Bug 79176 – Mount and ieee1394 devices on boot

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 79176 - Mount and ieee1394 devices on boot

Summary:	Mount and ieee1394 devices on boot

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	anaconda (Show other bugs)
Sub Component:
Version:	8.0
Hardware:	i386 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Jeremy Katz
QA Contact:	Mike McLean
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2002-12-06 15:01 EST by Stephen John Smoogen
Modified:	2007-04-18 12:48 EDT (History)
CC List:	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)
Add an attachment (proposed patch, testcase, etc.)

Groups: 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.