Bug 173085 - Missing firewire hard disk with latest kernel
Summary: Missing firewire hard disk with latest kernel
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Depends On: 185500
TreeView+ depends on / blocked
Reported: 2005-11-13 22:37 UTC by David Bentley
Modified: 2013-03-06 03:44 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2007-04-03 00:18:13 UTC

Attachments (Terms of Use)
messages.txt as atachment (6.01 KB, text/plain)
2005-11-13 22:44 UTC, David Bentley
no flags Details
pertinent section of /var/log/messages (8.28 KB, text/plain)
2005-11-16 20:17 UTC, Tom Wood
no flags Details
messages.txt from FC5T2 fully updated from rawhide 15/2/06 (37.11 KB, text/plain)
2006-02-15 21:43 UTC, David Bentley
no flags Details
lshal.txt (109.74 KB, text/plain)
2006-02-15 21:54 UTC, David Bentley
no flags Details
dmesg outpt when hotpluging and unpluging (599 bytes, text/plain)
2006-02-16 00:15 UTC, David Bentley
no flags Details
lshal.txt (109.93 KB, text/plain)
2006-03-06 00:25 UTC, David Bentley
no flags Details
sdc1.txt (712 bytes, text/plain)
2006-03-06 00:27 UTC, David Bentley
no flags Details
new output from hald (3.64 KB, text/plain)
2006-03-06 11:58 UTC, David Bentley
no flags Details
output from an initial root login for comparison. (4.84 KB, text/plain)
2006-03-06 12:42 UTC, David Bentley
no flags Details
output from an initial root login for comparison. (3.70 KB, text/plain)
2006-03-06 13:13 UTC, David Bentley
no flags Details
messages.txt (1.75 KB, text/plain)
2006-03-06 15:39 UTC, David Bentley
no flags Details
AVC message found. (715 bytes, text/plain)
2006-03-06 16:10 UTC, David Bentley
no flags Details

Description David Bentley 2005-11-13 22:37:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
one of my two external firewire hard disk is not now accessible

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Boot with firewire hard disks attached

Actual Results:  Only one accessible

Expected Results:  Both to be accessible

Additional info:

Appropriate ouput from the messages for kernel-2.6.14-1.1637_FC4 and the previous kernel (kernel-2.6.13-1.1532_FC4) will be added as an atacment later.

Comment 1 David Bentley 2005-11-13 22:44:38 UTC
Created attachment 121000 [details]
messages.txt as atachment

output from messages.

Comment 2 Tom Wood 2005-11-16 20:16:28 UTC
I have the same problem with close to the same content in /var/log messages. 
Attaching appropriate portion of my /var/log/messages.

Comment 3 Tom Wood 2005-11-16 20:17:29 UTC
Created attachment 121146 [details]
pertinent section of /var/log/messages

Comment 4 André Fettouhi 2005-11-17 16:45:26 UTC
Same problem here with my external 200 GB Maxtor HD. 

dmesg gives

ieee1394: The root node is not cycle master capable; selecting a new root node
and resetting...
ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0010b920003dc402]
ieee1394: Host added: ID:BUS[0-01:1023]  GUID[434fc0000eb7c010]
SCSI subsystem initialized
sbp2: $Rev: 1306 $ Ben Collins <bcollins@debian.org>
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03812a0(lo)
IPv6 over IPv4 tunneling driver
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: Maxtor    Model: 5000DV            Rev: 0100
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
Attached scsi generic sg0 at scsi0, channel 0, id 1, lun 0,  type 14

plugging it in again gives

ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[0010b920003dc402]
ohci1394: fw-host0: SelfID received, but NodeID invalid (probably new bus reset
occurred): 0000FFC0
ieee1394: The root node is not cycle master capable; selecting a new root node
and resetting...
ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[0010b920003dc402]
scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: Maxtor    Model: 5000DV            Rev: 0100
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
Attached scsi generic sg0 at scsi1, channel 0, id 1, lun 0,  type 14

trying to mount it manually as su -


[root@andre-notebook ~]# mount /dev/sda1 /mnt/firewireHD -t ntfs -r -o uid=gd1331
mount: special device /dev/sda1 does not exist

Kind Regards

André Fettouhi

