Bug 238479 - KingSton Data Traveler U3 USB Key : 1st partition should not be mounted
KingSton Data Traveler U3 USB Key : 1st partition should not be mounted
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-30 16:01 EDT by Thomas Canniot
Modified: 2013-03-05 22:50 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:37:30 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)
hal-device output on FC7T4 (6.07 KB, text/plain)
2007-04-30 16:01 EDT, Thomas Canniot
no flags Details
hal-device output on FC6 (9.59 KB, text/plain)
2007-04-30 16:08 EDT, Thomas Canniot
no flags Details
hal-device output on FC7T4 (11.25 KB, text/plain)
2007-04-30 16:08 EDT, Thomas Canniot
no flags Details
graphical representation of a broken usb device (103.32 KB, image/png)
2007-04-30 17:04 EDT, David Zeuthen
no flags Details

  None (edit)
Description Thomas Canniot 2007-04-30 16:01:15 EDT
Description of problem:
KingSton Data Traveler U3 USB Key has 2 partitions. The first one (0: in
hal-device output) contains data added by KingStone to manage your key. They are
for windows only and are completely useless in Fedora. Moreover, the partition
can not be written on.
This partition should not be mounted by default then (which was the case under FC6)

The 2nd partition contains user data, this one is mounted by default. (1: in
hal-device output)

Version-Release number of selected component (if applicable):
hal-0.5.9-6.fc7


See hal-device output below.
Comment 1 Thomas Canniot 2007-04-30 16:01:17 EDT
Created attachment 153817 [details]
hal-device output on FC7T4
Comment 2 Thomas Canniot 2007-04-30 16:08:14 EDT
Created attachment 153819 [details]
hal-device output on FC6
Comment 3 Thomas Canniot 2007-04-30 16:08:36 EDT
Created attachment 153820 [details]
hal-device output on FC7T4
Comment 4 Thomas Canniot 2007-04-30 16:09:50 EDT
WHen i look at hal-output on FC6 i'm no more sure whether it is a hal bug or
not. Many gnome-mount one ?
Comment 5 Will Woods 2007-04-30 16:10:31 EDT
I'm not sure refusing to acknowledge the existence of the first device is the
right solution. For example, having that device there makes it so that some
machines cannot boot from the USB key. Removing the U3 partition (with the
stupid windows-only utility) fixes that problem.

If you don't show that device, how will people know if it's there (and causing
problems) or not?

It'd be nice if the U3 people would tell us poor Linux users how you disable the
U3 device instead.
Comment 6 David Zeuthen 2007-04-30 16:18:49 EDT
Probably adding an entry to

 /usr/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi

will help. If you can generate a patch it would be nice too. Thanks.
Comment 7 David Zeuthen 2007-04-30 16:29:14 EDT
(In reply to comment #5)
> I'm not sure refusing to acknowledge the existence of the first device is the
> right solution. For example, having that device there makes it so that some
> machines cannot boot from the USB key. Removing the U3 partition (with the
> stupid windows-only utility) fixes that problem.

Nit-picking: it's more than a partition - the USB stick sports two Logical Units
(aka LUN's) one of them claiming to be an optical drive. So it looks sort of
like this

      usb_device_781_5406_0000187A3A60BF03
        usb_device_781_5406_0000187A3A60BF03_usbraw
        usb_device_781_5406_0000187A3A60BF03_if0
          usb_device_781_5406_0000187A3A60BF03_if0_scsi_host
            usb_device_781_5406_0000187A3A60BF03_if0_scsi_host_scsi_device_lun1
              storage_serial_SanDisk_U3_Cruzer_Micro_0000187A3A60BF03_0
                volume_label_U3_System
            usb_device_781_5406_0000187A3A60BF03_if0_scsi_host_scsi_device_lun0
              storage_serial_SanDisk_U3_Cruzer_Micro_0000187A3A60BF03
                volume_uuid_b11637fc_0bbb_4f05_8bd6_f019b253714c
                volume_uuid_45E6_6D1F

where LUN1 is the fake optical drive.

(The rationale, I think, from the hardware vendor is that Windows automagically
autoruns programs, without the users confirmation, from optical drives only.)

> If you don't show that device, how will people know if it's there (and causing
> problems) or not?
> 
> It'd be nice if the U3 people would tell us poor Linux users how you disable the
> U3 device instead.

It's fine - we can just tell hal to ignore the USB optical drive that this USB
stick claims to provide. We do that already for some Sandisk devices see bug
208512 for details. 

The device file will _still be there_, we just don't show it in the UI or make
it available via HAL. So if people really want to access that
Windows-only-autorun crap they can just mount it via a root shell. It's fine.

(The way we handle it right now is a bit brutal from the hal side of things. We
simply ignore the entire device and all it's children. This will change for
Fedora 8 insofar that we will include a more fine-grained hint so it's only
invisible in Nautilus but still visible in other apps using HAL)
Comment 8 David Zeuthen 2007-04-30 16:32:09 EDT
(In reply to comment #4)
> WHen i look at hal-output on FC6 i'm no more sure whether it is a hal bug or
> not. Many gnome-mount one ?

Strictly speaking it's not a bug at all. It's just the way your hardware works
and we do exactly the right thing when a multi-LUN device like that appears.
That said, as pointed out in comment 6 I'd be happy to take a patch to the
whitelist of broken usb sticks. Thanks.
Comment 9 David Zeuthen 2007-04-30 16:35:35 EDT
> This partition should not be mounted by default then (which was the case
> under FC6)

Also, the reason you didn't see this in FC6 was due to a bug in how we detect
file systems on optical discs in FC6 HAL. That bug was fixed in FC7 HAL but it
had the unfortunate side-effect (of HAL working better!) such that all the
hardware is now shown :-)
Comment 10 David Zeuthen 2007-04-30 17:04:16 EDT
Created attachment 153824 [details]
graphical representation of a broken usb device

Thought it was easier to explain with a graphical representation.
Comment 11 Thomas Canniot 2007-04-30 17:09:24 EDT
I'm really sorry but i don't have the knowledge to make a patch. I'm just a
little translator and ambassador. :(
Comment 12 Will Woods 2007-04-30 17:53:01 EDT
Probably you want to ignore any volume where volume.label = "U3 System" and
volume.is_disc = True, but I'm not sure if preprobe stuff has to be done at the
device level or the volume level.

If it needs to be done at the block device label, probably storage.drive_type =
cdrom, storage.lun = 1 and 'U3' somewhere in storage.model would be sufficient
to identify these devices. But I don't know if you can do substring matches.
Comment 13 Bug Zapper 2008-04-03 20:24:20 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 14 Bug Zapper 2008-05-06 21:37:23 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.