Bug 105602

FWIW, a USB disk isn't seen by anaconda either.

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.

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.

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,

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.

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 :-(

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
storage).

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? :-)

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

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?

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. 

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.

I was looking explicitly within the installer environement and poking
around loading modules by hand...  trust me here :-)