Comment 5 Paul W. Frields 2005-12-01 18:26:09 UTC
Just updated from kernel-2.6.14-1.1532_FC4 to kernel-2.6.14-1.1637_FC4 on one of
my FC4 systems which has two IEEE1394 disks attached.  Prior to the upgrade,
they operated normally as /dev/sda and /dev/sdb, but are now detected as
character devices /dev/sg0 and /dev/sg1.  The disks are attached via the sbp2
module as in the previous comments.

The problem persists in kernel-2.6.14-1.1644_FC4 as well, no changes.  Can post
message log snippets if necessary.

Comment 6 David Bentley 2006-01-02 10:39:01 UTC
I suspect this same problem also exists in rawhide but as I can't yet get a 
successful network install (may have to wait for FC5test2) on the system I am 
useing as my FC5 test system.

If so I will file as a seperate bug either against rawhide or FC5test2 as 
appropriate when I next get it installed.

Comment 7 David Bentley 2006-01-22 16:15:06 UTC
I have now got FC5T2 plus updates installed on the system that I usually have my 
firewire drives attached to and although they are visible in the hardware browser
they are not available to mount.

Updating to FC5T2

Comment 8 David Bentley 2006-01-29 23:22:03 UTC
Since kernels get updated almost daily now and it is still a problem as of 29/1/06
I am moving this to devel rather than FC5T2.

Comment 9 Dave Jones 2006-02-01 05:53:14 UTC
I think this is a udev problem.  I brought 174537 up with the upstream firewire
maintainer (which looks like a dupe). Here's what he had to say..


Does it help if sd_mod is loaded? The problem here to me looks like that
the hotplug scripts aren't recognizing type 14 (TYPE_RBC) is a disk
type. This is caused by a chance in the scsi layer where it started
handling a scsi command conversion that sbp2 used to handle itself (it
really belonged in scsi).

I think the disks/cdrom's are working for these people, just that
hotplug needs to be squared away. We have this on Ubuntu,
in /etc/udev/rules.d/90-modprobe.rules:

# Load SCSI class modules based on the device class
SUBSYSTEM!="scsi_device", GOTO="scsi_device_end"
SYSFS{type}=="0|7|14",                  RUN+="/sbin/modprobe -Qba sd_mod"
SYSFS{type}=="1",                       RUN+="/sbin/modprobe -Qba st"
SYSFS{type}=="[345]",                   RUN+="/sbin/modprobe -Qba sr_mod"
SYSFS{type}=="?*",                      RUN+="/sbin/modprobe -Qba sg"

You can see where type 14 is classed as the sd_mod, instead of falling
through to sg.


Harald ?

Comment 10 André Fettouhi 2006-02-05 16:06:26 UTC
Just tested my firewire with the latest version of the kernel and udev for FC4
and latest hal from nrpms.net and now after many weeks my firewire works again.
I can see my Maxtor 200 GB disk. I didn't have to load sb_mod. Many thanks.


André Fettouhi

Comment 11 Stefan Richter 2006-02-14 19:33:02 UTC
I don't see exactly from the log in comment #1 why one of the disks should be
inaccessible. Both are made available, one as /dev/sdc[1,2], the other as
/dev/sdd[1]. Do you miss auto-loading by hal? Hal is affected by the same issue
as Dave describes in comment #9. One of the two disks is reported as type 14
(Direct-Access-RBC) instead type 0 (Direct-Access).

The problem reported by Tom Wood in comment #2 / #3 looks different. Seems more
like a problem that was fixed in the current 1394 development drivers just two
days ago: http://marc.theaimsgroup.com/?t=113969290200003

Tom, if you know how to patch and build kernels, you could either try to apply
the mentioned patch alone (might fail on "older" kernels) or fetch a current
1394 driver patch from http://me.in-berlin.de/~s5r6/linux1394/updates/ . After
building and installing the patched kernel modules, unload all 1394 modules
including sbp2 (check with "lsmod | grep 1394" which ones), then load sbp2 with
"modprobe sbp2 force_inquiry_hack=1", then load ohci1394. --- Do not do this if
you never built a kernel from sources.

Comment 12 Harald Hoyer 2006-02-15 11:36:57 UTC
This is in rawhide...

ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="0|7|14", \
        RUN+="/sbin/modprobe sd_mod"

Do you still have the problems?

