SlackwareThis Forum is for the discussion of Slackware Linux.
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.
I have a big problem. I cannot log into my P4 box/Linux-Slackware 11.0.
I had 10.2 on my machine and was working just fine. Unfortunately, I was trying to upgrade a particular package (forget which one now.) and I accidentally 'upgraded' aaa_elflib. At least I am assuming this is the problem.
Here is the problem:
When I boot, I get as far as the reiserfs check, and then (on kernel 2.6.10), it asks for root pass and wants to go into single user mode. I have triple checked the reiserfs, and I don't think this is the problem.
If I use an older kernel I have setup to boot from menu, it gets past this, but I get a trail of 'cannot execute binary file' and then that ends and I am left with a dumb console. (Can type but thats it. No shell!)
I used a boot disk called: "Linux System Rescue" to see a better picture of whats going on.
When I try chroot to my system from disk, I get:
Code:
/lib/tls/libdl.so.2: invalid ELF header
I tried booting with the Slack 11.0 system disk (DVD or disk 1) and I tried installing from it. (In other words I tried re-installing the aaa_elflib / bin...tgz / and a couple other 'main' base files.
Still get the same problem.
When I do an 'ldd' on a particular problem binary, I get 'dynamic executable'. If I do this on the same executable after booting up with an 11.0 disk, it does read off the libs.
I cannot figure out what is going on. I am at the end of my rope. I would have re-installed a fresh 11.0, but I need to figure out what is going on, and I have spent allot of time getting this one going just the way I like it.
Please help!
-bC
Last edited by bonecrusher; 10-23-2006 at 06:41 PM.
libdl.so is part of glibc-2.3.6-i486-6 and glibc-solibs-2.3.6-i486-6. Have you reinstalled those yet?
Yes I did that already.
I have uninstalled and reinstalled many things. I have a list...
At any rate now I am at the point where I can boot to my root filesystem with sata.i kernel. I get quite a few errors, seemed like it mainly had to do with the modules and 'ldconfig' statement(?).. and many things don't work. (Like PKGTOOL).
Right now if I boot using one of my kernels, it still goes to reiser disk check single user.
I have also un- re- installed as many 'main' packages as I could think of. I noticed many of the packages (bin-11) for instance were 'installed' twice. When I actually uninstalled both versions (11.0 and 10.1) and re-installed bin-11.0 I noticed right away some commands started working again.. 'mount' for instance. But others aren't now. It's a real mess.
I think I need to install a 2.6 kernel too. I noticed the new version of udev doesn't use the same commands (ie udevstart). (BTW this was one of the main reasons that fsck kept trying to start at boot I think. It couldn't stat /dev/sda5.
I will keep updating as I try and fix things!
Last edited by bonecrusher; 10-26-2006 at 12:02 AM.
Upgrading elflibs probably wasn't the problem. The problem is most likely in not reading UPGRADE on the Slackware CDs and following those instructions to the letter. The system is in a pretty much unrepairable state. The best, easiest, and least head-banging solution is to just backup your important data (including config files) using a live CD and reinstall from scratch.
I'd also personally recommend using EXT3 over ReiserFS because it has a clear upgrade path and IMO a lot less likely to lose data.
Upgrading elflibs probably wasn't the problem. The problem is most likely in not reading UPGRADE on the Slackware CDs and following those instructions to the letter. The system is in a pretty much unrepairable state. The best, easiest, and least head-banging solution is to just backup your important data (including config files) using a live CD and reinstall from scratch.
I'd also personally recommend using EXT3 over ReiserFS because it has a clear upgrade path and IMO a lot less likely to lose data.
Well forgive me if I don't want to erase quite yet. As I mentioned, it had nothing to do with following the UPGRADE to the letter. It was a mistake I made in swaret (which in and of itself doesn't follow UPGRADE.TXT) that got compounded. (Probably more then once). You are right in the fact that if I had followed the UPGRADE to the letter this wouldn't have happened... I am going to keep trying and keep a record of what I do. I think I will give it maybe 2 or 3 more days. Thanks for the input.
Using swaret really isn't that bad, but using swaret to upgrade a/ is a really, really bad idea. That package set really needs a human touch in order for it to go smoothly. Really, now your system really is irrepairable and banging your head on it any more is completely pointless.
Using swaret really isn't that bad, but using swaret to upgrade a/ is a really, really bad idea. That package set really needs a human touch in order for it to go smoothly. Really, now your system really is irrepairable and banging your head on it any more is completely pointless.
Well, I can boot it now and log in.. Still getting some errors though. I am getting that - that it is pointless. Now I am getting seg faults when I run commands like 'less'. At least I have learned a few things about how the libraries work.
As I mentioned I have always used swaret with no problems, and I think what had happened (at least what I remember), is that the EXCLUDE variable got screwed up (I had been editing it before this happened...was trying to let it update ALSA). I think I must have inadvertently commented or deleted the aaa_ variable. Hence my problems! BTW - Whenever I did an upgrade I would always do what UPGRADE.TXT and (to a lesser extent) swaret --faq says: use installpkg/upgradepkg on "glibc-solibs,pkgtools,sed,bin". Does aaa_* ever get upgraded? Never thought about it, but in UPGRADE.TXT it doesn't mention "aaa_*" at all but says (after above pkgs are done) to go ahead and do:
This would also upgrade anything under aaa wouldn't it? Why doesn't swaret say anything about this? If it can be upgraded why is it under EXCLUDE and never mentioned in FAQ or man? Well just a thought.
So it technically isn't swaret fault and I do genuinely like the program and will continue to use it. Just beware when you edit that file. Be careful!
Well, I guess it is time to wipe the partition.
Ugg. This sucks.
Last edited by bonecrusher; 10-24-2006 at 09:44 AM.
I guess there is no need to do a fresh reinstall. You have to make sure glibc and kernel (built upon this glibc) are installed.
I'd suggest to boot from 1st CD, mount disk partition and do upgradepkg --reinstall --install-new for glibc-solibs and kernel & kernel-modules and update lilo.conf .
I guess there is no need to do a fresh reinstall. You have to make sure glibc and kernel (built upon this glibc) are installed.
I'd suggest to boot from 1st CD, mount disk partition and do upgradepkg --reinstall --install-new for glibc-solibs and kernel & kernel-modules and update lilo.conf .
Well that and it seems to me that aaa_elflibs needs to be installed before ANYTHING else. (The Slack Install has it second right after it creates the base system). As it sets up libraries for programs not installed and then when those programs are actually installed it (the new program) changes the symlink to it's own lib among other things...so installing elflibs over already installed stuff is prolly pretty bad idea as I found out. (or at least that is how I am grasping what happened). I had the system up pretty good after I got the kernel (from slack disk) installed. I ended up doing what you suggested shortly after I left the last msg in this thread, but the system still had a few major problems, and I have another slack box so I just backed up (scp -r):
/etc (every last drop)
/home/*
and a couple odd's and ends...
(such as my most recent .config for a 2.6.x kernel), and that was it.
(god I hate doing up a BRAND new .config!) Then wiped it out and started over. Already back up in KDE (with sound) and have most of my customizations resolved. Even got a new nano package made up already with checkinstall.
If I had had the time to spend on it I would have gotten it back (It prolly would have meant re-installing the whole system over the old one w/o a partition wipe, but it could have been done. But what is the point of doing that? Only if you don't have any backup resources (or LOT's of time to resolve all the new .configs laying around). Then again I could have always burned it to a dvd/cd. (And is it even possible (if your reading this) not to have a backup system with all the file systems around nowadays?) (Thinking online etc) 0Oh well live and learn.. as I said I learned quite a bit about slack install process/libraries this time around, though.
-b
Last edited by bonecrusher; 10-26-2006 at 12:14 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.