Joe Zeff writes:
Recently I upgraded my laptop to F16 using preupgrade. This morning,
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
No, it's not. libcrypt.so.1 is provided by glibc, not glibc-devel.
[mrsam@monster ~]$ rpm -q -f /lib64/libcrypt.so.1
Furthermore, 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
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 /forcefsck
Then 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
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
mistake of adding the color terminal, finding that I don't like it. How
do I reverse this?