From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
/dev/sda4 does not automount like other removable media (ie. cdroms).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert zip disk
Actual Results: /dev/sda4 isn't mounted
Expected Results: /dev/sda4 mounted in /media
HAL needs to poll for media inserts on removable media. Can you
please attach the output of lshal.
Specifically, is this a USB device? (USB Mass Storage uses SCSI
emulation, so that's why I'm asking)
This is a bona fide SCSI Zip drive:
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7850 SCSI adapter>
aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs
(scsi0:A:4:0): refuses synchronous negotiation. Using asynchronous
Vendor: IOMEGA Model: ZIP 100 Rev: E.11
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi0, channel 0, id 4, lun 0
udi = '/org/freedesktop/Hal/devices/block_8_0'
info.udi = '/org/freedesktop/Hal/devices/block_8_0' (string)
storage.requires_eject = false (bool)
storage.hotpluggable = false (bool)
storage.removable = true (bool)
info.product = 'ZIP 100' (string)
info.vendor = 'IOMEGA' (string)
storage.drive_type = 'disk' (string)
block.storage_device = '/org/freedesktop/Hal/devices/block_8_0'
storage.vendor = 'IOMEGA' (string)
storage.model = 'ZIP 100' (string)
storage.automount_enabled_hint = true (bool)
storage.no_partitions_hint = false (bool)
storage.media_check_enabled = true (bool)
storage.bus = 'scsi' (string)
block.minor = 0 (0x0) (int)
block.major = 8 (0x8) (int)
info.capabilities = 'block storage' (string)
info.category = 'storage' (string)
info.parent = '/org/freedesktop/Hal/devices/scsi_0_0_4_0' (string)
block.device = '/dev/sda' (string)
block.is_volume = false (bool)
block.have_scanned = false (bool)
block.no_partitions = false (bool)
linux.sysfs_path_device = '/sys/block/sda' (string)
linux.sysfs_path = '/sys/block/sda' (string)
info.bus = 'block' (string)
Hi - it is actually quite delibirate that we don't add an /etc/fstab
entry for SCSI devices (except for SCSI optical drives).
The reason for having this policy as default stems from the fact that
a) we only allow an authorized user at the physical console to mount
drives; and b) only allow said user to mount drives that is know to be
physically attached to the system.
Specifically, SCSI drives may be on the other side of the planet
(iSCSI) and currently there is no way to check this. For FC4 we plan
to key off a whitelist of SCSI host adapters to alleviate this - until
this happens you may try out putting the XML below in a file
/usr/share/hal/fdi/95userpolicy/my-policy.fdi and restart the hal
daemon (service haldaemon restart). That should make it work for you;
please try it out (if it doesn't work please attach the entire
contents of the output of lshal and attach it to this bug).
--- BEGIN ------
<match key="info.category" string="storage">
<match key="storage.bus" string="scsi">
<merge key="storage.policy.should_mount" type="bool">true</merge>
--- END ------
Created attachment 106635 [details]
lshal output with zip disk inserted
OK, there was another problem insofar that the fs detection code in
hal picked up the partition as a msdos_part_table which doesn't make
sense (other people were bit by this bug too). I've fixed that with
these RPM's, please give it a whirl
It works with the new hal rpms and the above .fdi code. However, the
icon that appears on the desktop gives the option "Unmount Volume"
instead of "Eject" like a CD.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: