Bug 79176

Summary:	Mount and ieee1394 devices on boot
Product:	[Retired] Red Hat Linux	Reporter:	Stephen John Smoogen <smooge>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-05-25 14:52:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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

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.