Grub first, then ethics.
Fedora 19 is coming up, and I've taken advantage of installing the beta to also switch my stand alone grub partition to run grub2 instead of the old grub1. I did this using a quick and dirty hack rather than trying to install grub2 manually.
I re-used the partition I had fedora 17 on to install fedora 19 (twice). I first installed so fedora 19 was in a single partition (which included /boot as a subdirectory). I did a minimal install to take the smallest amount of time.
I then saved the /boot subdirectory in a safe place using rsync -a and I re-installed fedora 19 in the same partition, but this time I also made my old stand alone grub partition be mounted as /boot when it installed.
(By the way, I should note that the os-prober correctly finds my existing Fedora 18 partition and points at it as well, so while doing this I haven't lost the ability to boot my main fedora 18 partition).
Now I almost have a stand alone grub2 partition, but at the moment the just installed fedora 19 needs it as well.
At this point, I copy the saved /boot directory back to the fedora 19 partition, edit the fedora 19 fstab to not mount /boot, and fix the grub.cfg file to use the new UUIDs I got when I reformatted and installed the 2nd time. Now the fedora 19 partition no longer depends as much on my stand alone grub2 partition.
Now (carefully testing in small incremental changes) I can rewrite the grub.cfg file in the stand alone partition and use the multiboot directive to do the grub2 equivalent of chainloading the grubs in each of my fedora partitions (one running 19, the other 18). Once I'm sure that works, I can remove the various kernel images leftover from the fedora 19 install into the separate boot partition, and I have a completely clean stand alone grub2 boot that can redirect the boot to other things.
Now my two fedora partitions are completely independent. They can each get kernel updates without screwing up my boot order or needing to make os-prober entries.
When it comes time to install the next new fedora, I can use the technique I originally described in Installing Fedora 18 to copy a completely installed fedora image out of a virtual machine and just fixup some UUIDs here and there. I won't need to do any grub install in the copy since the multiboot directive should do everything needed (untill they decide to totally change the multiboot protocol conventions, of course, which is sure to happen someday with linux developers :-).
With that working, I'm free to experiment with adding additional stuff to the stand alone grub. One thing that is always useful is a memtest boot entry. For doing things like updating BIOS and firmware, a DOS boot is often useful, and a boot of a live CD image for recovery is also nice. I discovered how to do many of these with memdisk. I obtained the memdisk boot image by extracting it from the syslinux rpm (I didn't want to officially install all of syslinux for fear it would clobber my grub booter :-).
I also tried out some examples of using the grub2 loopback feature and have boot entries for booting the knoppix live DVD and the ubuntu 13.04 live cd that way.
The upshot is that all this nonsense seems to work. I even boot the recover iso image off a different disk with gpt partitions (where I had space for it to live). This all resulted in this config file for my stand alone grub2 partition:
set default="0"
terminal_output console
set timeout="9"
menuentry "Boot Fedora 18 via multiboot" {
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
multiboot /boot/grub2/i386-pc/core.img
}
menuentry "Boot Fedora 19 via multiboot" {
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
multiboot /boot/grub2/i386-pc/core.img
}
menuentry "Boot Memtest" {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
linux16 /memtest/memtest86+-4.20.bin
}
menuentry "Boot Freedos 1.1" {
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
linux16 /syslinux/memdisk
initrd16 /syslinux/FD11-144.IMG
}
menuentry "Boot Grml recovery live cd" {
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
search --no-floppy --fs-uuid --set=root 83693456-a3ef-4b35-a4bb-e0671367e40e
linux16 ($root)/booty/syslinux/memdisk iso
initrd16 ($root)/booty/grml64-full_2013.02.iso
}
menuentry "Boot Ubuntu 13.04 live cd" {
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
search --no-floppy --fs-uuid --set=root 83693456-a3ef-4b35-a4bb-e0671367e40e
set isofile="/booty/ubuntu-13.04-desktop-amd64.iso"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile noprompt noeject
initrd (loop)/casper/initrd.lz
}
menuentry "Boot KNOPPIX 7.0.4 DVD" {
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
search --no-floppy --fs-uuid --set=root 83693456-a3ef-4b35-a4bb-e0671367e40e
set isofile="/booty/KNOPPIX_V7.0.5DVD-2012-12-21-EN.iso"
loopback loop ($root)$isofile
linux (loop)/boot/isolinux/linux bootfrom=/dev/sdb1$isofile acpi=off keyboard=us lang=us
initrd (loop)/boot/isolinux/minirt.gz
}
It is pretty nifty to be able to boot freedos and reference files on a FAT usb stick for doing things like BIOS updates (of course it would be niftier if manufacturers would come up with better ways to do things like that independent of windows or dos :-).
Historical information from my previous grub2 experiments:
Indication are that the GRUB2 developers are anxious to improve GRUB2 so much that it is no longer possible to chainload a linux partition which uses GRUB2. The grub2-install script prints dire warnings about blocklists and needs the --force option to make it install in a partition, and it broke in the Fedora 17 Beta, which is another sign of looming disaster.
Since sometimes the best way to win a game is with a preemptive strike, I decided to investigate switching my stand alone GRUB1 partition where I chainload all the versions of linux installed on my system for a stand alone GRUB2 partition which could use the official GRUB2 ways of multi booting (if they can be winkled out of the totally useless documentation).
My first problem was getting GRUB2 instead of GRUB1 installed on my /mainboot partition. I don't remember all the different ways I broke my system while trying to do this (I was using a test system I regularly trash, by the way, since I knew I'd break it :-). The technique that finally worked may not need to be this elaborate, but it did work:
First I copied all the grub2 files from my Fedora 17 partition's /boot directory to the /mainboot directory (which is where I had my stand alone GRUB1 boot partition /dev/sda1 mounted).
rsync -a /boot/grub2/ /mainboot/grub2/
That gets all the support modules in place and a sample grub.cfg file I can modify to try and get it to boot the other kernels. However, GRUB1 is still installed in the MBR and nothing will make GRUB2 boot till I get it installed:
mv /boot /saveboot
mv /mainboot /boot
grub2-install /dev/sda
mv /boot /mainboot
mv /saveboot /boot
Warning: The above commands are just what I wish I had typed. By the time I did what should have been the equivalent of the above, I was booting off a Fedora 17 Live USB stick, so by then the disk was really /dev/sdb and I also had to edit the device.map file to change sdb to sda (which will be the name of the disk when I boot without the USB stick).
That finally got GRUB2 to boot and show my menu entries I had put in the grub.cfg file. Unfortunately, none of the entries would work the way I initially wrote them (using the kernel command).
Apparently the GRUB2 in Fedora 17 has evolved beyond anything as mundane as a generic kernel command. Now you need to use different commands for different kinds of kernels. Googling around eventually led me to the linux16 command for booting memtest, so I finally got one of my menu entries to operate correctly (but I'd really like to be able to do more on this machine than just test memory :-).
More googling led me to the multiboot command to use instead of kernel to boot the core.img file in the 2nd kernel (but note that this file moved between Fedora 16 and Fedora 17, so get the right location).
This made the entry for Fedora 17 boot correctly (at last!), but the entry for Fedora 16 still gives errors. Apparently whatever the hell multiboot actually is, the Fedora 16 version of GRUB2 isn't compatible. (The docs run on and on about multiboot as if they had discovered fire for the first time, but it is all incoherent babbling about how wonderful it is with nothing actually giving you any idea what the babbling is about).
So, even though the idea here was to get rid of chain loading, I had to resort to chain loading to get Fedora 16 to boot. That finally gives me these three completely different menu entries to boot Fedora 16, Fedora 17, and memtest:
set default="0"
set timeout=10
menuentry "Boot Fedora 16" {
set root='hd0,msdos3'
chainloader +1
}
menuentry "Boot Fedora 17" {
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos5'
multiboot /boot/grub2/i386-pc/core.img
}
menuentry "Boot Memtest" {
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
linux16 /memtest/memtest86+-4.20.bin
}
I have no idea if all those insmod commands are needed, I just copied them from the installed Fedora 17.