[SOLVED] Using efistub to boot from a RAID5 array

kpl_kampfsemmel · 2019-12-10 23:05:41

Fair warning in advance: I am a noob, who just happens to like how lightweight and straight forward linux is. My knowledge about kernel and inner system mechanisms is very basic.

I acquired an old HP Compaq Pro 8300 with a gen3-i3 and 16gb memory which I intend to use as a fileserver with nextcloud.
I added a 2-port PCIe SATA controller to the 4 on-board ports and connected six 2tb-drives.
The computer has full EFI funcionality which I intend to use for booting the system. ( efistub method )

I want to have everything redundant, which is why I don't just install to one disk and use the others as an array.
My original idea was to use LVM for the data array as well as for the system array, but I concluded, that a system on top of LVM on top of a RAID5 would be unneccessarily complicated.
The plan now is to create a version 1.0 RAID1 array with an ef00-type 100mb partition on each drive for the system image ("/boot"), one version 0.90 RAID5 array with an ext4 file system for "/" and another RAID5 array with LVM on top for all the data.

I will ignore the data/LVM part for this post, because its not relevant.

The RAID1 array is working. The system starts to look for the specified device where the root partition resides on, but it can't find it.
My guess is that I am doing something wrong with specifying the correct device OR that the kernel just lacks auto-assembly ability.

I created a virtual machine to simlify the problem for this post. Just 3 drives. No data array.

Here's what I did: (omitting irrelevant stuff from inside $ arch-chroot . Details about my default setup routine at >Link< )

$ gdisk -l /dev/sda | tail -3
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFIBOOT
   2         1050624        16777182   7.5 GiB     FD00  Linux RAID

$ gdisk -l /dev/sdb | tail -3
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFIBOOT
   2         1050624        16777182   7.5 GiB     FD00  Linux RAID

$ gdisk -l /dev/sdc | tail -3
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFIBOOT
   2         1050624        16777182   7.5 GiB     FD00  Linux RAID

$ mdadm -Cv -e 1.0 /dev/md0 -l 1 -n 3 /dev/sda1 /dev/sdb1 /dev/sdc1

$ mdadm -Cv -e 0 /dev/md1 -l 5 -n 3 /dev/sda2 /dev/sdb2 /dev/sdc2

$ mkfs.fat -F32 -n EFIBOOT /dev/md0

$ mkfs.ext4 -L root /dev/md1

$ mount -L root /mnt

$ mkdir /mnt/boot

$ mount -L EFIBOOT /mnt/boot

$ pacstrap /mnt linux base base-devel efibootmgr

$ genfstab -U /mnt >> /mnt/etc/fstab

$ efibootmgr -c -d /dev/sda -p 1 -l \vmlinuz-linux -L "archlinux efistub sda" -u "initrd=/initramfs-linux.img root=LABEL=root rw"
$ efibootmgr -c -d /dev/sdb -p 1 -l \vmlinuz-linux -L "archlinux efistub sdb" -u "initrd=/initramfs-linux.img root=LABEL=root rw"
$ efibootmgr -c -d /dev/sdc -p 1 -l \vmlinuz-linux -L "archlinux efistub sdc" -u "initrd=/initramfs-linux.img root=LABEL=root rw"
$ efibootmgr -c -d /dev/sda -p 1 -l \vmlinuz-linux -L "archlinux efistub fallback sda" -u "initrd=/initramfs-linux-fallback.img root=LABEL=root rw"
$ efibootmgr -c -d /dev/sdb -p 1 -l \vmlinuz-linux -L "archlinux efistub fallback sdb" -u "initrd=/initramfs-linux-fallback.img root=LABEL=root rw"
$ efibootmgr -c -d /dev/sdc -p 1 -l \vmlinuz-linux -L "archlinux efistub fallback sdc" -u "initrd=/initramfs-linux-fallback.img root=LABEL=root rw"

$ exit

$ umount -R /mnt

$ reboot

This results in

ERROR: device 'LABEL=root' not found. Skipping fsck.
:: mounting 'LABEL=root' on real root
mount: /new_root: can't find LABEL=root.

I also tried specifying the device by UUID, taken from

$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID

NAME      SIZE TYPE  FSTYPE            UUID
loop0   524.5M loop  squashfs
sda         8G disk
├─sda1    512M part  linux_raid_member 6c435470-5b14-72d5-fc0b-e1dc013b6711
│ └─md0   512M raid1 vfat              4EDB-37A7
└─sda2    7.5G part  linux_raid_member ca8a44be-9866-d73f-5241-990451489ef3
  └─md1    15G raid5 ext4              8399ad05-f799-40e7-8a1c-e9f9c5d9551d