Comment 13 David Bentley 2006-02-15 17:19:26 UTC
I will test things later this evening after getting the latest updates as the
haldaemon was not running after yesterdays updates.

I read somewhere that this was an SELINUX problem that will be fixed in the
next policy update (in todays RAWHIDE hopefully but no build system report
in either the devel-list or test-list yet as of 17:20 GMT)

Comment 14 David Bentley 2006-02-15 21:43:32 UTC
Created attachment 124710 [details]
messages.txt from FC5T2 fully updated from rawhide 15/2/06

Comment 15 David Bentley 2006-02-15 21:54:45 UTC
Created attachment 124712 [details]

output fom lshal

Comment 16 David Bentley 2006-02-15 22:37:45 UTC
Both  of the firewire devices are visible in the scsi section of the hardware
browser along with the scsi card in the system.

Adaptec AHA-2940U/UW/D /AIC-7881U driver aic 7xxx
EZ2 Disk FW HDD driver sbp2
OXFORD IDE Device LUN 0 driver sbp2

and the line from comment #12 is in 50-udev.rules allong with the following line

ACTION=="add", SUBSYSTEM="scsi" , SYSFS{type}=="0|7|14", RUN+="/bin/sh -c 'echo
60 > /sys$$DEVPATH/timeout'"

does this have any adverse effects. 

Comment 17 David Bentley 2006-02-15 22:54:00 UTC
Forgot to say that although the brige boards show up in the hardware browswer
none of the drives show up in the hard disk section and none appear in either 
media or mnt nor in the computer folder where I would expect them to be nor are
they visible on the desktop when hotpluged (they used to appear this way in core
4 prior to the 2.6.14 kernel updates.

My USB flash disk appears in computer OK when hotpluged but does not mount on
the desktop until opened (this is the same behavior as a data CD except you dont
get any indication of media insertion it just opens when clicked then appears 
on the desktop)

Presumably this is the expected behavior for gnome 2.13

Comment 18 David Bentley 2006-02-16 00:15:08 UTC
Created attachment 124727 [details]
dmesg outpt when hotpluging and unpluging

Comment 19 Stefan Richter 2006-02-16 08:13:40 UTC
About comment #18: Either you cut too much from the dmesg --- notably messages
from sbp2, scsi_mod, sd_mod --- or whatever tool is responsible for this on FC
fails to load sbp2 and/or sd_mod.

I run a slightly outdated Mandrake system which uses
/etc/hotplug/{ieee1394,scsi}.agent to load these modules. Since Linux 2.6.14 the
scsi.agent had to be extended to load sd_mod for SCSI devices of type 14, i.e.
RBC devices.

Comment 20 David Bentley 2006-02-16 14:22:00 UTC
No the ouput shown in attacment #18 is only what is shown and if you look in 
the lshal output it appears no drivers get loaded.

To get dmseg output I booted the system without the drives attached (after 
adding enforcing=0 as a boot option as selinux is breaking hal presently) ran 
dmseg in one window pluged the drives in and out in the reverse order (the 
drives are dairy chained) and ran dmseg again after saving the output and cut 
and pasted the lines into the file that were the only diference between the two
at the end of what was displayed.

Comment 21 Stefan Richter 2006-02-16 17:06:53 UTC
I.e. autoloading of IEEE 1394 drivers does not work for you; perhaps also not
autoloading of SCSI drivers. Here is some information about driver autoloading
which is not specific to FC (since I never used FC or RH myself):

In order to autoload IEEE 1394 high-level drivers (protocol drivers) by
userspace helpers (hotplug scripts or udev scripts), the ieee1394 base driver
generates hotplug events with the following environment variables set:

MODALIAS. (MODALIAS was added in Linux 2.6.14.) The userspace helpers may either
evaluate the new MODALIAS which is generated like this:
	snprintf(buf, sizeof(buf), "ieee1394:ven%08Xmo%08Xsp%08Xver%08X",
	PUT_ENVP("MODALIAS=%s", buf);
or directly SPECIFIER_ID and VERSION. IEEE 1394 high-level drivers match the
following specifier IDs and versions:

driver   :   specifier ID   :   version
eth1394   :   0x00005e   :   0x000001
dv1394   :   0x00a02d   :   0x010001
raw1394   :   0x00a02d   :   0x010001
raw1394   :   0x00a02d   :   0x000100
raw1394   :   0x00a02d   :   0x000101
raw1394   :   0x00a02d   :   0x000102
video1394   :   0x00a02d   :   0x000100
video1394   :   0x00a02d   :   0x000101
video1394   :   0x00a02d   :   0x000102
sbp2   :   0x00609e   :   0x010483

Note: dv1394 will soon be deprecated due to availability of libraw1394 clients
with comparable functionality. dv1394 will be removed from the kernel at some point.

Once sbp2 is loaded because a FireWire node with the mathcing specifier ID and
version was detected, sbp2 logs in into the device and creates SCSI devices. The
scsi_mod base driver checks device and creates a sysfs entry with a few
attributes, among them the "type" attribute. Userspace helpers may evaluate the
type and load SCSI high-level drivers (command set drivers) according to the type:

TYPE_PROCESSOR=3      #/* HP scanners use this */
TYPE_WORM=4           #/* Treated as ROM by our system */
TYPE_MOD=7            #/* Magneto-optical disk - treated as TYPE_DISK */

    case "$TYPE" in
        $TYPE_DISK)     MODULE=sd_mod ;;
        $TYPE_TAPE)     MODULE=st ;;
        $TYPE_PRINTER)  MODULE=sg ;;
        $TYPE_WORM)     MODULE=sr_mod ;;
        $TYPE_ROM)      MODULE=sr_mod ;;
        $TYPE_SCANNER)  MODULE=sg ;;
        $TYPE_MOD)      MODULE=sd_mod ;;
        $TYPE_CHANGER)  MODULE=sg ;;
        $TYPE_COMM)     ;;
        $TYPE_RBC)      MODULE=sd_mod ;;

