OMV not behaving reliably at install

This was supposed to be simple replacement of my DNS-323 and it is not going well.

After several attempts, that each failed in their own strange and magical ways I am giving it one last go with OMV.

The last install REFUSED to spin down the HDD's, spinning and clicking all the time. One attempt the OS updates just tossed errors.

Another time it just lost track of the raid. Another install found a raid/FS from a previous attempt, but couldn't do anything with it.

OMV feels like it has all the features, but the operation is unreliable. Help me love this software.

Build:
I built my NAS from an Odroid HC4 with a pair of Barracuda Compute 8TB (ST8000DM004) and industrial 16GB SD.

The PCB is removed from the original case and affixed to a 1U 19" shelf. The PS is 15V@4.33A, exceeding the 4A recommendation.

HDDs use right angle connector and Sata extension cables to sit along side the PCB.

Process this time to "start from scratch":

1. Followed a forum post to locate spiupdate_odroidhc4_20201222.img.xz

2. (Balena) Etched a SD with that file, booted holding the button to force SD boot, watched it program onboard flash to default state.

3. Conformed the system booted to petitboot without any SD installed.

4. Etched an SD with Armbian_21.08.6_Odroidhc4_bullseye_current_5.10.81.img.xz found here.

5. Booted holding the button to force SD boot, confirm OS install, setup users and configure region. Update OS with:

sudo apt update && sudo apt upgrade -y

6. Reboot without holding the button to boot into petitboot, "Exit to shell", to cause auto boot from SD card, I ran:

# flash_eraseall /dev/mtd0
# flash_eraseall /dev/mtd1
# flash_eraseall /dev/mtd2
# flash_eraseall /dev/mtd3

7. Reboot to SD card successful, following the install script page I ran

sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

8. Connecting to OMV by http succeeds, using "admin" account I "secure wipe" drives found at /dev/sda and /dev/sdb (both showing 7.28TiB), 2 days pass.

9. Create raid (/dev/md0, mirror) and allow to fully sync, 1 day passes.

Now we get to the problem this go-round...
10. Create file system on device "/dev/md0" type 'EXT4' and start process. The sub-window appears in the browser and the FS building process starts.

(BTW this printout routine is buggy and stops using '\n' and runs off the left side of the screen above 10K)

I changed focus on the computer and began working on other things expecting this to take several hours.

At some point later, less than an hour, I return and OMV is back at the login screen.

Strange because in the 'secure wipe' dialog and Raid array sync progress stayed visible and page unlocked until complete.

Upon logging in, there is no file system in the list. Was it not created?

Trying to create a file system now, the drop down menu does not display "/dev/md0" as a device, even though it shows in the raid management list.

I pulled logs that weren't empty. I started the File system creation about 8-9am, I think.

What happened? Can I trust OMV with my data?

Is there some incompatibility with my drives (why they wont spin down)?

I think I discovered what happened, and why the raid array was not available for creating a new file system.

The file system creation process started and completed and at some point.

The drive preparation was complete, but OMV never mounted it.

Using the create/mount button I was able to find and mount the EXT4 FS and move forward.

I also seem to have discovered the source to the HDD spin down problem from before. in this thread a user is asked to run hd-idle, but here were my initial results:

jesse@Blinky2:~$ sudo systemctl status hd-idle
Command 'hd-idle' not found, but can be installed with:
sudo apt install hd-idle

Is hd-idle supposed to be installed with the OMV setup script?

Adding the service and running "sudo systemctl status hd-idle" returns this now:

jesse@Blinky2:~$ systemctl status hd-idle
● hd-idle.service - hd-idle - spin down idle hard disks
     Loaded: loaded (/lib/systemd/system/hd-idle.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Sun 2022-01-02 21:44:01 PST; 11min ago
       Docs: man:hd-idle(1)
    Process: 112469 ExecStart=/usr/sbin/hd-idle $HD_IDLE_OPTS (code=exited, status=0/SUCCESS)
        CPU: 3ms

Jan 02 21:44:01 Blinky2 systemd[1]: Starting hd-idle - spin down idle hard disks...
Jan 02 21:44:01 Blinky2 hd-idle[112469]: usage: hd-idle [-t <disk>] [-a <name>] [-i <idle_time>] [-l <logfile>] [-d] [-h]
Jan 02 21:44:01 Blinky2 systemd[1]: hd-idle.service: Succeeded.
Jan 02 21:44:01 Blinky2 systemd[1]: Started hd-idle - spin down idle hard disks.

and returning this morning the drivers were cool to the touch and showed this:

jesse@Blinky2:~$ sudo hdparm -C /dev/sda
[sudo] password for jesse:

/dev/sda:
 drive state is:  standby
jesse@Blinky2:~$ sudo hdparm -C /dev/sdb

/dev/sdb:
 drive state is:  standby

when they are spinning the status is "active/idle"

After poking it some this morning (causing the drives to spin up) I can confirm they spun down in about the right length of time while being watched.