Problem booting under F16

[Sam Varshavchik]

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 at monster ~]$ rpm -q -f /lib64/libcrypt.so.1
glibc-2.14.90-18.x86_64

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 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 /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  
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20111127/a1947d9f/attachment-0001.bin