26.12.2020 15:38, Istvan Gabor пишет:
Fri, 25 Dec 2020 09:32:43 +0300 időpontban Andrei Borzenkov írta:
24.12.2020 20:53, Andrei Borzenkov пишет:
24.12.2020 20:08, Istvan Gabor пишет:
Hello:
I would like to set up a Leap 15.1 system that boots from a md raid1 array.
I have a sample configuration from a working debian system that boots from raid1 array. However there are 2 things in the sample configuration I don't understand.
The working debian grub.cfg has this:
### BEGIN /etc/grub.d/10_linux ### menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-686-pae' --class debian --class gnu-linux --class gnu --class os { load_video insmod gzio insmod raid insmod mdraid1x insmod part_msdos insmod part_msdos insmod ext2 set root='(mduuid/4245........a8)' search --no-floppy --fs-uuid --set=root 68b........26e echo 'Loading Linux 3.2.0-4-686-pae ...' linux /boot/vmlinuz-3.2.0-4-686-pae root=UUID=68b........26e ro nomodeset quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-3.2.0-4-686-pae }
My questions:
...
What occurs if the the fs-uuid of the mduuid device's file system is not equal to the one given in the search command?
The value of "root" variable does not change.
That's not quite correct. If fs-uuid in search command is found on some other device than mduuid device then "root" variable will be set to refer to this other device. If fs-uuid in search command is not found anywhere, the value if "root" variable does not change.
Thank you Andrei. I understand this.
I still could not make grub2 raid1 chainloading.
I could install grub2 on the raid1 (/dev/md113) device:
# grub2-install --force /dev/md113 Installing for i386-pc platform. grub2-install: warning: the drive name `mduuid/b...f6' in device.map is incorrect. Using hostdisk//dev/md113 instead. Please use the form [hfc]d[0-9]* (E.g. `hd0' or `cd'). grub2-install: warning: File system `ext2' doesn't support embedding. grub2-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported.
The result is grub bootblock in the first sector of /dev/md113 which is configured to load core.img from the absolute disk location on /dev/md113 (which corresponds to the file /boot/grub2/i386-pc/core.img).
This is grub.cfg:
set timeout=3 menuentry "openSUSE Leap 15.1" { insmod part_msdos insmod ext2 insmod mdraid1x set root='mduuid/b...f6' search --no-floppy -l Leap -s linux /boot/vmlinuz root=LABEL=Leap noresume initrd /boot/initrd }
In grub2-emu the correct menu appears in the emulator, that is grub is installed on the raid1 (/dev/md113) device.
You do realize that grub-emu does know how to interpret "hostdisk" and boot time grub code most likely does not?
I installed the chainloader on the mbrs of /dev/sda and /dev/sdb.
# grub2-install --boot-directory=/boot/grub2.chainload /dev/sda Installing for i386-pc platform. Installation finished. No error reported.
# grub2-install --boot-directory=/boot/grub2.chainload /dev/sdb Installing for i386-pc platform. Installation finished. No error reported.
You must have some reasons to use these commands because I do not understand what these commands are supposed to achieve.
The chainloader's config is this:
set timeout=3 menuentry "openSUSE Leap 15.1" { insmod part_msdos insmod ext2 insmod mdraid1x insmod chain set root='mduuid/b...f6'
That's wrong. $root at this point must point to physical BIOS disk that will be considered "boot device" by loaded code. Linux MD RAID device cannot be BIOS disk by definition.
search --no-floppy -l Leap -s chainloader +1 }
Huh? In the previous step you "installed chainloader" (whatever you mean here) on MBR of two disks. Now you load block from entirely different disk location which has nothing to do with these two MBR. How exactly these two steps are related? Unless you have firmware partitioned RAID (like IMSM). But as you do not describe your complete configuration I can only guess.
This shows the correct menu when I start the computer. But when it tries to boot/chainload the raid1 device, grub hangs, only showing: GRUB
This means the initial boot sector was loaded and it tried to load core.img to continue boot and likely succeeded to load something (otherwise we should have seen different error) but code that it loaded hung.
It seems that the chainloader can't find or load grub installed on the raid1 device?
Of course not. chainloader is command that emulates PC BIOS boot protocol^Wconventions. PC BIOS knows nothing about Linux MD RAID, so you cannot tell PC BIOS to boot from Linux MD RAID. What happens here - you load the first block from your MD RAID1 (because *grub* knows how to access it) and jump to it. It gets as parameter some BIOS disk number (it does not matter which one, in this case grub will fall back to disk C - 0x80 - because you did not provide valid disk number). Grub boot block was configured to load core.img from absolute disk locations *relative to /dev/md113*. Now grub interprets these locations *relative to physical disk start*. So it loads some garbage at these locations and jumps to it.
How can I solve this?
If the question is "how you boot with /boot/grub on MD RAID1" - you simply install grub on MBR, that's all. You can also chainload this MBR from another grub (making sure to set correct $root) and it should also work. If the question is "how I chainload grub from /boot/grub on MD RAID1 if I cannot install on MBR" - well, you need separate physical partition(s) with file system that supports embedding to install boot block into. In practice this is only btrfs or you could (try to) convince grub maintainers to support installing boot block directly in raw partition without filesystem. Currently this is explicitly prohibited. You will still need separate physical partitions to install grub into them. Alternatively you could directly load core.img using multiboot /boot/grub2/i386-pc/core.img assuming this core.img was configured to find its /boot/grub on MD RAID1. You will need to skip actual installation of boot block using grub-install --no-bootsector This won't be integrated in default bootloader management framework on openSUSE. Which is also doable ... if someone is willing to implement and maintain it.