Note: Some tapes actually use osst instead of st.

Comment 22 Stefan Richter 2006-02-16 17:15:03 UTC
In the above example of shell code, TYPE has to be filled like this:
    TYPE=$(cat /sys/bus/scsi/${H}:${C}:${I}:${L}/type)
I believe the script needs to wait a little bit from reception of a SCSI hotplug
event to evaluation of the type attribute, but I am not sure about it.

Comment 23 David Bentley 2006-03-05 13:21:43 UTC
The problem of firewire disks not appearing in computer has now been fixed in
bug 181494 but only VFAT volumes mount on the desktop when opened or double clicked.

I have several fire wire drives and their behavior is described below :-

One drive is split 20gig NTFS 60gig EXT3 the other normally attached to the
test machine is a single 160gig EXT3 partition and the drive which is normally
on my windows only machine is split into 3 partitions one 80gig NTFS and two
FAT32(VFAT) of 30gig and 5gig.

Selecting and opening any of the FAT32 partitions results in a folder in media
which opens for browsing on the desktop and a corresponding firewire disc icon
on the desktop.

Selecting and opening any NTFS partition you get two boxes appear both with the 
error icon one box has no title and just an OK button the other box is titled
error and has the expected text that explains that the NTFS file system is 

Selecting and opening any of the EXT3 partitions results in a folder appearing
in media but this time you dont have to refresh to see it. The folder does not
open automatically nor does it get an icon on the desktop. Opening the folder 
reveals its contents as expected. 

Selecting and opening the an EXT3 partition in computer a second time results
in two boxes one with no title the error icon and an OK button and another
titled error with an error icon an OK button and text saying canot mount volume.

Doing the same for a FAT32 partition results in afolder opening on the desktop
as expected.

I hope this errors of no icons on the desktop for EXT3 partitions and the error
behaviour described will not be present when hotplug mounting and mounting when
already connected at boot gets fixed.

NB the same behaviour is seen for the EXT3 partitions if the drive is hotpluged
or attached at boot via its alternate USB interface. It appears in computer
(with a USB disk icon) but not in media and when you select and open it then it
appears in media and you can use it but you get the same error boxes as before
if you try to open it a second time.

Is this error behavior a problem with gnome-mount and not as a result of the way
the device was descovered and made available for mounting.

