F16 upgrade disaster

Sam Varshavchik mrsam at courier-mta.com
Sat Nov 12 17:21:02 UTC 2011


TL;DR: grub2 turned out to be a disaster. Grub from F15 was still there, so  
it was able to boot F16, but after applying the updates, uninstalling grub2,  
installing F16's grub, it fails to boot with "Error 16".

Anyway, I started an upgrade of F15 to F16. I got a complaint that Anaconda  
couldn't update the bootloader configuration. Ok, that's never a good sign,  
but I haven't had an upgrade disaster for a few releases, so why not do  
something exciting on a Saturday morning? I told it to keep going, and after  
it finished installing all RPMs, I flipped to an alt screen, to see what's  
going on.

Instead of grub, I now have grub2. Ok. Spent a few minutes with a crash  
course on grub2, and looking around in /boot. Looks like the functional  
replacement for /boot/grub/menu.lst (which only has the F15 kernels listed,  
and does not have the F16 kernel, not a surprise) would be  
/boot/grub2/grub.cfg

At, my grub.cfg is empty. Wonderful.

Some reading and googling later, I ran /sbin/grub2-mkconfig, which produced  
a reasonably looking grub.cfg, including the new kernel.

So, let's try, what I presume is the next step, /sbin/grub-install:

[root at octopus grub2]# /sbin/grub2-install /dev/sda
/sbin/grub2-setup: warn: Your core.img is unusually large.  It won't fit in the embedding area..
/sbin/grub2-setup: 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..
/sbin/grub2-setup: error: will not proceed with blocklists.

Well, that's nice to know. After more Googling, I'm told that my MBR area,  
before the first partition, is too small, that's what this apparently means.  
Splendid. My partitions are mdraid partitions, with ext inside them. It's  
difficult enough to resize existing partitions, but when they're mdraid  
partitions, it's worse. I've done it once before, when /boot had to be  
expanded, and it's bad enough to do it with a working system, but I have an  
unfinished upgrade on my hands, that won't even boot, on its own.

After more Googling, I see someone saying – just use parted, and flip the  
'bios_grub' bit on the first partition. Sounds simple enough:

[root at octopus mrsam]# parted /dev/sda
GNU Parted 3.0
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: ATA ST3250410AS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system     Flags
 1      32.3kB  831MB   831MB   primary   ext3            raid
 2      831MB   22.3GB  21.5GB  primary   ext3            raid
 3      22.3GB  28.7GB  6440MB  primary   linux-swap(v1)  raid
 4      28.7GB  250GB   221GB   extended
 5      28.7GB  250GB   221GB   logical   ext3            raid

(parted) toggle 1 bios_grub
parted: invalid token: bios_grub
Flag to Invert? ^C
(parted) help toggle
  toggle [NUMBER [FLAG]]                   toggle the state of FLAG on partition
        NUMBER

	NUMBER is the partition number used by Linux.  On MS-DOS disk labels,
        the primary partitions number from 1 to 4, logical partitions from 5
        onwards.
        FLAG is one of: boot, root, swap, hidden, raid, lvm, lba, hp-service,
        palo, prep, msftres, bios_grub, atvrecv, diag, legacy_boot


Ok, so "bios_grub" is not a valid flag, but it's listed as a valid flag. Ok,  
fine, let's move on.

Well, I still had a system with networking enabled, so just on a lark, "yum  
list" showed that grub is still in the F16 repository. Yay! Wait, can't  
install, it conflicts with grub2. Ok, "yum remove grub2". Almost there. "yum  
remove grub". Yum then proceeds to install grub2 again, because it sees that  
grub2 obsoletes grub. Put "exclude=grub2*" in /etc/yum.conf, install it,  
/sbin/grub-install works. Phew (and I haven't even mentioned the wonderful  
error messages I got from /sbin/new-kernel-pkg…).

But then, a reboot gets stuck at "Error 16". I tried everything I could  
think of, but I give up. I'm pxe-booting this brick into rescue mode,  
pulling my files off, and reinstalling.

Funny thing is, I just updated to F16 on another laptop with this partition  
table:

Model: ATA Hitachi HTS54121 (scsi)
Disk /dev/sda: 100GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system     Flags
 1      32.3kB  41.9GB  41.9GB  primary  ntfs
 2      41.9GB  42.1GB  140MB   primary  ext3            boot
 3      42.1GB  42.6GB  518MB   primary  linux-swap(v1)
 4      42.6GB  100GB   57.4GB  primary  ext3

The upgrade went without a hitch. And grub was happy to install itself there.

Is that the raid flag that's the problem?

I have other machines with RAID installs. I don't know if I can update them,  
now.














-------------- 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/20111112/0ff7832c/attachment.bin 


More information about the users mailing list