Bug 138269 - SCSI zip disk doesn't automount
Summary: SCSI zip disk doesn't automount
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-volume-manager   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-06 23:35 UTC by Brian Gerst
Modified: 2013-03-06 03:41 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-07 00:03:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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-13 03:57 UTC, Brian Gerst
no flags Details

Description Brian Gerst 2004-11-06 23:35:12 UTC
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):

How reproducible:

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 15:31:22 UTC
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 19:13:11 UTC
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-09 01:58:30 UTC
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

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' 
  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 15:04:03 UTC
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">
    <match key="info.category" string="storage">
      <match key="storage.bus" string="scsi">
        <merge key="storage.policy.should_mount" type="bool">true</merge>

--- END ------

Comment 5 Brian Gerst 2004-11-13 03:57:27 UTC
Created attachment 106635 [details]
lshal output with zip disk inserted

Comment 6 David Zeuthen 2004-11-17 15:27:05 UTC
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



Comment 7 Brian Gerst 2004-11-17 23:56:26 UTC
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 15:44:48 UTC
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.

Comment 9 Bug Zapper 2008-05-07 00:03:03 UTC
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:

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