Re: UUIDs and PARTUUIDs cloning for backup recovery

[Andrei Borzenkov]

22.10.2016 01:49, John Griessen пишет:
> Hi,
> 
> I once used grub1 to clone disks to multiple other disks and after each
> cloning run with rsync a script changed fstab to match the device it was on
> and I was ready to boot from 3 or 4 places on the same machine, or over
> ssh to another
> machine.  I occasionally had wrong boot attempts because of changing
> /dev/sdc vs. /dev/sdb
> definitions, but that was not too often and fairly easy to fix.
> 
> How would I get that function back today where debian and the rest all
> use UUIDs and PARTUUIDs?
> 
> Does anyone have a good script for it?  It seems so complicated now.
> 

grub1 was not aware of Linux MD and simply accessed each individual disk
as independent filesystem. This is not possible with default metadata
format of Linux MD that is used today so this likely would not work even
with grub1. Where is /boot/grub located - is it on Linux MD?

> I recently tried booting an rsync copy of my main workstation computer
> with two screens
> and lots of engineering tools and data installed so it has a size of 45GB.
> I was starting from a mdadm raid1 boot to /.  I copied that with rsync,
> and booting
> the copy on a single hard drive, grub2 gives me kernel panics

Once kernel is loaded, grub2 ceases to exist so it hardly can give you
kernel panic (unless you mean *grub2* kernel here).

> and cannot utilize a hand written grub.cfg menu entry like this:
> 
> menuentry 'Debian stretch/sid Linux 4.7.0-1-amd64' --class debian
> --class gnu-linux --class gnu --class os {
>   load_video
>   insmod gzio
>   insmod part_msdos
>   insmod diskfilter
>   insmod mdraid1x
>   insmod ext2
>   set root=UUID=87d52f42-838c-4418-a37e-f0d0a63ed8ed

This line is bogus. I'm surprised code after this works at all.

>     echo 'Loading Linux 4.7.0-1-amd64 ...'
>     linux /boot/vmlinuz-4.7.0-1-amd64
> root=UUID=87d52f42-838c-4418-a37e-f0d0a63ed8ed  ro rootdelay=20
>     echo 'Loading initial ramdisk ...'
>     initrd /boot/initrd.img-4.7.0-1-amd64
> }
> 

When filesystem label or UUID changes you need to change every place
that is using filesystem label or UUID. There is nothing new here. grub2
"smple configuration" script is using UUIDs, so you need to update
grub.cfg to reflect new UUIDs.

> I ran
> sudo dpkg-reconfigure grub-pc
> 

Assuming that grub2 actually booted (I am a bit surprised it could get
as far as that :) ) it is enough to simply update grub.cfg; update-grub2
should do it. Of course dpkg-reconfigure also generates new stage2 image
to reflect your current disk configuration (the fact that you use Linux
MD, new UUID etc), so it makes sense.

> Do I need to create a different initrd.img as if it was on a single
> disk? 

That question is unrelated to grub and is better asked on Debian support
forum. In general, yes, distributions that I'm aware of default to
host-specific initrd, which means it will miss e.g. Linux MD drivers and
configuration. Distributions that build generic initrd by default still
need to be told where root is located and how to make it available =>
kernel params in grub.cfg.

> Do I need to get a chroot
> on the copy's / to run to do that?
> 

Yes, grub-mkconfig (which is called by update-grub2) expects to be run
in target system environment, so you need chroot. Can you run
dpkg-reconfigure from outside of installed root at all? I do not see any
option to specify where root is located.

> Should I be using
> set  root=PARTUUID=f2ce6af6-01
> ?
> 

No. grub2 is not Linux kernel and it does not support this syntax for
root variable (be it UUID or PARTUUID).