Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The logs of the startup process contained in /var/log/syslog and /var/log/messages are attached to this post.
How can I fix that (without reinstalling the system)?
I have not seen this before, but from using google it appears that it's because your locale data is from an older version of glibc to the one installed.
I don't understand why slackpkg reports that it upgraded glibc-solibs to the same version as what was already present, but I don't use slackpkg so maybe that's normal or I don't understand the report.
You'd need to boot the installer and mount your file system, then look at which versions of glibc are installed in /var/log/packages; then use upgradepkg to fix it.
I don't use slackpkg but I have never had an issue using upgradepkg as the packages are built -- indeed that's how each batch of updates is generally done. However, it may be that your $LC_COLLATE is set differently to mine : mine is the default "C".
Yes this happen to me during an upgrade on one of the systems I am writing a script for users to upgrade with. And seems that mirror I was using was not up to date. It borked the system.
sorry to say you went through what I went through. I noticed multilib is not up to date with current with the compat32. I use the UK mirror so I just did it all manually.
That system was borked. I you may want to chroot install over it. I tried but again endless loop of login type and logs you out. I am glad it was only a test system that got borked. Hang in there.
I should have used my local repos but had no clue current was going to catch me off guard.
Yes this happen to me during an upgrade on one of the systems I am writing a script for users to upgrade with. And seems that mirror I was using was not up to date. It borked the system.
sorry to say you went through what I went through. I noticed multilib is not up to date with current with the compat32. I use the UK mirror so I just did it all manually.
That system was borked. I you may want to chroot install over it. I tried but again endless loop of login type and logs you out. I am glad it was only a test system that got borked. Hang in there.
I should have used my local repos but had no clue current was going to catch me off guard.
I'm not sure that this would be near the correct answer and multilib does not exist on ARM.
e.g. if you mounted the filesystem of -current under /mnt/hd, and had the glibc packages in /tmp on your 14.1 machine:
ROOT=/mnt/hd upgradepkg /tmp/glibc-2.22*z
Give that a go. If that doesn't work, then it may be something going weird with the patches I applied to the -5 build -- but as I said, it didn't break on any of my systems and I have quite a lot of them ;-)
Just wanted to say I ran into this as well. I first upgraded glibc-solibs, and then the above message appeared, making upgradepkg unusable. I fixed it by running `LC_ALL=C upgradepkg ...' and updated the other glibc packages (as well as pkgtools and aaa_elflibs). I did not run into this on my x86 and x86_64 machines. On my other Raspberry Pi, I did not experience this either; there, I started the upgrade with LC_ALL=C upgradepkg right away and first upgraded glibc, aaa_elflibs and pkgtools in one go before upgrading anything else. I was lucky to have mksh installed as my default shell, since bash was broken due to this; mksh was not affected, and allowed me to login.
e.g. if you mounted the filesystem of -current under /mnt/hd, and had the glibc packages in /tmp on your 14.1 machine:
ROOT=/mnt/hd upgradepkg /tmp/glibc-2.22*z
Give that a go. If that doesn't work, then it may be something going weird with the patches I applied to the -5 build -- but as I said, it didn't break on any of my systems and I have quite a lot of them ;-)
Mine won't upgrade package, says its already installed.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.