Bug 106926 - mkinitrd changes for better firewire disk handling
mkinitrd changes for better firewire disk handling
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
David Lawrence
https://bugzilla.redhat.com/bugzilla/...
:
Depends On: 101227 103821
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-13 13:59 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-16 16:41:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-10-13 13:59:47 EDT
Description of problem:
Bug 103821 has the whole story.  The attachment in the URL above patches
mkinitrd such that it handles some of the recent changes in the way the kernel
handles firewire hard disks, such as not hanging during boot with a firewire
disk connected to the system, or supporting root devices in (raid devices and/or
volume groups in) external firewire disks.
Comment 1 Jeremy Katz 2003-10-13 18:10:13 EDT
Hmmm, this all smells like "huge hack" to me which means the kernel won't get
fixed and instead the problem will just get ignored.  mkinitrd has enough hacks
without more.  Why should firewire be different from every other storage adapter
in the kernel as far as scanning the bus on module insertion?

For now, blocking on kernel bugs.  If they don't move anywhere before release,
I'll see this again in my passthrough of open mkinitrd bugs.
Comment 2 Alexandre Oliva 2003-10-13 20:12:48 EDT
It is my understanding that the need for userland rescan is one of those
can't-fix-in-2.4 (or at least that's what the sbp2 maintainer claims; I don't
have a URL handy :-(.  The order of loading modules is indeed an ugly hack, but
since this hasn't been fixed yet in spite of the age of the bug report, and I
don't know that anyone is actually working to fix it, I don't see that we'll
have a fix in place in time for the release.  And then, this is not the kind of
change you shoiuld make to mkinitrd just before a release, so perhaps now is the
time to put it in.  We can always revert it later (and I promise to monitor
kernels until the release and let you know it can be reverted if the kernel bug
is fixed).
Comment 3 Matthew Galgoci 2003-10-16 13:59:47 EDT
Out of morbid curiosity, where did you find a bootable firewire controller
for x86? What's the make/model/manufacturer? I've been looking for one so
I can actually test this scenario, but have been unable to find such a beast.
Comment 4 Alexandre Oliva 2003-10-17 12:25:39 EDT
I can't boot off of it, but I can still use it for the root filesystem, or for
physical volumes or raid members that I'd like to have available at boot time.
Comment 5 Alexandre Oliva 2003-10-17 21:12:15 EDT
Patch broken up in smaller, (almost) independent pieces and attached a tarball
with them all to bug 103665.  Should this bug be closed now?
Comment 6 Alexandre Oliva 2004-02-16 16:41:09 EST
None of these are needed in FC2test1 any more.  All I have to do to
get firewire disks to be brought up early in the boot is to mkinitrd
--with=sd_mod --with=sbp2.  Yay!

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