Red Hat Bugzilla – Bug 79176
Mount and ieee1394 devices on boot
Last modified: 2007-04-18 12:48:54 EDT
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) ???
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.
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 done grep -q "SBP2" /proc/bus/ieee1394/devices 2>/dev/null && modprobe sbp2 >/dev/null 2>&1 fi ---> 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?
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.
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.
Code is in place to prevent this problem in CVS
Time tracking values updated
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.