Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79176 - Mount and ieee1394 devices on boot
Summary: Mount and ieee1394 devices on boot
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-06 20:01 UTC by Stephen John Smoogen
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-05-25 14:52:57 UTC

Attachments (Terms of Use)

Description Stephen John Smoogen 2002-12-06 20:01:53 UTC
Description of Problem:

Installer found diskdrives on my firewire chain and I was able to add them as
/scratch and /home. During the firstboot, the machine went to single user mode
because rc.sysinit could not find those drives. Pretty obvious why, as the
ieee1394 modules had not been installed. 

The problem could be one of several packages:

1) anaconda should put drives found on ieee1394 chains as no-auto in /etc/fstab
and not allow for needed directories be put on it. The argument would be that
ieee1394 is a plug and pray tree, and the devices are not promised to be there
after boot. However, if someone is silly enough to want them to be permanent..
that is a different matter.

2) mkinitrd or the call to it in anaconda should include ieee1394 modules when
the initial ramdisk is made.

3) initscripts should load the modules before trying to do a mount.

4) ???

Comment 1 Stephen John Smoogen 2002-12-07 03:29:59 UTC
This bug may actually be with initscripts as the ieee1394 driver is in the
initrd.img but the ohci1394 is not looked at until after all the mounting is
done in rc.sysinit.

Comment 2 Stephen John Smoogen 2002-12-07 04:47:33 UTC
Ok I am very confused now. Looking at the initrd.img itself I see lines like:

echo "Loading scsi_mod module"
insmod /lib/scsi_mod.o
echo "Loading sd_mod module"
insmod /lib/sd_mod.o
echo "Loading ieee1394 module"
insmod /lib/ieee1394.o
echo "Loading ohci1394 module"
insmod /lib/ohci1394.o
echo "Loading sbp2 module"
insmod /lib/sbp2.o
echo "Loading jbd module"
insmod /lib/jbd.o
echo "Loading ext3 module"
insmod /lib/ext3.o

And looking at dmesg the device is found, the firewire drive is seen BUT by the
time that initscripts gets to here.. it isnt seen anymore. I have NO idea what
group it belongs to now.

# Ooh, firewire too.
aliases=`/sbin/modprobe -c | awk '/^alias ieee1394-controller/ { print $3 }'`
if [ -n "$aliases" -a "$aliases" != "off" ]; then
      for alias in $aliases ; do
        [ "$alias" != "off" ] && action $"Initializing firewire controller
($alias): " modprobe $alias
      grep -q "SBP2" /proc/bus/ieee1394/devices 2>/dev/null && modprobe sbp2
>/dev/null 2>&1


I was wondering if I missed something in the logic above. We test for aliases
!="off" twice in a nested if/for loop. Shouldnt it always be true if it got past
the first if?

Comment 3 Stephen John Smoogen 2002-12-07 05:12:43 UTC
Played around with the order of the items in linuxrc and did not have any
effect. Removing the modules after bootup, and re-doing them by hand causes the
device to be seen and added correctly to the /proc/scsi/scsi tree

Its late.. good luck with the ice-cleanup in NC.

Comment 4 Michael Fulbright 2002-12-09 20:25:17 UTC
This was something which was a side-effect of loading the ieee1394 support for
CDROMs in the installer. We do not intend to support ieee1394 hard drives in
future releases.

Comment 5 Jeremy Katz 2002-12-16 22:18:31 UTC
Code is in place to prevent this problem in CVS

Comment 6 Michael Fulbright 2002-12-20 17:38:25 UTC
Time tracking values updated

Comment 7 Brent Fox 2003-05-25 14:52:57 UTC
I'm going through Bugzilla closing some bugs that have been marked as Modified
for some period of time.  I believe that most of these issues have been fixed,
so I'm resolving these bugs as Rawhide.  If the bug you are seeing still exists,
please reopen this report and mark it as Reopened.

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