Debian LUKS encrypted OMV snapraid fails reboot after creation

  • Hey OMV community,


    I've been fighting this one for a couple of weeks, hoping for any insight. Debian 10 install on 500G SSD with 5 WD 4TB reds. Install OMV 5 (so pulling latest 5.x) following https://openmediavault.readthe…stallation/on_debian.html. Prep drives, install plugins, create encrypted drives, create snapraid, create mergerFS pool per, and create shared folders per steps 4.1-4.6 from this great guide - https://www.michaelxander.com/diy-nas/


    The first time i did this i then just created the SMB/CIFS shares and then started using the system with no issues. A couple of weeks later I rebooted and the system successfully checks the journal of the SSD boot disk but then doesn't get beyond that. There is an obligatory 1 min 30 sec wait period/countdown at the console and then it barfs out into recovery mode.


    I had made a dd copy of the SSD disk after getting the system up for the first time, so I restored to it, but the same results. I have two identical SSDs so I tried the dd boot disk restore to one, but same results after booting from that disk. I then switched the first SSD out with one of the others and rebuilt from scratch. This time I rebooted after multiple OMV steps. So, rebooting the system following creating the encrypted drives, then after creating the snapraid, then after creating the mergerFS pool, and then after creating the shared folders, everything looked good. I next created the SMB/CIFS shares and rebooted and it barfed with the exact same previous results.


    /var/log/boot isn't super helpful in identifying where things are bombing. I initially thought perhaps grub disk checks are failing because of the LUKS encryption, but if that were the case i would expect the reboot after applying LUKS encryption to the disks to barf at that point, but it didn't. It finally bombed following the reboot after configuring the SMB/CIFS shares.


    I have a ton of photos of logs, etc., since the network never comes up due to the failures, but could certainly dump a bunch of the logs to a thumb drive and upload. Hoping someone has seen something like this before. I humbly await any and all knowledge. Thank you.


    CB

  • KM0201

    Approved the thread.
  • The above step by step barf-out is actually the same issue documented by edogd with guidance from subzero79 here - LUKS + KeyFile + AutoMount? [SOLVED]. And it appears the solution is documented here - https://github.com/OpenMediaVa…-luksencryption/issues/39. So question to edogd - where in the process you and I both followed (http://https//michaelxander.com/diy-nas/) do you use crypttab_test? I'm about to reinstall for the hundredth time and would like to document it properly. Thanks!

    • Official Post

    A couple of weeks later I rebooted and the system successfully checks the journal of the SSD boot disk but then doesn't get beyond that. There is an obligatory 1 min 30 sec wait period/countdown at the console and then it barfs out into recovery mode.

    Try a search on the forum I believe the issue is related to the encryption on the drives, with the drives being locked during a boot process and the use of union filesystem, not sure if there was a solution.

    Raid is not a backup! Would you go skydiving without a parachute?


    OMV 7x amd64 running on an HP N54L Microserver

  • subzero79  edogd the crypttab_test mod to LUKS worked like a champ, thank you both! I installed the crypttab_test branch after installing openmediavault-luksencryption and then immediately added the disks to cryptttab after encrypting them. At reboot I get the prompt for the encryption key (only once, which is nice) and the OS unencrypts and mounts them (which suits my risk tolerance).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!