On 10/23/2016 12:03 PM, Andrei Borzenkov wrote:
Sorry, I could not parse this sentence. What I'd do,
1. create target devices (presumably, Linux MD)
2. copy from source to target
3. adjust /etc/fstab, /etc/mdadm.conf and whatever else is appropriate
(which may include recreating initrd)
4. chroot and run grub-install and grub-mkconfig or your distro command
that calls them
Note that in case of Linux MD grub2 grub-install only supports
installation on MBR. You also need to install grub2 individually on each
disk that belongs to MD array holding /boot/grub if you want resiliency
against individual disk failures.
Also note that in relation to grub2 "Linux MD" is really relevant only
if grub2 itself (i.e. /boot/grub directory) is on MD array.
5. configure your distro to use new bootloader location(s) as default.
So next time you update grub2 package it runs grub-install with correct
parameters. In case of Debina-based distro this actually means running
dpkg-reconfigure.
I found my main problem was a wrong rsync copy. I had been doing rsync -acHv
and I noticed my scripts had become rsync -aCHv which is filtering out many
files needed
to run. I decided that MD raid was not so helpful in my workstation use
as having really good robust backups incrementally happening with rsync,
and easy to restore by just booting a different disk and occasionally removing
a disk,
putting it on shelf for hacker safe backup. I don't seem to need a chroot to
get
a rsync copy of a running drive to boot OK. I just stop networking and
thunderbird
and firefox and run rsync until there are just a few log files difference and
call
that a good bootable backup.
I have my debian grub-pc package pinned at 2.02~beta2-22+deb8u1 for now. Grub2
is
working well with a GPT partitioned disk now. Everything seems high
reliability!
Thanks for the help.
John Griessen
_______________________________________________
Help-grub mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-grub
