This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 224272 - Boot message "mdadm: No arrays found in config file"
Boot message "mdadm: No arrays found in config file"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
6
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Doug Ledford
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-24 18:11 EST by Davide Bolcioni
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.2-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-20 15:35:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
mdadm.conf (316 bytes, text/plain)
2007-01-24 18:11 EST, Davide Bolcioni
no flags Details

  None (edit)
Description Davide Bolcioni 2007-01-24 18:11:06 EST
Description of problem: When booting, the message "mdadm: No arrays found in 
config file" appears after the hostname is set. In spite of the message, my MD 
arrays are OK.


Version-Release number of selected component (if applicable):
mdadm-2.5.4-2.fc6

How reproducible:
At every boot.

Steps to Reproduce:
1. Reboot
2.
3.
  
Actual results:
mdadm: No arrays found in config file ... and a heart attack :-)

Expected results:
No such worrisome message.

Additional info: Please see attached mdadm.conf, which was generated by 
Anaconda upon upgrading from Fedora Core 5. The UUIDs match.
Comment 1 Davide Bolcioni 2007-01-24 18:11:06 EST
Created attachment 146472 [details]
mdadm.conf
Comment 2 Curtis Doty 2007-02-09 23:09:49 EST
I see this too. At first, I though this was a bug in the initscripts. But a
closer look makes me thing it is in mdadm.c.

This bug appears to occurs when you have md devices that are already loaded
properly in the kernel initrd. *And* when your /etc/mdadm.conf exists (i.e.
anaconda was nice enough to set it up for you automatically).

Now you don't want to delete the /etc/mdadm.conf since it is needed for
mdmonitor functionality--very important. But...

mdadm.c appears to generically spit out this error when it *really* means that
/dev/md0 didn't *need* to be running--because it was already.

Maybe a patch to mdadm.c to make it quiet when the auto-assemble routines run,
but md devices are already running?
Comment 3 Doug Ledford 2007-07-03 13:10:24 EDT
I'm preparing a new version of mdadm for an update.  It will be 2.6.2-2 (or
later).  I don't see this behavior with that version.  Instead, if you call
mdadm -As without a specific raid device, it silently ignores any that are
running.  If you call mdadm -As /dev/md<blah>, it will report:

[root@firewall lost+found]# mdadm -As /dev/md0
mdadm: device /dev/md0 already active - cannot assemble it
[root@firewall lost+found]# 

So, I believe this will be resolved by the update.  If I'm wrong, please reopen.
Comment 4 Fedora Update System 2007-07-05 15:12:20 EDT
mdadm-2.6.2-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fedora Update System 2007-07-09 11:47:58 EDT
mdadm-2.6.2-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 6 Fedora Update System 2007-07-10 02:42:20 EDT
mdadm-2.6.2-4.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2007-07-20 15:35:22 EDT
mdadm-2.6.2-4.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.