Bug 238479

Created attachment 153817 [details]
hal-device output on FC7T4

Created attachment 153819 [details]
hal-device output on FC6

Created attachment 153820 [details]
hal-device output on FC7T4

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 ?

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.

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.

(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)

(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.

> 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 :-)

Created attachment 153824 [details]
graphical representation of a broken usb device

Thought it was easier to explain with a graphical representation.

I'm really sorry but i don't have the knowledge to make a patch. I'm just a
little translator and ambassador. :(

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.

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.

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