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): kernel-2.6.14-1.1637_FC4 How reproducible: Always 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.
Created attachment 121000 [details] messages.txt as atachment output from messages.
I have the same problem with close to the same content in /var/log messages. Attaching appropriate portion of my /var/log/messages.
Created attachment 121146 [details] pertinent section of /var/log/messages
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> 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 - gives [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
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.
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.
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
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.
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" LABEL="scsi_device_end" You can see where type 14 is classed as the sd_mod, instead of falling through to sg. ###################### Harald ?
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. Regards André Fettouhi
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.
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?
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)
Created attachment 124710 [details] messages.txt from FC5T2 fully updated from rawhide 15/2/06
Created attachment 124712 [details] lshal.txt output fom lshal
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.
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
Created attachment 124727 [details] dmesg outpt when hotpluging and unpluging
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.
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.
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: VENDOR_ID, MODEL_ID, GUID, SPECIFIER_ID, VERSION, and 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", ud->vendor_id, ud->model_id, ud->specifier_id, ud->version); 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_DISK=0 TYPE_TAPE=1 TYPE_PRINTER=2 TYPE_PROCESSOR=3 #/* HP scanners use this */ TYPE_WORM=4 #/* Treated as ROM by our system */ TYPE_ROM=5 TYPE_SCANNER=6 TYPE_MOD=7 #/* Magneto-optical disk - treated as TYPE_DISK */ TYPE_CHANGER=8 TYPE_COMM=9 TYPE_ENCLOSURE=13 TYPE_RBC=14 case "$TYPE" in $TYPE_DISK) MODULE=sd_mod ;; $TYPE_TAPE) MODULE=st ;; $TYPE_PRINTER) MODULE=sg ;; $TYPE_PROCESSOR)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_ENCLOSURE);; $TYPE_RBC) MODULE=sd_mod ;; esac Note: Some tapes actually use osst instead of st.
PS: 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.
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 unsupported. 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.
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
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 ?
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.
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.
Created attachment 125689 [details] lshal.txt
Created attachment 125690 [details] sdc1.txt
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 bugreport. Thanks
/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.
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 started. 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.
Created attachment 125701 [details] new output from hald attachment as promised
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.
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 drive appears on the desktop that when clicked on opens a folder titled tmp as expected.
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).
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 partitions. NB the disk was formatted and partioned and in use on FC4 previously.
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?
Created attachment 125709 [details] messages.txt Checked for them in audit.log and couldn't spot any but I have attached some text 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)
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.
Reassigning to SELinux - please see comment 37 and onwards. Why would SELinux deny hal mounting an ext3 drive? Thanks, David
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.
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. Questions 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
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.
With the new firewire kernel stack firewire harddisks mount just fine for me now. If there are additional issues, please reopen this bug. Thanks.
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. :-)