That very well could be the root of the problem. I have a feeling when installing off a USB drive it some times changes any onboard drives to something other than SDA which obviously seems to mess the installation up once the USB is removed.

Does anyone know how to reassign the disk we want as the OS drive to SDA during the installation of OMV 4 off of a USB drive? I did not see an option come up to change that.

mdadm keeps looking for arrays, but installer did not ask what to do with the 4 drives..

The installer doesn't do anything with data drives. It isn't OMV's fault that the array isn't assembling on boot. I would fix the array with a rescue disk like systemrescuecd and then see if things work.

The four 4TB disk are fresh, not even partitioned.
The installer did not prompt for the creation of an array, so why mdadm pops up?

OMV doesn't have its own kernel or do any magic with the boot. There is no config file that is causing it to fail to boot with four blank HDs. mdadm is enabled in the kernel but that is because it checks for arrays on every boot like it should.

ryecoaaron, thanks for jumping in and giving us your thoughts on this. Any help is appreciated.

I know that the installation guide suggests removing all data drives when installing OMV 3 or 4 and it seems most of us tried to follow that.

Would you recommend trying the install OMV 4 with the entire array of drives (including the will be OS drive of course) present during the installation? Is there any reason the guide recommends removing the drives in that case other than accidently choosing a data drive as the installation location?

We could obviously try that within a VM pretty quickly if we wanted to as well.

That'ts good to know. I am going to try and install a VM on my OMV3 box to see what happens if OMV4 is installed with the data array existing. Hopefully I will get time to test this in the next week or two and it could give us some insight as to what is going on.

I am going to try and install a VM on my OMV3 box to see what happens if OMV4 is installed with the data array existing. Hopefully I will get time to test this in the next week or two and it could give us some insight as to what is going on.

I did test this in a VM and it worked fine. It would be very interesting to see what steps you took if you get it to fail.

I may just be guessing, but it appears to me that the issue only comes up when OMV gets installed to a device other than Sda, and then the device connected as Sda changes between installation and first boot. For most folks, this is either because the installer was Sda during installation and it now that disk/drive is removed, and/or because the disks for the array are subsequently attached and the first disk became Sda.

In the case of @ebreetteville in a previous post, OMV was installed to a flash drive. I had the same errors when installing to a flash drive (USB DOM), but only in instances where the installer came up as Sda and the flash drive as Sdb. Installation worked, but after removing the installation media and rebooting, I got the mdadm error and boot failed to complete. But, if I rearranged the drives until the installation media was Sdb, then I had no issues.

Perhaps in the cases where OMV fails to boot after data drives are first attached, its because the first data drive became Sda, but wasn't the installer? Others reported here previously that in cases where the data disks were attached during install, installation was successful. It could be in those cases, Sda is still the same disk as during install, even if not the boot disk, so everything works.

What got me thinking on this was the mention in one post previously that if the installer was left in, the new system disk booted, plus mentions of "Missing sda1" warnings. Seems that something about the identity of sda is an issue in these cases, even if sda isn't the boot disk.

I would think that might be a reason why OMV doesn't boot but it shouldn't be the reason the kernel can't re-assemble an array. Each drive has a signature on it and the arrays are re-assembled by their signatures. It *shouldn't* care about the drive letters.

I would think that might be a reason why OMV doesn't boot but it shouldn't be the reason the kernel can't re-assemble an array. Each drive has a signature on it and the arrays are re-assembled by their signatures. It *shouldn't* care about the drive letters.

Definitely need to defer to you on these things, as its way above my expertise. In any case, I now think my issue is slightly different from the others here. I'm failing to boot due to the mdadm message others are getting, followed by busybox prompt, But in my case, I was starting with a fresh install and no disks connected. I wanted to pull some baseline power numbers with no disks attached, and couldn't get it to boot due to that message. I never got to the point where I connected the disks, so different situation than failure to re-assemble an array.

Definitely need to defer to you on these things, as its way above my expertise. In any case, I now think my issue is slightly different from the others here. I'm failing to boot due to the mdadm message others are getting, followed by busybox prompt, But in my case, I was starting with a fresh install and no disks connected. I wanted to pull some baseline power numbers with no disks attached, and couldn't get it to boot due to that message. I never got to the point where I connected the disks, so different situation than failure to re-assemble an array.

Hmm wonder why it’s only happening to us. I only pull the data drives due to it been recommended I’ve used omv and the software raid was made with omv way back in the early days of omv which ever version was around in 2012.