Bug 79176 - Mount and ieee1394 devices on boot
Mount and ieee1394 devices on boot
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-06 15:01 EST by Stephen John Smoogen
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-25 10:52:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen John Smoogen 2002-12-06 15:01:53 EST
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-06 22:29:59 EST
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-06 23:47:33 EST
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 00:12:43 EST
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 15:25:17 EST
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 17:18:31 EST
Code is in place to prevent this problem in CVS
Comment 6 Michael Fulbright 2002-12-20 12:38:25 EST
Time tracking values updated
Comment 7 Brent Fox 2003-05-25 10:52:57 EDT
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.