Bug 106926 - mkinitrd changes for better firewire disk handling
Summary: mkinitrd changes for better firewire disk handling
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: David Lawrence
URL: https://bugzilla.redhat.com/bugzilla/...
Whiteboard:
Depends On: 101227 103821
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-13 17:59 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-02-16 21:41:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2003-10-13 17:59:47 UTC
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 22:10:13 UTC
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-14 00:12:48 UTC
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 17:59:47 UTC
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 16:25:39 UTC
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-18 01:12:15 UTC
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 21:41:09 UTC
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.