sdb         8G disk
├─sdb1    512M part  linux_raid_member 6c435470-5b14-72d5-fc0b-e1dc013b6711
│ └─md0   512M raid1 vfat              4EDB-37A7
└─sdb2    7.5G part  linux_raid_member ca8a44be-9866-d73f-5241-990451489ef3
  └─md1    15G raid5 ext4              8399ad05-f799-40e7-8a1c-e9f9c5d9551d
sdc         8G disk
├─sdc1    512M part  linux_raid_member 6c435470-5b14-72d5-fc0b-e1dc013b6711
│ └─md0   512M raid1 vfat              4EDB-37A7
└─sdc2    7.5G part  linux_raid_member ca8a44be-9866-d73f-5241-990451489ef3
  └─md1    15G raid5 ext4              8399ad05-f799-40e7-8a1c-e9f9c5d9551d
sr0       639M rom   iso9660           2019-12-01-09-07-07-00

:

$ efibootmgr ... root=UUID=8399ad05-f799-40e7-8a1c-e9f9c5d9551d rw"

This resulted in the same issue. "Device not found."

Same applies to "root=/dev/md1"

What am I missing? Am I trying to make efistub do something it can't do?

Last edited by kpl_kampfsemmel (2019-12-11 16:14:04)

g2g591 · 2019-12-10 23:21:47

No, it looks like you forgot to setup mkinitcpio.conf to get the array setup during boot.

Last edited by g2g591 (2019-12-10 23:22:02)

kpl_kampfsemmel · 2019-12-11 00:01:50

Thank you so much for that fast reply.
I will try that tomorrow and report back.

frostschutz · 2019-12-11 10:18:33

For booting purposes, mdadm RAID1 with 1.0 metadata is fine. (Enables read-only access to the raid-unaware bootloading mechanism.)

For everything else you should use the default mdadm 1.2 metadata. version 0.90 is ancient and shouldn't be used at all anymore.

There's nothing wrong with LVM on RAID, that's up to personal preference/requirements.

kpl_kampfsemmel · 2019-12-11 12:36:37

Interesting. In the official kernel docmumentation I read that auto-assembly at boot time is only supported for type 0 superblocks
Is this documentation outdated?

frostschutz · 2019-12-11 13:48:07

No, it's correct, but that's what people used before there was initrd/initramfs. You don't want kernel-based auto-assembly, you want initcpio with mdadm to assemble it.

(Also, ArchLinux kernel uses modules for mdraid, it's not compiled into kernel, so auto-assembly without initrd would not be possible either way using the ArchLinux standard kernel.)

Last edited by frostschutz (2019-12-11 14:33:11)

kpl_kampfsemmel · 2019-12-11 15:25:20

I just tried it with another test VM at my office and it works!
I will do a clean walk-through with the PC at home, create a minimalistic howto and post it here.
If anyone ever intends to do the same and has a similar knowledge and skill level to me, this thread will save their day.

Thank you so much, g2g591 and frostschutz! You made my day!

WorMzy · 2019-12-11 15:34:22

Please remember to mark your thread as solved by editing the first post and amending the topic title.

https://wiki.archlinux.org/index.php/Co … ow_to_post

kpl_kampfsemmel · 2019-12-11 16:14:37

Oh, yes, I forgot. Thanks for reminding me. Done.

Arch Linux

#1 2019-12-10 23:05:41

[SOLVED] Using efistub to boot from a RAID5 array

#2 2019-12-10 23:21:47

Re: [SOLVED] Using efistub to boot from a RAID5 array

#3 2019-12-11 00:01:50

Re: [SOLVED] Using efistub to boot from a RAID5 array

#4 2019-12-11 10:18:33

Re: [SOLVED] Using efistub to boot from a RAID5 array

#5 2019-12-11 12:36:37

Re: [SOLVED] Using efistub to boot from a RAID5 array

#6 2019-12-11 13:48:07

Re: [SOLVED] Using efistub to boot from a RAID5 array

#7 2019-12-11 15:25:20

Re: [SOLVED] Using efistub to boot from a RAID5 array

#8 2019-12-11 15:34:22

Re: [SOLVED] Using efistub to boot from a RAID5 array

#9 2019-12-11 16:14:37

Re: [SOLVED] Using efistub to boot from a RAID5 array

Board footer