mdadm: no arrays found in config file or automatically

I see the same thing. I think this only happens on systems that have no RAID configured, so it's a harmless warning, not an error.

Do you have RAID disks or not?

Im getting this

Just done a fresh installed unplugged all my drives in the software raid installed the os onto the ssd which then booted fine and i could access the webinterface. then ive shutdown and reconnected the drives and started the sytem again but all i get is

mdadm: no arrays found in config file or automatically
gave up waiting for root file system device. common problems:
- boot args (cat /proc/cmdline)
- check rootdelay= (did the system wait long enough?)
- missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/sda1 does not exist dropping to shell!

then goes to busybox.

but if i shutdown and unplug the raid drives and power back up it boots normally. any suggestions.

update,

as a test i have reinstalled omv3 onto the os drive with the swraid drives unplugged once installed ive plugged the sw raid drives back in and booted the system which boots normally. looks like its a omv4 issue but im no expert with linux so who knows.

Hi All,

Didnt want to create another thread about the same issue, and since the OP managed to sort it figured that it wasn't bad form to jump in.

I too have this issue on a brand new build, using build 4.0.14.

Built on an HP microserver GEN8, following the Setup found here : https://www.abyssproject.net/2…rver-gen-8-servir-de-nas/
(Used google Translate to give an english version).

However i cant get past the error to allow the build of a new array.

I will try and see if i can fire this up using OMV3.X tomorrow... however i would say the indications from above would suggest it would be ok... So whats changed in this respect between OMV3.X and OMV4.X?

Any pointers gratefully appreciated!

Many thanks
Paul

Quote from toibs

Hi All,

Didnt want to create another thread about the same issue, and since the OP managed to sort it figured that it wasn't bad form to jump in.

I too have this issue on a brand new build, using build 4.0.14.

Built on an HP microserver GEN8, following the Setup found here : https://www.abyssproject.net/2…rver-gen-8-servir-de-nas/
(Used google Translate to give an english version).

However i cant get past the error to allow the build of a new array.

I will try and see if i can fire this up using OMV3.X tomorrow... however i would say the indications from above would suggest it would be ok... So whats changed in this respect between OMV3.X and OMV4.X?

Any pointers gratefully appreciated!

Many thanks
Paul

Display More

did you try putting omv3 back on and did it work as expected like it did for me.

It’s a shame omv4 didn’t work since everything’s in docker looks like I could of moved over with out any issues.

anyone managed to fix this issue yet or am i stuck on omv3 for now. haven't seen anything on the forums yet with a fix

I am running into the same issue. Fresh install of Debian 9, installed openmediavault via apt-get and am now getting the no arrays error. I have Debian running on a single SSD and I have a four drive array that is not yet configured in OMV (it does have an old configuration from another software raid).

# omv-initsystem
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

Quote from z0rk

I rebooted and still get the same error message again. So I checked /etc/mdadm/mdadm.conf and noticed that the line I added was gone, so I added it again and rebooted; and I am still getting the same error message.

I am experiencing the same as well.

Anyone had a update on this. Or does it look like where sticking to omv3

Quote from chclark

Anyone had a update on this. Or does it look like where sticking to omv3

Are you having any other problems besides that repeating warning message during boot?

Quote from gderf

Are you having any other problems besides that repeating warning message during boot?

thats the only issue i can see as this stops the system booting. i have had to roll back and install omv3 as that is the only way the system will boot.

I had the same issue, I've been running OMV 2 and in order to upgrade to OMV 4 I disconnected all data disks as manual tells to and performed fresh install, OMV was booting with no issues, I reconnected data disks (RAID5) and got stuck in (initramfs) console. At that point I remembered that I forgot to edit /etc/mdadm/mdadm.conf before re-install it had

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=openmediavault:Storage UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx

at the bottom (I replaced my UUID value with x-es here), so I disconnected all the drives again, booted, put the ARRAY line in mdadm.conf and ran
> update-initramfs -u
(-u for update) and
> update-grub
for good measure, shut down, connected all the drives, booted up - the problem was gone and the raid is up and running (you have to mount the filesystem (the one that is on the RAID) through OMV interface though)

Note: I don't know about UUID is it in the superblock or is it coming from this config, but I'm pretty sure the name parameter should match the name of your raid array.

Googled mdadm.conf, manual says

uuid=
The value should be a 128 bit uuid in hexadecimal, with punctuation interspersed if desired. This must match the uuid stored in the superblock.
name=
The value should be a simple textual name as was given to mdadm when the array was created. This must match the name stored in the superblock on a device for that device to be included in the array. Not all superblock formats support names.

So it's better to have original mdadm.conf to copy the ARRAY line from, otherwise you have to get that information from the RAID array somehow.

Quote from curlymike

I had the same issue, I've been running OMV 2 and in order to upgrade to OMV 4 I disconnected all data disks as manual tells to and performed fresh install, OMV was booting with no issues, I reconnected data disks (RAID5) and got stuck in (initramfs) console. At that point I remembered that I forgot to edit /etc/mdadm/mdadm.conf before re-install it had

Code

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=openmediavault:Storage UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx

at the bottom (I replaced my UUID value with x-es here), so I disconnected all the drives again, booted, put the ARRAY line in mdadm.conf and ran
> update-initramfs -u
(-u for update) and
> update-grub
for good measure, shut down, connected all the drives, booted up - the problem was gone and the raid is up and running (you have to mount the filesystem (the one that is on the RAID) through OMV interface though)

