Raspberry Pi Forums

Just installed Arch from NOOBS and am liking it. It boots (and shuts down) very fast - and I generally like its "fast, minimal, bleeding edge" feel.

But I noticed a couple of seg fault problems. I installed "busybox" (with pacman -S busybox) and then did:

# rdate my.clock.host

Result was Segmentation Fault - core dumped.

Installed ntp, with pacman -S ntp

then did:

# ntpd

to try to get the daemon running. Result was another seg fault.

These results 100% repeatable.

However, FWIW, this does work:

# ntpdate my.clock.host

Surely, software installed from the repos should not be seg faulting, yes?

Seg faults shouldn't happen, maybe a bad card?
I just saw other thread about ntpd seg faults

Seriously doubt it is a bad card - this card has worked for a long time.

Other post suggests something is really going on. Incidentally, one thing I don't like about Arch's "pacman", as compared to the Debian "apt" tools, is that it is not at all clear, when you install something, whether it is already installed. "apt-get" will tell you that it is already installed - and either refuse to install it again (if it is current) or tell you it is going to upgrade it (if it isn't the latest version). "pacman" just goes ahead and does it. Worse, as far as I can tell, it will do the "upgrade" EVEN IF the installed version is current.

This is all relevant to the current issue - specifically with "ntp", because when I first booted up Arch, I did a "ps" to see if ntpd was already running - didn't see it in ps, so assumed it wasn't installed, so I installed it. But from what I can tell now, it probably was already installed - but was just crashing on startup, so it wasn't running. You can see how this is all very confusing and makes debugging the underlying issue difficult.

Poster in other thread seems to be suggesting that the upgrade caused the problem - which is possible if it really was working before and his version was sufficently older than the current (buggy) version.

Someone has found the problem, and workaround https://archlinuxarm.org/forum/viewtopi ... 60&t=11191
When the fix is done I don't know

pepedog wrote:Someone has found the problem, and workaround https://archlinuxarm.org/forum/viewtopi ... 60&t=11191
When the fix is done I don't know

Sort of.

Speaks to the problem in 'ntpd', but doesn't address the general problem of seg faults (in, e.g., busybox).

Martin Frezman wrote:Incidentally, one thing I don't like about Arch's "pacman", as compared to the Debian "apt" tools, is that it is not at all clear, when you install something, whether it is already installed. "apt-get" will tell you that it is already installed - and either refuse to install it again (if it is current) or tell you it is going to upgrade it (if it isn't the latest version). "pacman" just goes ahead and does it. Worse, as far as I can tell, it will do the "upgrade" EVEN IF the installed version is current.

If you have an up-to-date version of the package installed pacman will have a message along the lines of "packagename is already up to date, reinstalling" this will be above the estimated package size.

If you have an up-to-date version of the package installed pacman will have a message along the lines of "packagename is already up to date, reinstalling" this will be above the estimated package size.

Yes, true. That's how I knew that it was doing exactly that - installing something unnecessarily (unnecessary because it was already there and already up-to-date).

The point is that the Debian method, which is more "chatty", is preferable.

Why? Pacman tells you that the package is already installed and asks if you want to continue with reinstalling it, how is that an issue?

Update: re: busybox (rdate).

I copied over a working busybox executable from a Raspbian system (compiled by me long ago) and it (the 'rdate' applet/functionality) works fine. So, the problem is in the busybox executable in the Arch repo.