Bug 105602 - firewire-connected external disks are not seen by anaconda
firewire-connected external disks are not seen by anaconda
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-09-25 17:42 EDT by Alexandre Oliva
Modified: 2014-03-16 22:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-11 13:00:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch that enables installing from/to firewire disks (6.03 KB, patch)
2003-10-25 15:54 EDT, Alexandre Oliva
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2003-09-25 17:42:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
Anaconda loads the ieee1394 and uhci1394 modules, but apparently not the sbp2
module, needed for my external firewire enclosure to work.  Even if it did load
sbp2 (I can do it by hand, but i have to use insmod sbp2.o, modprobe sbp2
doesn't work!?!), it would have to run rescan-scsi-bus.sh to get the scsi device
to be enabled, and to create the corresponding /dev/sda* devices, none of which
it seems to do.

Even if I do it all myself before getting the installation started, anaconda
still doesn't offer sda as one of the disks it can install to.  I suppose the
modules are being loaded too late, or something.  I wonder if we should have
these modules in initrd, loaded by linuxrc, when some command-line flag is given
to the kernel (e.g., firewire-storage or usb-storage).
Comment 1 Alexandre Oliva 2003-09-25 18:16:47 EDT
FWIW, a USB disk isn't seen by anaconda either.
Comment 2 Michael Fulbright 2003-09-26 12:26:18 EDT
We have never allowed you to install to a usb-storage or sbp2 device.

I understand the firewire stuff is pretty horked in the kernel at the moment.
Comment 3 Tom Cullen 2003-09-28 00:00:50 EDT
SBP2-related devices that worked fine in RH9 (all releases) refuse to function 
in RH 9.0.93 and Fedora Core 0.94.

Affect the following machine:
SONY Picturebook C1MW (This machine has external firewire DVD/CD-RW drive)
Fedora Core 0.94 and RH 9.0.93 will boot, and will not let you proceed past 
adding additional drivers for USB & UHCI. I *DID* manage to install on this 
machine using iso's on a small partion. KUDZU will not detect this external 
firewire drive during boot, and actually hangs the machine. KUDZU run in a term 
also hangs, but not the entire machine. Additionally, insmod and modprobe do 
not "see" the drive. Maybe I'm just plain silly for attempting an install on 
this machine, but I've been able to get everything to work except for the 
camera and this firewire port.
Comment 4 Alexandre Oliva 2003-09-28 02:57:35 EDT
Tom, you probably want to have a look at bugs 103821.

Michael, do you mean anaconda actually active refuses to have even RAID members
in external storage devices?  I hope you'd agree that this can be a very useful
thing to do.  I don't actually see why anaconda would refuse to enable someone
to create filesystems in external disks.  I realize additional magic might be
necessary to get them to be usable for the root filesystem, but this hopefully
wouldn't be too hard either.  Anyway, this report is not about not being able to
install root filesystems in external devices, it's about raid devices that work
perfectly well after installation not being recognized by the raid detection
code in anaconda, and this probably has to do with its not seeing (or refusing
to see) USB or Firewire disks.  If it actively refuses to consider them, would
you please provide me with a pointer to the code, such that I could try to work
around that somehow?  Thanks,
Comment 5 Jeremy Katz 2003-09-29 16:53:13 EDT
Yes, USB and Firewire are completely thrown out of consideration as disks for
the system in anaconda except in expert mode (see isys/isys.py:driveIsRemovable()).

Of course, the whole thing is more complicated now (and somewhat validated ;) by
the rescan-scsi-bus nonsense you have to do for firewire disks :/

Going to add something so that firewire cds can at least be used as install
sources again, though.
Comment 6 Alexandre Oliva 2003-10-18 17:39:36 EDT
Thanks for the pointer to driveIsRemovable(), now I see that, if I enter expert
mode, it *will* indeed enable me to install to removable drives, and this
actually works if I connect the external disk enclosure as USB, but not as
Firewire, even if I load the modules and rescan the bus as quickly as possible
after it gives me a shell prompt on VT2.  I've managed to do it all before
anaconda switches to VT7 for the graphical install, but it seems to not be early
enough.  There seems to be some probing and disk enumeration that takes place
far too early in the process for me to be able to get the scsi device for the
firewire disk in place in time for it to be considered and, if I miss this
window of opportunity, the disk won't be reconsidered, ever.  Any ideas on how
to overcome this?  I suppose I could use USB for installs and be done with it,
but USB 1.1 (the best I have on this laptop) is painfully slow :-(
Comment 7 Alexandre Oliva 2003-10-25 15:54:02 EDT
Created attachment 95481 [details]
patch that enables installing from/to firewire disks

This patch should enable the anaconda loader to install from firewire CDs, as
well as to firewire hard disks (only in expert mode, like any other removable
Comment 8 Alexandre Oliva 2004-02-16 16:44:19 EST
Most of the patch is no longer needed for FC2, but the bit that loads
the sbp2 module is still necessary.  It does work to modprobe sbp2 to
install into firewire hard disks, with kickstart or in VT2, but if you
need sbp2 loaded to get to stage2 (e.g., if your CD-ROM is a firewire
device; not my case, but...), there's no way to do it.  Pretty please,
with sugar on top? :-)
Comment 9 Jeremy Katz 2004-02-17 20:00:53 EST
Nope, kudzu needs to be fixed to probe it right since it can...

Instead of /proc/bus/ieee1394, you now have to recurse into the
directory structure of /sys/bus/ieee1394
Comment 10 Alexandre Oliva 2004-02-17 23:57:07 EST
Well, it didn't work in kernel 2.4 the way it was, so why do you
expect changing kudzu so as to probe it elsewhere would fix the problem?
Comment 11 Jeremy Katz 2004-02-18 10:41:51 EST
No, it worked that way in 2.4 until the big "let's break firewire in
2.4" bit ;-)  And I've verified that grokking through
/sys/bus/ieee1394 after just loading the ohci1394 host adapter does in
fact show the drive which needs sbp2.

Hence, fixing the kudzu probe will fix the problem. 
Comment 12 Alexandre Oliva 2004-02-18 16:39:51 EST
Well...  When I tried to add just rescan-scsi-bus to the firewire
start up code for FC1 in the installer, it wasn't enough.  And I see
/etc/rc.sysinit explicitly modprobes sbp2.
Comment 13 Jeremy Katz 2004-02-18 17:59:46 EST
I was looking explicitly within the installer environement and poking
around loading modules by hand...  trust me here :-)

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