Note: I don't know about UUID is it in the superblock or is it coming from this config, but I'm pretty sure the name parameter should match the name of your raid array.

Googled mdadm.conf, manual says

uuid=
The value should be a 128 bit uuid in hexadecimal, with punctuation interspersed if desired. This must match the uuid stored in the superblock.
name=
The value should be a simple textual name as was given to mdadm when the array was created. This must match the name stored in the superblock on a device for that device to be included in the array. Not all superblock formats support names.

So it's better to have original mdadm.conf to copy the ARRAY line from, otherwise you have to get that information from the RAID array somehow.

Display More

well I’m lost allready seems like a bigger problem as never had to mess with this before. Will wait for dev/mod input before I attempt a omv4 install again.

+1 other here, fresh install on a flash drive, 2*1TB disks partitions removed in GPared so disk is not initialized and same error message.

I just wanted to comment on this as I also recently tried to move from OMV 2 to OMV 4. Using the base image of OMV 4 installed onto a SSD using a USB image I tried 3 or more times to install the OMV 4 image and I saw the same exact error from above. I had all of the data drives disconnected while installing the OS except for the 1 SSD that was going to be used as the OS drive. Also, that SSD was connected through Sata and not through any raid controllers.

One thing I think may be the problem which maybe someone above can help replicate is that OMV4 won't boot correctly it's first time if an onboard raid card is built into the motherboard. I believe this may be part of the problem because the motherboard I am using actually has a built in LSI raid controller which you can't disable from initializing on boot. Even if you disable it from initializing in the BIOS or loading an OS it will still try to initialize during boot.

After trying the installation several times I tried the OMV 3 image using a USB image and it booted up the first time with no issues. I am not sure why OMV 3 doesn't have the same issue as OMV 4 since it sounds like all of our installations were done using the same hardware as our previous versions of OMV.

Any help on why this may be an issue and how to solve it moving forward would be wonderful in case we want to upgrade to OMV 4.

Quote from ZeroGravitas23

I just wanted to comment on this as I also recently tried to move from OMV 2 to OMV 4. Using the base image of OMV 4 installed onto a SSD using a USB image I tried 3 or more times to install the OMV 4 image and I saw the same exact error from above. I had all of the data drives disconnected while installing the OS except for the 1 SSD that was going to be used as the OS drive. Also, that SSD was connected through Sata and not through any raid controllers.

One thing I think may be the problem which maybe someone above can help replicate is that OMV4 won't boot correctly it's first time if an onboard raid card is built into the motherboard. I believe this may be part of the problem because the motherboard I am using actually has a built in LSI raid controller which you can't disable from initializing on boot. Even if you disable it from initializing in the BIOS or loading an OS it will still try to initialize during boot.

After trying the installation several times I tried the OMV 3 image using a USB image and it booted up the first time with no issues. I am not sure why OMV 3 doesn't have the same issue as OMV 4 since it sounds like all of our installations were done using the same hardware as our previous versions of OMV.

Any help on why this may be an issue and how to solve it moving forward would be wonderful in case we want to upgrade to OMV 4.

Display More

yea very annoying. I had to go back to omv3 since 4 wouldn’t work and doesn’t seem anyone has picked this up.

Fingers crossed someone on the team spots this thread and can help.

Hi there
I have exact same issue here.
New installation using a bootable USB device with the iso in order to install on a SSD.
No other disk at this stage.
Then when booting after the install without the USB in fails with the mdadm: no arrays found in config file or automatically message.
When booting with the key it works.
One thing is that when the key is plugged in, the SSD is on sdb and the key is on sda. I don't know if this is an issue.
When I plug my 4 other drives without the key it fails and with the key it works (even though SSD is then on sdc).
My raid is building. I'll see if this works without the key once done and I'll report it here.

I'm having the same issue with a test setup. I note, however, that:

1. Installing OMV 4 onto a USB DOM: I get the mdadm error message repeatedly and the computer does not complete the boot process (drops to a Busybox prompt). When installing, the USB Flash drive installation media is sda, while the installation target (the USB DOM) is sdb.

2. Installing OMV 4 onto an SSD: No issues. In this instance, the installation media is sdb, while the installation target SSD is sda.

As someone noted above, if they leave the installation media inserted on their machine, OMV booted without error. So, it seems to me that, for some of us in this thread at aleast, OMV 4 is having issues when the drive assignment changes between installation and first boot (in my case the System disk was sdb during install, but became sda once the installation media was removed).

Sadly, I have no idea how to address this.

As an update:

I was able to install successfully by moving the USB Flash drive installation media around the computer's USB ports until I found a combination where the installation target (system drive) came up as sda and the flash drive was sdb.

There may be other issues I didn't find. But for me, simply ensuring the installation target (system disk) was sda fixed it.

Quote from ZeroGravitas23

One thing I think may be the problem which maybe someone above can help replicate is that OMV4 won't boot correctly it's first time if an onboard raid card is built into the motherboard. I believe this may be part of the problem because the motherboard I am using actually has a built in LSI raid controller which you can't disable from initializing on boot. Even if you disable it from initializing in the BIOS or loading an OS it will still try to initialize during boot.

I'm not sure if its a similar situation, but I had an add on card controller (LSI 2008 based controller running in IT mode) connected during my installation attempts. As I noted above, I was able to install successfully, but only when I was able to make the installation target (system disk) come up as sda during the installation.