Comment 24 David Bentley 2006-03-05 15:47:06 UTC
All of the above (comment #23) was tried as root. 
If you boot and login as a normal user the attached drives partitions get auto
mounted and in the case of vfat partions show on the desktop and are opened. 
Error dialog boxes appear for ntfs partitions and the ext3 partitions appear in
media automatically and become part of the file system.
Clicking on an ext3 partition's icon in computer gives the can't mount error
dialogues as described in comment #23

Comment 25 Dave Jones 2006-03-05 18:35:10 UTC
NTFS is unsupported by the fedora kernel, so that's expected behaviour.

Why ext3 & vfat have different behaviour to the gnome-volume-mounter I don't
know. Davidz ?

Comment 26 David Zeuthen 2006-03-05 20:42:32 UTC
Re two dialogs on unsucessful mount, there's a bug in Nautilus that puts up a
blank dialog when it's not supposed to. I can't find the bug number right now
but it ought to be fixed in a FC5 update.

I haven't personally seen any different behavior between ext3, vfat and other
file systems supported by Fedora such as hfsplus. And to report; I'm happily
able to mount my Powerbook G4 12" in target disk mode via Firewire. Though I
think it requires that I manually do a 'modprobe sbp2' but that is another bug.

Re comment 23 and comment 24 - first of all you should never log in as root.
Second, please ensure that you reboot after upgrading packages like hal. Re not
being able to mount ext3 please paste the output of 

 gnome-mount -t -v -d /dev/file

where you should replace /dev/file with the block device for your ext3
partition, e.g. /dev/sda1 or whatever (lshal will help you find it). I need this
from a fully updated rawhide system (please remember to reboot too). If it fails
please also attach full contents of lshal. Thanks.

Comment 27 David Bentley 2006-03-06 00:23:58 UTC
Attachments follow as requested.

Machine booted and loged in as normal user then confirmed that Archive was created
in /media as not visible on the desktop but does show up in computer.

lshal.text then sdc1.text captured.

I decided to attach a single firewire drive that only has an ext3 partiton to make
things as easy as posible to diagnose.

Comment 28 David Bentley 2006-03-06 00:25:58 UTC
Created attachment 125689 [details]

Comment 29 David Bentley 2006-03-06 00:27:01 UTC
Created attachment 125690 [details]

Comment 30 David Zeuthen 2006-03-06 01:24:10 UTC
Interesting.. more questions

 1. What does your /etc/fstab look like?

 1. can you mount /dev/sdc1 by hand? e.g. as root 'mount -t ext3 /dev/sdc1
/media/tmp' (have to create /media/tmp yourself)

 2. Try shutting down hald by 'service haldaemon stop' as root. Then run
'/usr/sbin/hald --daemon=no --verbose=yes' as root from a terminal. This will
create lots of output. Now try to run the gnome-mount command again (as an
unprivileged user). Copy the output that appeared from output of hald to this


Comment 31 David Bentley 2006-03-06 10:45:16 UTC
/etc/fstab shown below :-

LABEL=/1                /                       ext3    defaults        1 1
LABEL=/boot1            /boot                   ext3    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
LABEL=SWAP-hda6         swap                    swap    defaults        0 0

I will try mounting by hand etc... and attach the output as requested.

Comment 32 David Bentley 2006-03-06 11:56:38 UTC
Here goes. Booted machine loged in as a normal user looked in /media drive already
mounted in the file system as Archive. Opened a terminal bacame root typed 
cd /media
mkdir tmp
mount -t ext3 /dev/sdc1 /media/tmp
Looked in /media/tmp and disk mounted OK.

Rebooted loged in as normal user and again drive mounted already as before.
Opened a terminal became root but not allowed to use service haldaemon stop so
I used the services control panel aplet to do it.
Tthen issued the /usr/sbin/hald --daumon=no --verbose=yes and got the masses of
output as expected waited a while so that I could see where the new output had 

Opened another terminal and found that you need to be root to use the mount
command so became root and issued the command again it worked OK and the new
output from hald is in the following attachment.

Comment 33 David Bentley 2006-03-06 11:58:55 UTC
Created attachment 125701 [details]
new output from hald

attachment as promised

Comment 34 David Bentley 2006-03-06 12:42:46 UTC
Created attachment 125702 [details]
output from an initial root login for comparison.

New output from hald when freshly booted and loged in as root.
Drive not auto mounted as /media/archive this time.

Comment 35 David Bentley 2006-03-06 13:13:53 UTC
Created attachment 125704 [details]
output from an initial root login for comparison.

output from an initial root login for comparison
Note as root the drive is mounted in /media/tmp and an icon for a firewire
appears on the desktop that when clicked on opens a folder titled tmp as

Comment 36 David Bentley 2006-03-06 13:26:40 UTC
Note doing the mount manually when initially loged in as root gives gives the
result similar to what should happen automatically (ie an icon on the desktop
that works as it should).

Comment 37 David Bentley 2006-03-06 13:56:19 UTC
Revalation. HALDAEMON and SELINUX issue possibly.
As booting with enforcing=0 added gives the expected results for both ROOT and a
NORNAL user.

ROOT ) disc shows in computer but is not mounted and has no icon on the desktop
until double cliked or opened (expected behavior) and you can unmount and re-mount
it without error.

