mdadm: no arrays found in config file or automatically

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • mdadm: no arrays found in config file or automatically

      This is a fresh install ov OMV 4.0.9 to USB flash drive. During the install I had internal HD removed. With the HD removed boot generated no errors. After installing the HD I get the following error during boot. It repeats the same error message about 30 - 40 times before finishing the boot:

      mdadm: no arrays found in config file or automatically

      As elsewhere suggested I modified /etc/mdadm/mdadm.conf to include:

      # definitions of existing MD arrays
      ARRAY <ignore> devices=/dev/sda

      Then I did: omv-mkconf mdadm

      This generated the follwing error:

      mdadm /etc/mdadm/mdadm.conf defines no arrays

      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.

      Any idea how get rid off this error at boot?

      Thanks
    • 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.
      OMV 3.0.58 - 64 bit - Nut, SABnzbd, Sonarr, Couchpotato
      HP N40L Microserver, 8gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)

      The post was edited 1 time, last by chclark ().

    • 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.
      OMV 3.0.58 - 64 bit - Nut, SABnzbd, Sonarr, Couchpotato
      HP N40L Microserver, 8gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)
    • 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 : abyssproject.net/2017/03/prepa…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

      The post was edited 1 time, last by toibs ().

    • toibs wrote:

      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 : abyssproject.net/2017/03/prepa…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
      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.
      OMV 3.0.58 - 64 bit - Nut, SABnzbd, Sonarr, Couchpotato
      HP N40L Microserver, 8gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)
    • 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).

      Shell-Script

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

      z0rk wrote:

      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.
    • gderf wrote:

      chclark wrote:

      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?
      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.
      OMV 3.0.58 - 64 bit - Nut, SABnzbd, Sonarr, Couchpotato
      HP N40L Microserver, 8gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)
    • 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

      Source Code

      1. # definitions of existing MD arrays
      2. 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.

      The post was edited 2 times, last by curlymike ().

    • curlymike wrote:

      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

      Source Code

      1. # definitions of existing MD arrays
      2. 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.
      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.
      OMV 3.0.58 - 64 bit - Nut, SABnzbd, Sonarr, Couchpotato
      HP N40L Microserver, 8gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)
    • +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.
      Linux openmediavault 4.15.0-0.bpo.2-amd64 #1 SMP Debian 4.15.11-1~bpo9+1 (2018-04-07) x86_64 GNU/Linux
      hp proliant N40L 8GB ram on 64GB flashAMD Turion(tm) II Neo N54L Dual-Core Processor
      More abut me: etiennebretteville.com
    • 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.
    • ZeroGravitas23 wrote:

      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.
      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.
      OMV 3.0.58 - 64 bit - Nut, SABnzbd, Sonarr, Couchpotato
      HP N40L Microserver, 8gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)
    • 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.
      Working with computers since the days when unboxing and set-up required 3 weeks with a soldering iron!
    • 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.

      ZeroGravitas23 wrote:

      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.
      Working with computers since the days when unboxing and set-up required 3 weeks with a soldering iron!