Bug 180708 - hotplug/udev-dependent RAID arrays don't autoassemble on boot (firewire, usb)
hotplug/udev-dependent RAID arrays don't autoassemble on boot (firewire, usb)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
MassClosed
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-09 15:27 EST by Bill McGonigle
Modified: 2009-08-14 06:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:04:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kernel messages from boot, no auto-assembly (26.20 KB, application/octet-stream)
2008-01-23 01:33 EST, Bill McGonigle
no flags Details

  None (edit)
Description Bill McGonigle 2006-02-09 15:27:03 EST
+++ This bug was initially created as a clone of Bug #174537 +++

If you have a raid array that's under something handled by udev (firewire,
probably USB) it won't be autoassembled on boot.

With a stock fc4, under 2.6.15 the drives are properly detected, assigned sda
and sdb in this case, but with sdb1 and sdb2 marked with partition type fd, no
autodetection happens.

Just having /dev/md3 in /etc/fstab will cause the system to drop to a single
user repair-disk shell on boot since it can't find the device, even with the
noauto option (either another bug or I don't really understand noauto).  A
normal boot with an fstab entry will have no /dev/md3 device created
(/dev/md[0-2] are IDE on this system).

In the most manual case, this certainly works:
   mdadm --assemble /dev/md3 /dev/sda1 /dev/sdb1 
but 'manual' is the object of avoidance here.

As a workaround, I'm using a mdadm.conf like:
  DEVICE partitions
  ARRAY /dev/md3 level=raid1 num-devices=2 UUID=24674bf8:caaa8927:d9cee427:baf19e61

And in /etc/rc.d/rc.local:
  # try looking for raid set again
  /sbin/mdadm --assemble --scan --auto
  if [ -b /dev/md3 ]; then
      mount /dev/md3 /mnt/backup
  fi

I've tried adding --auto to the mdadm call in rc.sysinit, but it seems to be too
early to have an effect.

Anyhow, I understand some of why this is happening this way, but the bottom line
is you have to give up autoassembly of RAID and the use of fstab just because of
the bus type the drive is on, and that's not a great situation (fstab was a
great invention).

Some talk about this on the hotplug list:
  http://sourceforge.net/mailarchive/message.php?msg_id=14630152
and on the Debian list:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273182
(another proposed hackaround there) led me to file this under the 'kernel'
component, but I'm not married to a kernel solution if there's smarter way.
Comment 1 Bill McGonigle 2006-02-09 15:33:53 EST
Sorry, I missed a typo in the above:

sub:
  A normal boot with an fstab entry will have 
  no /dev/md3 device created (/dev/md[0-2] are 
  IDE on this system).
with:
  A normal boot WITHOUT an fstab entry will have 
  no /dev/md3 device created (/dev/md[0-2] are 
  IDE on this system).
Comment 2 Dave Jones 2006-09-16 22:15:08 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 3 Dave Jones 2006-10-16 14:22:34 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 4 Jon Stanley 2008-01-19 23:39:42 EST
(this is a mass-close to kernel bugs in NEEDINFO state)

As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

If you believe that this bug was closed in error, please feel free to reopen
this bug.
Comment 5 Bill McGonigle 2008-01-23 01:30:28 EST
Confirming this is still an issue in Fedora 8.  Re-opening.  
Comment 6 Bill McGonigle 2008-01-23 01:33:21 EST
Created attachment 292609 [details]
kernel messages from boot, no auto-assembly
Comment 7 Chuck Ebbert 2008-01-23 14:41:42 EST
(In reply to comment #0)
> 
> Just having /dev/md3 in /etc/fstab will cause the system to drop to a single
> user repair-disk shell on boot since it can't find the device, even with the
> noauto option (either another bug or I don't really understand noauto).

What does the fstab entry say exactly? If the last field is not 0, fsck will be
run on the filesystem. If it is zero it should just be skipped. (And it really
should be using a label, not a fixed device name.)
Comment 8 Bill McGonigle 2008-01-23 17:09:21 EST
So, for instance:

LABEL=backup            /mnt/backup             ext3    data=journal,noatime    1 2

Will cause a drop to the single user shell on boot because LABEL=backup, which
is on /dev/md3 (a RAID-10, and described in mdadm.conf), doesn't exist yet.  I
do think that boot-time fsck has value, so that shouldn't be forfeit based on
bus protocol.

As I understand it, first udev has to detect the USB drives, then if mdadm auto
assembly is run again it will run the mirrors.  Actually, for this RAID-10, it
has to be run twice because the first time it finds the RAID-1 mirrors, then the
second time it can figure out how to assemble the RAID-0 on top of it.

For RAID auto-assembly to work uniformly across topologies, drives handled by
udev these days (usb, firewire, others?) need to be recognized before RAID
auto-assembly happens. Back in the day before udev, IIRC the kernel recognized
the drives and it worked as one might expect.

Actually, I don't really know how possible that is in the kernel vs. just doing
it in init scripts (I don't really understand where udev hooks in).  Probably,
at least, the fsck stage should be delayed until udev has had a chance to get
drives online.

That mdadm's assembly mode ought to be multi-pass until a stable solution is
achieved is probably a separate bug.
Comment 9 Bug Zapper 2008-11-26 01:55:04 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bill McGonigle 2008-11-26 02:31:39 EST
I can confirm through 9 at least.
Comment 11 Bug Zapper 2009-06-09 18:06:41 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2009-07-14 13:04:45 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 13 Bill McGonigle 2009-08-14 06:34:33 EDT
this has been seen on 10.   Drakut may solve it, AIUI.

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