Bug 138269 - SCSI zip disk doesn't automount
SCSI zip disk doesn't automount
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gnome-volume-manager (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-06 18:35 EST by Brian Gerst
Modified: 2013-03-05 22:41 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:03:06 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)
lshal output with zip disk inserted (57.57 KB, text/plain)
2004-11-12 22:57 EST, Brian Gerst
no flags Details

  None (edit)
Description Brian Gerst 2004-11-06 18:35:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
/dev/sda4 does not automount like other removable media (ie. cdroms).

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


How reproducible:
Always

Steps to Reproduce:
1. Insert zip disk


Actual Results:  /dev/sda4 isn't mounted

Expected Results:  /dev/sda4 mounted in /media

Additional info:
Comment 1 John (J5) Palmieri 2004-11-08 10:31:22 EST
HAL needs to poll for media inserts on removable media.  Can you
please attach the output of lshal.
Comment 2 David Zeuthen 2004-11-08 14:13:11 EST
Specifically, is this a USB device? (USB Mass Storage uses SCSI
emulation, so that's why I'm asking)
Comment 3 Brian Gerst 2004-11-08 20:58:30 EST
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
transfers
  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

lshal shows:
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' 
(string)
  storage.physical_device =
'/org/freedesktop/Hal/devices/scsi_0_0_4_0'  (string)
  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)
Comment 4 David Zeuthen 2004-11-09 10:04:03 EST
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 ------

<deviceinfo version="0.2">
  <device>
    <match key="info.category" string="storage">
      <match key="storage.bus" string="scsi">
        <merge key="storage.policy.should_mount" type="bool">true</merge>
      </match>
    </match>
  </device>
</deviceinfo>

--- END ------
Comment 5 Brian Gerst 2004-11-12 22:57:27 EST
Created attachment 106635 [details]
lshal output with zip disk inserted
Comment 6 David Zeuthen 2004-11-17 10:27:05 EST
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

 http://people.redhat.com/davidz/hal-testing/

Thanks,
David
Comment 7 Brian Gerst 2004-11-17 18:56:26 EST
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.
Comment 8 Bug Zapper 2008-04-03 11:44:48 EDT
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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 9 Bug Zapper 2008-05-06 20:03:03 EDT
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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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