Joe Zeff writes:
Recently I upgraded my laptop to F16 using preupgrade. This morning, at a convention, I did a system update that included (I thought) a new kernel. The next time I booted, the system hung, with no output. I had to power-cycle to try again, this time getting error messages: it couldn't find libcrypt.so.1 and there were a number of failures of systemd-remount-api-vfs. I power-cycled again, and hit the space bar to enter the GRUB menu. There was one F16 kernel, the upgrade, and the latest F14 kernel, which worked. After several experiments, I found that libcrypt.so.1 is provided by glibc-devel,
No, it's not. libcrypt.so.1 is provided by glibc, not glibc-devel. [mrsam@monster ~]$ rpm -q -f /lib64/libcrypt.so.1 glibc-2.14.90-18.x86_64Furthermore, if you have a corrupted libcrypt.so.1, it wouldn't matter which kernel you're booting. You wouldn't be able to boot anything. No matter which kernel you boot, you're running the same userspace, and the same set of userspace libraries. If a fundamental, key rpm like glibc is bad, you're bricked, until you fix it in rescue mode.
Unless you're in the business of actually building, and compiling anything, you do not need any -devel package.
so I told yum to install it, which brought along some other
things I'd thought I'd had. Alas, it didn't fix the boot failure.
Although this isn't my main box, I'd like to keep it working as well as
I can, and would prefer to be using an F16 kernel if I'm running F16, as
I appear to be.
There's no sufficient information to determine what your problem is. But, whatever it is, you have to start with a stable filesystem. That's your starting point. No matter what your problem is, if you have a corrupted filesystem, you're going to spin around in circles. Given that you've experienced boot failures, and hard resets, your first order of business is to stabilize your filesystem.
# touch /forcefsckThen reboot, using whichever kernel you're able to boot. If your boot starts rhgb and plymouth, press ESC as soon as it comes up, to see the kernel messages. You should see messages that confirm that all your filesystems are getting fsck-ed. The end result is going to be either that fsck was able to repair your filesystems, or not. If not, you have too much damage, and no other option but to wipe and reinstall. fsck might result in an extra reboot, and a second round of fscking, if there was damage to your root filesystem. That's normal, as long as the second time around the job gets done.
If fsck gives you a clean bill of health, and you can boot, the next step is to validate your rpm database. Run 'rpm --rebuilddb'. From this point, you have a stable filesystem, and a good rpm database, and you have a starting point to figure out what's really broken with your overall system. If 'rpm -- rebuilddb' gave you an empty rpm database, or one that's obviously not reflecting reality, you'll pretty much have to reinstall – it's possible to restore it, if you spend some time to gather what you have, and what the rpm database should really show for you, but that'll be very time consuming, and the path of least resistance is a reinstall.
At this point, with a stable filesystem and a good rpm database, you can begin figuring out why you can't boot the latest kernel. The first thing to try would be to remove, and reinstall the kernel rpm, in order to recreate the boot initrd image, and the grub menu entries. It's very possible that, if your problem was a dud initrd, that would fix it.
Keep in mind that if, after a forced fsck (and an rpm rebuild, I suppose), you ended up with an unbootable brick, it wasn't caused by the fsck. You were bricked to start with. All that fsck did was make it obvious.
Also, as a side note, I'd tried using the fedorautils and made the mistake of adding the color terminal, finding that I don't like it. How do I reverse this?
http://fedorautils.sourceforge.net/revert.html
Attachment:
pgpL_38segxL6.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
