== What I needed to do with Grub2 to change my boot disk

On my work machine I have been very slowly migrating away from a
pair of old drives to a pair of new drives. For [[quite a while
LVMCautiousMigration]] the only thing the old drives have been used for
has been booting from and holding _/boot_; today I finally removed the
single surviving old disk and moved to booting off the new disks. It
turned out to be somewhat more involved than I expected.

The initial state was _/dev/sda_ as the old drive with _/boot_ as a
plain filesystems, _/dev/sdb_ and _/dev/sdc_ as the new drives with
_/boot-n_ (the new version of _/boot_) as a mirrored RAID array and
filesystem.
My first step (some time ago actually) was to run _grub2-install_ to
install the boot blocks on _sdb_ (and _sdc_, although I have no idea if
those work). Unfortunately I forgot to save the exact commands I used to
do this. My notes say that I bind-mounted _/boot-n_ on top of _/boot_
during this process so that _grub2-install_ would see the right thing in
the right place but I'm not sure how I handled device mappings.

Today I changed my _/etc/fstab_ to fix up the mounts (basically
changing _/boot-n_ into _/boot_), shut the machine down, pulled the
old drive, shuffled the cables around, and booted up. The machine
started Grub2 but then couldn't boot Linux, ultimately because it
couldn't find the kernel and initramfs. This happened because ~~I
forgot to update grub.cfg to tell it the new location and UUIDs of
the new _/boot_~~. Although Grub2 could find the new _/boot_ in
order to load grub.cfg, the various kernel stanzas in grub.cfg
re-specify where to find the kernel and initramfs with boiler plate
like this:

.pn prewrap on
>  set root='hd0,msdos1'
>  if [ x$feature_platform_search_hint = xy ]; then
>    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  bfe06079-ea84-49cb-a028-d5b1ad47cfba
>  else
>    search --no-floppy --fs-uuid --set=root bfe06079-ea84-49cb-a028-d5b1ad47cfba
>  fi
>  linux /vmlinuz-....

(The complexity of a Grub2 _grub.cfg_ is why I'm not really fond
of Grub2. I'm not sure we need a shell script interpreter embedded
in the boot system, and if it has to be fully programmable I wish
they'd used a better language.)

Since my _/boot_ was no longer (MS-DOS) partition 1 or a filesystem with
that UUID, this failed and everything bombed out.
To get the machine booted I dropped into the Grub2 command line and used
its _ls_ command to see what was there (per [[the Fedora page on Grub2
https://fedoraproject.org/wiki/GRUB_2]]). After finding that I wanted
'_md/13_' (I believe) I went back and changed the '_set root=..._' line
to specify it, then told Grub2 to try booting. This worked, although
Grub2 warned me that it still couldn't find the particular UUID.

Fixing this permanently required revising _grub.cfg_; I actually did
this twice, once the hard way and once the easy way. The hard way is to
use _blkid_ to look up the new _/boot_'s UUID then carefully edit all of
the stanzas to change the _set root=..._ bit to _md/13_ and change the
UUID in the _search_ lines. While this worked I didn't think that all of
those _--hint-..._ bits were correct any more and they made me nervous.

The easy way to fix this is to use _grub2-mkconfig -o /tmp/foo_ and
then pick through _/tmp/foo_ for the official and proper way to do
all of this boiler plate. It turned out to be (for me):

> _set root='mduuid/~~<md-uuid>~~'_ \\
> .... \\
> _search --no-floppy --fs-uuid --set=root --hint='mduuid/~~<md-uuid>~~' ~~<fs-uuid>~~_

(_grub2-mkconfig_ looked up the UUIDs for itself.)

(The really easy way would be to just use _grub2-mkconfig_ to
regenerate your _grub.cfg_, but I have an old-style _grub.cfg_ that
I happen to like and didn't want to have replaced with the new
Fedora 18 _grub2-mkconfig_ version. Also note that the grub.cfg that
_grub2-mkconfig_ creates for you may look nothing like the grub.cfg that
the Fedora installer creates. This is a complete mess and I hope that
Fedora fixes it someday.)

I'm sure that I'm going to need to do this again sometime in the future.
In that future, the smart thing to do will be to update _grub.cfg_
before the initial reboot (after the final copy from the old _/boot_,
for obvious reasons). I'm not sure if _grub2-mkconfig_ would give the
right results (even with making the new _/boot_ the actual _/boot_), but
clearly I can just look up the UUIDs by hand.

PS: no, I don't know why Grub2 and _grub.cfg_ don't have a final
fallback of 'where you got the grub.cfg from'. Probably it's for the
same reason that Grub2 needs a shell script interpreter.