NORMAL ) disc shows in computer is mounted automatically abd gets an icon on the 
desktop and can be unmounter and re-mounted without error.

The problem is why is this possible HALDAEMON/SELINUX issue only affecting ext3

NB the disk was formatted and partioned and in use on FC4 previously.

Comment 38 David Zeuthen 2006-03-06 14:22:07 UTC
Thanks for the testing so far. 

Comment 37:
> The problem is why is this possible HALDAEMON/SELINUX issue only affecting ext3
> partitions.

What are the AVC denied messages then?

Comment 39 David Bentley 2006-03-06 15:39:57 UTC
Created attachment 125709 [details]

Checked for them in audit.log and couldn't spot any but I have attached some
from messages which may be of interest.

I will have another look in audit.log as suggested without selinux disabled and

attach anything I can find (I will force a new audit log to be created then
there will be less to trawl through)

Comment 40 David Bentley 2006-03-06 16:10:44 UTC
Created attachment 125710 [details]
AVC message found.

AVC message generated as a result of mount attempt by selecting and opening
Archive with selinux enabled and loged in as root after system re-booted.

Comment 41 David Zeuthen 2006-03-06 16:18:00 UTC
Reassigning to SELinux - please see comment 37 and onwards. Why would SELinux
deny hal mounting an ext3 drive? 

Thanks, David

Comment 42 Daniel Walsh 2006-03-06 17:39:17 UTC
file_t indicates a that this is an unlabled disk.  So we need to either label
the disk or mount it with a --context label.

Comment 43 David Zeuthen 2006-03-06 17:55:37 UTC
Given the use-case of external disks, labeling the disk is not an option I think.

Hmm.. I see nothing about --context in the mount(8) man page, that should
probably be fixed. IIRC one would pass an option fscontext=<something> where
<something> would have to be determine run-time. Perhaps this is what you meant?
The fscontext option is missing from the man page too, should probably be fixed too.


 1. If we do pass fscontext to mount, does that mean that the ext3 fs will be
modified on write such that it won't be usable on older kernels without extended
attribute support?

 2. Should we always pass fscontext=<something> when mounting ext3 fs from
external disks?

Ideally, the way I see it, the answer to 1. should be 'no' and the answer to 2.
should be 'yes'. Given time passes, 1. is probably not a big deal any more and
all old distros already have vendor patches for this anyway.

Thanks, David

Comment 44 Russell Coker 2006-03-15 11:25:40 UTC
Firstly I just filed bugzilla 185500 requesting an addition to the mount(8)  
man page. 
Still working on this issue, but fixed another hald policy issue and a mount 
issue along the way. 

Comment 47 David Zeuthen 2007-04-03 00:18:13 UTC
With the new firewire kernel stack firewire harddisks mount just fine for me
now. If there are additional issues, please reopen this bug. Thanks.

Comment 48 Stefan Richter 2007-04-03 07:16:16 UTC
Side note to comment #47:
David Z, if the new FireWire drivers had existed in 2005, the problem reported
by David B would have occurred too.  This was caused by a change of one of the
sysfs values exported by the SCSI stack.  The problem in comments #2 and #3 was
a 1394 driver problem.  I can't access the mailing list archive at the moment
but looking back this seemed to be caused by a firmware bug.  So the new drivers
would have had a good chance to run into the same trap had they been there 2
years ago.  The rest of the problems here were not related to device drivers.
Just saying.  :-)

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