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@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@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
(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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines