FC16 Grub hangs after system update

bluezImage · #1 7th March 2012, 05:02 PM

I have been running FC16_64, Gnome 3.2 successfully on my laptop for several months. This is a dual boot configuration with Windows 7, which I hardly use.

I just did a system update that included installing a new kernel (3.2.9-1.fc16.x86_64). The update completed and I rebooted the system. The machine restarted but hangs up with the screen showing only GRUB and a flashing cursor.

I booted from the rescue disk and did chroot /mnt/sysimage. I see that /boot/grub2/grub.cfg has been modified to add the new kernel. But I do not see anything obvious that would cause the system to hang.

Could anyone suggest a possible fix?

Thanks

chrismurphy · #2 7th March 2012, 08:25 PM

First command reinstalls GRUB2. Second command recreates the grub.cfg. I would just do both unless you're looking to isolate which one fixes your problem. Do both after you've booted rescue from F16 DVD media, and chroot /mnt/sysimage. I will assume the target drive is sda.

Code:

grub2-install --recheck --no-floppy /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

bluezImage · #3 7th March 2012, 08:25 PM

I got the system to start booting again by running

# grub2-install --force /dev/sda

in the recovery session.

I had to use --force because I was seeing a set of warnings:

warn: Your embedding area is unusually small. core.img won't fit in it.

warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are unreliable and their use is discouraged.

error:will not proceed with blocklists.

I would like to not have to use blocklists for this setup.

Can anyone suggest a way I can resize the embedding area to eliminate the use of blocklists?

chrismurphy · #4 7th March 2012, 08:31 PM

Yeah your disk is still using MBR partitioning, and probably an older tool originally partitioned it, placing partition 1 start at sector 63. And lately we're seeing some users complaining about this very error message, for some reason GRUB 2 core.img in some cases is getting too big.

You could try the flag --no-floppy which might make core.img just a tiny bit smaller, and small enough to fit in between the MBR and partition 1.

You could also use gparted to resize/move partition 1's start to the now common sector 2048. So this is both a move (change start point) and resize, because the partition has to shrink to avoid stepping on partition 2.

bluezImage · #5 7th March 2012, 08:50 PM

Your right. I am using a Dell Studio 17 laptop that came with Windows 7 installed. I then installed FC 12 and subsequently upgraded through FC 13, 14, 15 and then 16 using the same partitions. This is my partition list:

Device Boot Start End Blocks Id System
/dev/sda1 63 80324 40131 de Dell Utility
/dev/sda2 81920 30801919 15360000 7 HPFS/NTFS/exFAT
/dev/sda3 * 30801920 503685119 236441600 7 HPFS/NTFS/exFAT
/dev/sda4 503685120 976773167 236544024 5 Extended
/dev/sda5 503687168 504711167 512000 83 Linux
/dev/sda6 504713216 976773119 236029952 8e Linux LVM

I like the idea of using gparted to resize partition 1. However, I am unsure what the implication would be to the software (Dell Utility) that resides there. Is there a way I can resize p1 without corrupting data?

chrismurphy · #6 7th March 2012, 10:07 PM

Only if it's a resizable filesystem inside that partition. You'd have to check which file systems are resizable. I don't think FAT32 is (?) but all ext and NTFS are.

You'd have to research the nature of this utility partition, it's possible the BIOS expects it to be at sector 63. Before screwing with it, I would use dd to make a backup sector copy, which you can store on any filesystem, and then if you mess things up you can always restore it. I'd also save the number of sectors for that partition. I'm a little confused by that fdisk output:

63 80324 40131 de Dell Utility

How do you have a start sector of 63, end sector of 80324, but only 40131 blocks? These are 2 sector block sizes? Huh. All of them appear to be reported this way, 1K blocks? I thought everything had been using 4K blocks for years now.

---------- Post added at 03:07 PM ---------- Previous post was at 02:48 PM ----------

Check out your partition map again. You have 1596 sectors in between partitions 1 and 2. I bet the --force blocklists are largely stored in there. If that's working, you get to a grub menu, and you can boot your operating systems, I'd leave things alone.

You could just move partition 1, not resize, by 1500 sectors, and then reinstall GRUB2 and it probably won't complaint. It doesn't even need that much space.

bluezImage · #7 7th March 2012, 10:35 PM

These are good questions. I don't know enough yet about this to have any reply. When I get a chance I am going to look into using gparted to get a better understanding of what's happening here.

In the mean time using --force blocklists gave me back my grub menu back and I can boot the OS. So I have a functioning system again.

Many thanks for your help.