Debian installation OK, but cannot boot HC4

[odanmag]

Got my 2 HC4 devices. I plugged into the fist unit 2 x 4TB WD HD and started Petitboot. I ran Debian installer via netboot_default. I selected RAID1, LVM and encryption. Installer said all’s right. Restarted, but HD doesn’t boot, instead Petitboot appears. I updated Petitboot to latest firmware, not better, HD didn’t boot. Any idea what I can do ?

[tobetter]

Did you install the OS to the 2x 4TB HDD with RAID1/LVM or installed to SD card?
Does the "Petitboot appears" mean that you have the Petitboot screen shows to the display but it does not show the boot entry, "Debian Buster 10" for your case?

[odanmag]

Did you install the OS to the 2x 4TB HDD with RAID1/LVM or installed to SD card?
Does the "Petitboot appears" mean that you have the Petitboot screen shows to the display but it does not show the boot entry, "Debian Buster 10" for your case?

Yes, OS is installed on RAID1 (the 2 drives). On RAID1 i have /boot (ext2, 256 MB) and all rest is crypted (4 TB ext4 + 3.8 GB swap => LVM). No SD card used. Petitboot shows to the display but no « Debian Buster 10 » option to select.

[tobetter]

Ok, let me explain what I am thinking.

I guess your installation would be fine with RAID1, it would be worth to check the RAID1 set up with your PC for sure.
The problem is that the Petitboot is very small Linux system and it's customized version of Linux 4.9 to fit into 8MB SPI flash memory, so its feature is very restricted. That's why the Petitboot cannot access RAID1 storage so it cannot read what to boot and how.

To be honest, I've not tested RAID, sorry about that. So the solution I would suggest for you is to use SD card for OS, maybe fully or partially. At least if you allocate the /boot to SD card and everything else to RAID1, the Petitboot will show you the boot entry since the Petitboot only sees the boot script boot.ini or boot.scr and check the kernel image, ramdisk, device tree and compose the kernel parameter as composed in the boot script. So once the real kernel load and booted from /boot in SD car will load and run, it would be able to access RAID1.

Please let me know how you think.

[odanmag]

Ok, let me explain what I am thinking.

I guess your installation would be fine with RAID1, it would be worth to check the RAID1 set up with your PC for sure.
The problem is that the Petitboot is very small Linux system and it's customized version of Linux 4.9 to fit into 8MB SPI flash memory, so its feature is very restricted. That's why the Petitboot cannot access RAID1 storage so it cannot read what to boot and how.

To be honest, I've not tested RAID, sorry about that. So the solution I would suggest for you is to use SD card for OS, maybe fully or partially. At least if you allocate the /boot to SD card and everything else to RAID1, the Petitboot will show you the boot entry since the Petitboot only sees the boot script boot.ini or boot.scr and check the kernel image, ramdisk, device tree and compose the kernel parameter as composed in the boot script. So once the real kernel load and booted from /boot in SD car will load and run, it would be able to access RAID1.

Please let me know how you think.

Thank you for your lines. I’ll test some options et let you know

[tobetter]

Ok, let me explain what I am thinking.

I guess your installation would be fine with RAID1, it would be worth to check the RAID1 set up with your PC for sure.
The problem is that the Petitboot is very small Linux system and it's customized version of Linux 4.9 to fit into 8MB SPI flash memory, so its feature is very restricted. That's why the Petitboot cannot access RAID1 storage so it cannot read what to boot and how.

To be honest, I've not tested RAID, sorry about that. So the solution I would suggest for you is to use SD card for OS, maybe fully or partially. At least if you allocate the /boot to SD card and everything else to RAID1, the Petitboot will show you the boot entry since the Petitboot only sees the boot script boot.ini or boot.scr and check the kernel image, ramdisk, device tree and compose the kernel parameter as composed in the boot script. So once the real kernel load and booted from /boot in SD car will load and run, it would be able to access RAID1.

Please let me know how you think.

Thank you for your lines. I’ll test some options et let you know

