Bug 180708
Summary: | hotplug/udev-dependent RAID arrays don't autoassemble on boot (firewire, usb) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bill McGonigle <bill-bugzilla.redhat.com> | ||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 9 | CC: | jonstanley, wtogami | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | MassClosed | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-07-14 17:04:45 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Bill McGonigle
2006-02-09 20:27:03 UTC
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). [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. 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. (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. Confirming this is still an issue in Fedora 8. Re-opening. Created attachment 292609 [details]
kernel messages from boot, no auto-assembly
(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.) 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. 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 I can confirm through 9 at least. 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 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. this has been seen on 10. Drakut may solve it, AIUI. |