Bug 20951 - bad md magic on device at boot time, but RAID0 mounts OK
bad md magic on device at boot time, but RAID0 mounts OK
Product: Red Hat Linux
Classification: Retired
Component: raidtools (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Dale Lovelace
Depends On:
  Show dependency treegraph
Reported: 2000-11-16 08:59 EST by James A Griffin
Modified: 2007-04-18 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-16 09:42:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James A Griffin 2000-11-16 08:59:37 EST
At boot up several error messages (see attached dmesg) indicate "invalid
raid superblock magic on hdcx".  However, later is the process the
bind<hdcx,n> process works although it report "nonpersistent superblock"  I
am then able to mount /dev/md0 /backup.  While I suspect I have some sort
of configuration error, the fact that it works make me think that: 

1.  The autodetection of RAID  arrays does not expect to find nonpersistent
superblock, since no one in their right mind would be using a RAID0
configuration. <grin>
2.  The logic used in the "bind<>" process is more forgiving.

This causes another problem when trying to do an Upgrade install of RH
7.0.  Anaconda finds the bad superblock. (see attached anaconda dump).

[I'm new to using bugzilla and have not figured out how to do attachments
to this form, it seems to me that cut-n-paste is not the way.  I'll try
commit and see if it leads to an attachment selection option.]
Comment 1 Elliot Lee 2001-07-20 12:03:51 EDT
You have to use persistent superblocks to get raid autodetect.

Apologies for the unresponsiveness of the previous raidtools packager...

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