My crossfingers!!
This would be good use case to run RAID on ODROID-HC4.
Please let me know if you need any help from me.

[odanmag]

RAID seems finally to work. /boot partition must just not be part of RAID1. No SD card needed, Debian 10 entry is showing up and OS starts from Petitboot. I need to do more tests, check if I can manually copy /boot partition to second disk and simulate a crash on disk1 - see if system can still boot - and if all data are there.

After this step I will add encryption to RAID1 and see how performance is.

And in general stability have to be validated too.

[tobetter]

RAID seems finally to work. /boot partition must just not be part of RAID1. No SD card needed, Debian 10 entry is showing up and OS starts from Petitboot. I need to do more tests, check if I can manually copy /boot partition to second disk and simulate a crash on disk1 - see if system can still boot - and if all data are there.

After this step I will add encryption to RAID1 and see how performance is.

And in general stability have to be validated too.

Ha...you made it!! I did not think of having non-RAID partion in the same storage for /boot partition. So you prove that Netboot Install can set up RAID while installing without any other efforts and can boot from the SATA storages without SD card. Obviously the stability and performance is a different story but this is very good use case. Thank a lot!!

[mad_ady]

If you create a second /boot on the second disk do the following experiment:
- create it with the same uuid as on the first disk. Petitboot should display only one and will select one randomly
- create it with a different uuid - you should see two enteries in petitboot

You should be able to keep them synchronized by running a rsync in a kernel postinst hook.

[odanmag]

I created a /boot partition on the second disk and I copied into this new partition the exact same content of partition /boot first disk:

dd if=/dev/sda1 of=/dev/sdb1 bs=4096

With this procedure the UUID keeps the same on both /boot partitions. Petitboot displays only one entry. When I remove the second disks, the system continues to function and boots without any problem. If I remove the first disk, that does contain the active /boot partition, and reboots, the system automatically activates the /boot partition on the remaining disk (the second one) and boots without any problem. Petitboot always displays only one entry. Everything works as expected.

[tobetter]

I created a /boot partition on the second disk and I copied into this new partition the exact same content of partition /boot first disk:

dd if=/dev/sda1 of=/dev/sdb1 bs=4096

With this procedure the UUID keeps the same on both /boot partitions. Petitboot displays only one entry. When I remove the second disks, the system continues to function and boots without any problem. If I remove the first disk, that does contain the active /boot partition, and reboots, the system automatically activates the /boot partition on the remaining disk (the second one) and boots without any problem. Petitboot always displays only one entry. Everything works as expected.

Out of curiosity, where is the file /etc/fstab? It probably contains the UUID for /boot...?

[odanmag]

/etc/fstab file is on RAID (md0)

Code: Select all

root@hc4:/# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0  3.7T  0 disk  
├─sda1    8:1    0  243M  0 part  /boot
└─sda2    8:2    0  3.7T  0 part  
  └─md0   9:0    0  3.7T  0 raid1 /
sdb       8:16   0  3.7T  0 disk  
├─sdb1    8:17   0  243M  0 part  
└─sdb2    8:18   0  3.7T  0 part  
  └─md0   9:0    0  3.7T  0 raid1 /

Code: Select all

root@hc4:/# ls -lah /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root  80 fév 14  2019 .
drwxr-xr-x 7 root root 140 jan  1  1970 ..
lrwxrwxrwx 1 root root   9 fév 14  2019 a390f668-463b-44b6-93a0-e2475160df9b -> ../../md0
lrwxrwxrwx 1 root root  10 fév 14  2019 c1fa80bc-4327-44e7-871b-0956cc1c9d9c -> ../../sda1

Code: Select all

root@hc4:/# blkid
/dev/sda1: UUID="c1fa80bc-4327-44e7-871b-0956cc1c9d9c" TYPE="ext2" PARTLABEL="boothd1" PARTUUID="dd4da1b0-2cd1-4fda-8136-9ce6d782fbbb"
/dev/sda2: UUID="a0995fa1-bdd9-c8a9-08b2-d9c2eb94cd32" UUID_SUB="44107bb9-10e8-45db-03bc-5f085c7bbe96" LABEL="hc4:0" TYPE="linux_raid_member" PARTLABEL="debianhd1" PARTUUID="318700f3-f742-466e-b327-77e3d6c0f2de"
/dev/sdb1: UUID="c1fa80bc-4327-44e7-871b-0956cc1c9d9c" TYPE="ext2" PARTLABEL="boothd2" PARTUUID="02730d79-7305-479e-9fcc-130304dcb06f"
/dev/sdb2: UUID="a0995fa1-bdd9-c8a9-08b2-d9c2eb94cd32" UUID_SUB="091a7ee1-6d2b-eace-5821-cc39666bc8c3" LABEL="hc4:0" TYPE="linux_raid_member" PARTLABEL="debianhd2" PARTUUID="ec75bdd7-d9a6-4ea3-9916-546245fb26d8"
/dev/md0: UUID="a390f668-463b-44b6-93a0-e2475160df9b" TYPE="ext4"

Code: Select all

root@hc4:/# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/md0 during installation
UUID=a390f668-463b-44b6-93a0-e2475160df9b /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=c1fa80bc-4327-44e7-871b-0956cc1c9d9c /boot           ext2    defaults        0       2

[odanmag]

Next step for me will be adding lvm + encryption, as well as the possibility to enter encryption key remotely, during reboot process. For production, I’ll also add a swap partition.

[mad_ady]

Remember that kernel upgrades will write only on one partition and you'll need to sync the second one, othwrwise, on disk failure you'll boot and old kernel and you'll be missing the old modules.

[odanmag]

Remember that kernel upgrades will write only on one partition and you'll need to sync the second one, othwrwise, on disk failure you'll boot and old kernel and you'll be missing the old modules.

Thanks for the hint

[Th0masL]

Hey guys !

I'm going to buy the HC4 in order to setup a NAS with RAID1 support.

My main idea was to install the system on a single non-encrypted SD Card, and configure the 2x SATA drives as RAID1, encrypted with LVM or with VeraCrypt.

That way I should be able to reboot/start the server remotely :
Step 1 : The server boots and load the OS from the SD Card
Step 2 : I ssh into the server and mount the LVM partition by typing the password
Step 3 : The server is fully usable

I already have a similar setup on an existing server, but it contains only 1 SSD drive (and is encrypted with Veracrypt) so I'm not yet satisfied with the lack of redundancy.

I would need to test the hot-swap and RAID1 rebuild, as my plan is to have a fully failure-proof RAID1 NAS, with automatic rebuild if a new HDD is detected

Any idea of a better setup to be able to reboot the server remotely, with RAID1 and encrypted partitions ?

[lmikkele]

Hey guys !

I'm going to buy the HC4 in order to setup a NAS with RAID1 support.

My main idea was to install the system on a single non-encrypted SD Card, and configure the 2x SATA drives as RAID1, encrypted with LVM or with VeraCrypt.

That way I should be able to reboot/start the server remotely :
Step 1 : The server boots and load the OS from the SD Card
Step 2 : I ssh into the server and mount the LVM partition by typing the password
Step 3 : The server is fully usable

I already have a similar setup on an existing server, but it contains only 1 SSD drive (and is encrypted with Veracrypt) so I'm not yet satisfied with the lack of redundancy.

I would need to test the hot-swap and RAID1 rebuild, as my plan is to have a fully failure-proof RAID1 NAS, with automatic rebuild if a new HDD is detected

Any idea of a better setup to be able to reboot the server remotely, with RAID1 and encrypted partitions ?

Hi, friend. Currently i am still waiting for my HC4 to arrive, but have the same idea. On my current server i am using dropbear-initramfs . Hopefully you met this approach previously. If no, you could refer to this instruction:
https://hamy.io/post/0009/how-to-instal ... #gsc.tab=0

[legogris]

@odanmag: Where you ever able to get LUKS for the root partition working on the HC4?