Created attachment 520432 [details] udisks --dump for working card. Description of problem: I'm using an ExpressCard(PCIe)->CF adapter that uses a JMicron JM386 controller. With one card it correctly identifies as a removable, non-system drive. With another card, udisk identifies the card as a non-removable, system-internal drive and prompts the user for a password when attempting to mount it. I can change the default permissions to allow this without a password, but that would allow true system drives to be unmounted by unprivileged users. Version-Release number of selected component (if applicable): udisks-1.0.2-4.fc15.x86_64 kernel-2.6.40.3-0.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1. Insert CF<->ExpressCard adapter 2. Drive should automount. Actual results: Does not automount with one CF card, but does with another. Expected results: Should automount with both cards. Additional info: The "working" card in this case is an old 256MB CF card that doesn't support UDMA. The "non-working" card is a modern 16GB UDMA-enabled card that also supports SMART. When I use either card in a USB CF reader both function as expected. I don't know if this is a kernel or udisks problem. I plan on digging into udisks to figure out where it makes the "System-internal" and "removeable" distinction, but clearly something's wrong here.
Created attachment 520433 [details] udisks --dump for non-working card Added the dump from the non-working card.
I don't think there's any way to detect this is a CF card - from what I can tell, you can't really tell it apart from a hard disk using the ATA command-set. Please attach the output of 'hdparm -I /dev/sdb' and 'udevadm info -q all -n /dev/sdb'. Thanks.
Actually please also attach udevadm info -q all -n /dev/sdb --attribute-walk Maybe we can whitelist the controller in question.
[pizza@marinara ~]$ sudo hdparm -I /dev/sdd /dev/sdd: CompactFlash ATA device Model Number: TS16GCF400 Serial Number: 20101115 0140004A Firmware Revision: 20101008 Standards: Likely used: 6 Configuration: Logical max current cylinders 31045 31045 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 31293360 LBA user addressable sectors: 31293360 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 15279 MBytes device size with M = 1000*1000: 16022 MBytes (16 GB) cache/buffer size = 1 KBytes (type=DualPort) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 4 Standby timer values: spec'd by Vendor R/W multiple sector transfer: Max = 1 Current = 0 Advanced power management level: disabled DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set Power Management feature set Write cache WRITE_BUFFER command READ_BUFFER command NOP cmd CFA feature set Advanced Power Management feature set Mandatory FLUSH_CACHE * CFA advanced modes: pio5 *pio6 mdma3 mdma4 * CFA Power Level 1 (max 500mA) Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count not supported: enhanced erase 6min for SECURITY ERASE UNIT. HW reset results: CBLID- above Vih Device num = 0 Integrity word not set (found 0x0000, expected 0xada5)
[pizza@marinara ~]$ sudo udevadm info -q all -n /dev/sdd P: /devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0/block/sdd N: sdd S: disk/by-id/ata-TS16GCF400_20101115_0140004A S: disk/by-id/scsi-SATA_TS16GCF400_20101115_0140004A S: disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0 E: UDEV_LOG=3 E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0/block/sdd E: MAJOR=8 E: MINOR=48 E: DEVNAME=/dev/sdd E: DEVTYPE=disk E: SUBSYSTEM=block E: ID_ATA=1 E: ID_TYPE=disk E: ID_BUS=ata E: ID_MODEL=TS16GCF400 E: ID_MODEL_ENC=TS16GCF400\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_REVISION=20101080 E: ID_SERIAL=TS16GCF400_20101115_0140004A E: ID_SERIAL_SHORT=20101115_0140004A E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=0 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=0 E: ID_ATA_FEATURE_SET_APM=1 E: ID_ATA_FEATURE_SET_APM_ENABLED=0 E: ID_SCSI_COMPAT=SATA_TS16GCF400_20101115_0140004A E: ID_PATH=pci-0000:04:00.0-scsi-0:0:0:0 E: ID_PART_TABLE_TYPE=dos E: UDISKS_PRESENTATION_NOPOLICY=0 E: UDISKS_PARTITION_TABLE=1 E: UDISKS_PARTITION_TABLE_SCHEME=mbr E: UDISKS_PARTITION_TABLE_COUNT=1 E: UDISKS_ATA_SMART_IS_AVAILABLE=1 E: DEVLINKS=/dev/disk/by-id/ata-TS16GCF400_20101115_0140004A /dev/disk/by-id/scsi-SATA_TS16GCF400_20101115_0140004A /dev/disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0 E: TAGS=:systemd:
[pizza@marinara ~]$ udevadm info -q all -n /dev/sdd --attribute-walk Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0/block/sdd': KERNEL=="sdd" SUBSYSTEM=="block" DRIVER=="" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{removable}=="0" ATTR{ro}=="0" ATTR{size}=="31293360" ATTR{alignment_offset}=="0" ATTR{discard_alignment}=="0" ATTR{capability}=="50" ATTR{stat}==" 169 631 1409 56 0 0 0 0 0 56 56" ATTR{inflight}==" 0 0" ATTR{events}=="" ATTR{events_async}=="" ATTR{events_poll_msecs}=="-1" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0': KERNELS=="23:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" ATTRS{device_blocked}=="0" ATTRS{type}=="0" ATTRS{scsi_level}=="6" ATTRS{vendor}=="ATA " ATTRS{model}=="TS16GCF400 " ATTRS{rev}=="2010" ATTRS{state}=="running" ATTRS{timeout}=="30" ATTRS{iocounterbits}=="32" ATTRS{iorequest_cnt}=="0xd5" ATTRS{iodone_cnt}=="0xd5" ATTRS{ioerr_cnt}=="0xa" ATTRS{evt_media_change}=="0" ATTRS{dh_state}=="detached" ATTRS{queue_depth}=="1" ATTRS{queue_type}=="none" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0': KERNELS=="target23:0:0" SUBSYSTEMS=="scsi" DRIVERS=="" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23': KERNELS=="host23" SUBSYSTEMS=="scsi" DRIVERS=="" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': KERNELS=="0000:04:00.0" SUBSYSTEMS=="pci" DRIVERS=="pata_jmicron" ATTRS{vendor}=="0x197b" ATTRS{device}=="0x2368" ATTRS{subsystem_vendor}=="0x197b" ATTRS{subsystem_device}=="0x2368" ATTRS{class}=="0x010185" ATTRS{irq}=="18" ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003" ATTRS{local_cpulist}=="0-1" ATTRS{numa_node}=="-1" ATTRS{dma_mask_bits}=="32" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{broken_parity_status}=="0" ATTRS{msi_bus}=="" looking at parent device '/devices/pci0000:00/0000:00:1c.2': KERNELS=="0000:00:1c.2" SUBSYSTEMS=="pci" DRIVERS=="pcieport" ATTRS{vendor}=="0x8086" ATTRS{device}=="0x2944" ATTRS{subsystem_vendor}=="0x1043" ATTRS{subsystem_device}=="0x19a7" ATTRS{class}=="0x060400" ATTRS{irq}=="43" ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003" ATTRS{local_cpulist}=="0-1" ATTRS{numa_node}=="-1" ATTRS{dma_mask_bits}=="32" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{broken_parity_status}=="0" ATTRS{msi_bus}=="1" looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS==""
What confuses me is that one CF card is detected as non-system_internal, but not the others that I have. That tells me that the heuristic that makes that determination is somehow broken. I've previously filed bugs against the kernel relating to this ExpressCard adapter ("SIIG ExpressCard54 CF R/W") but the pata_jmicron driver has no way of detecting that this particular model is different from any others, given that they all share the same PCI [sub]vendor/model ID, so I also have to play games with the pata layer to force "short40c" cables so that I can even use UDMA speeds. So I don't think we're going to be able to whitelist that adapter somehow.
## And here's the dump from the "working" card: [pizza@marinara ~]$ sudo hdparm -I /dev/sdc [sudo] password for pizza: /dev/sdc: CompactFlash ATA device Model Number: Hitachi XXM2.3.0 Serial Number: X0213 20030606021821 Firmware Revision: Rev 3.00 Standards: Likely used: 4 Configuration: Logical max current cylinders 695 695 heads 15 15 sectors/track 48 48 -- bytes/track: 0 bytes/sector: 512 CHS current addressable sectors: 500400 LBA user addressable sectors: 500400 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 244 MBytes device size with M = 1000*1000: 256 MBytes cache/buffer size = 1 KBytes (type=DualPort) Capabilities: LBA, IORDY(may be)(cannot be disabled) Buffer size: 1.0kB bytes avail on r/w long: 4 Standby timer values: spec'd by Vendor R/W multiple sector transfer: Max = 1 Current = 0 DMA: not supported PIO: pio0 pio1 [pizza@marinara ~]$ sudo udevadm info -q all -n /dev/sdc P: /devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0/block/sdc N: sdc S: disk/by-id/ata-Hitachi_XXM2.3.0_X0213_20030606021821 S: disk/by-id/scsi-SATA_Hitachi_XXM2.3.X0213_20030606021821 S: disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0 E: UDEV_LOG=3 E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0/block/sdc E: MAJOR=8 E: MINOR=32 E: DEVNAME=/dev/sdc E: DEVTYPE=disk E: SUBSYSTEM=block E: ID_ATA=1 E: ID_TYPE=generic E: ID_BUS=ata E: ID_MODEL=Hitachi_XXM2.3.0 E: ID_MODEL_ENC=Hitachi\x20XXM2.3.0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_REVISION=Rev_3.00 E: ID_SERIAL=Hitachi_XXM2.3.0_X0213_20030606021821 E: ID_SERIAL_SHORT=X0213_20030606021821 E: ID_SCSI_COMPAT=SATA_Hitachi_XXM2.3.X0213_20030606021821 E: ID_PATH=pci-0000:04:00.0-scsi-0:0:0:0 E: ID_PART_TABLE_TYPE=dos E: UDISKS_PRESENTATION_NOPOLICY=0 E: UDISKS_PARTITION_TABLE=1 E: UDISKS_PARTITION_TABLE_SCHEME=mbr E: UDISKS_PARTITION_TABLE_COUNT=1 E: DEVLINKS=/dev/disk/by-id/ata-Hitachi_XXM2.3.0_X0213_20030606021821 /dev/disk/by-id/scsi-SATA_Hitachi_XXM2.3.X0213_20030606021821 /dev/disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0 E: TAGS=:systemd: [pizza@marinara ~]$ sudo udevadm info -q all -n /dev/sdc --attribute-walk Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0/block/sdc': KERNEL=="sdc" SUBSYSTEM=="block" DRIVER=="" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{removable}=="1" ATTR{ro}=="0" ATTR{size}=="500400" ATTR{alignment_offset}=="0" ATTR{discard_alignment}=="0" ATTR{capability}=="51" ATTR{stat}==" 165 4 1352 771 0 0 0 0 0 771 771" ATTR{inflight}==" 0 0" ATTR{events}=="media_change" ATTR{events_async}=="" ATTR{events_poll_msecs}=="-1" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0': KERNELS=="30:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" ATTRS{device_blocked}=="0" ATTRS{type}=="0" ATTRS{scsi_level}=="6" ATTRS{vendor}=="ATA " ATTRS{model}=="Hitachi XXM2.3.0" ATTRS{rev}=="Rev " ATTRS{state}=="running" ATTRS{timeout}=="30" ATTRS{iocounterbits}=="32" ATTRS{iorequest_cnt}=="0x13d" ATTRS{iodone_cnt}=="0x13d" ATTRS{ioerr_cnt}=="0x2" ATTRS{evt_media_change}=="0" ATTRS{dh_state}=="detached" ATTRS{queue_depth}=="1" ATTRS{queue_type}=="none" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0': KERNELS=="target30:0:0" SUBSYSTEMS=="scsi" DRIVERS=="" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30': KERNELS=="host30" SUBSYSTEMS=="scsi" DRIVERS=="" looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': KERNELS=="0000:04:00.0" SUBSYSTEMS=="pci" DRIVERS=="pata_jmicron" ATTRS{vendor}=="0x197b" ATTRS{device}=="0x2368" ATTRS{subsystem_vendor}=="0x197b" ATTRS{subsystem_device}=="0x2368" ATTRS{class}=="0x010185" ATTRS{irq}=="18" ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003" ATTRS{local_cpulist}=="0-1" ATTRS{numa_node}=="-1" ATTRS{dma_mask_bits}=="32" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{enable}=="1" ATTRS{broken_parity_status}=="0" ATTRS{msi_bus}=="" ATTRS{resource1}=="P" ATTRS{resource3}=="" looking at parent device '/devices/pci0000:00/0000:00:1c.2': KERNELS=="0000:00:1c.2" SUBSYSTEMS=="pci" DRIVERS=="pcieport" ATTRS{vendor}=="0x8086" ATTRS{device}=="0x2944" ATTRS{subsystem_vendor}=="0x1043" ATTRS{subsystem_device}=="0x19a7" ATTRS{class}=="0x060400" ATTRS{irq}=="43" ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003" ATTRS{local_cpulist}=="0-1" ATTRS{numa_node}=="-1" ATTRS{dma_mask_bits}=="32" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{enable}=="2" ATTRS{broken_parity_status}=="0" ATTRS{msi_bus}=="1" looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS==""
(In reply to comment #7) > What confuses me is that one CF card is detected as non-system_internal, but > not the others that I have. That tells me that the heuristic that makes that > determination is somehow broken. It's not broken - the reason is that one card is reporting the sysfs removable attribute as 1, the other as 0. That's why you are seeing this. Why is the kernel driver doing this? I don't know - it's most probably just reporting what the hardware is telling it so the driver is probably fine. The way to resolve this is to look at the ATA IDENTIFY data and make udev's ata_id export a property, say, ID_COMPACT_FLASH and then make udisks set system-internal to FALSE if this is set (this is possible because the IDENTIFY data has a bit for this - that's why I asked for hdparm -I output). I'll start working on the ata_id patch...
I'd noticed that 'removable' flag in the dumps, but hadn't had time to hunt down where it was being set. Since you say that's sysfs attribute, fingers point to a kernel bug. So I started digging into the kernel source. The removable flag is set based on bit7 in the second byte of the SCSI identify response, which in turn is generated based on bit7 of the first byte of the ATA Identify response. Hdparm blindly ignores that bit if the compact_flash bit is set -- so I patched that test out, and lo and behold, the "working" CF card has the "removable" flag set, but the "non-working" cards don't. Interesting. I wonder if the ATA/CF spec implies removable if the CFA bits are set?
Created attachment 520611 [details] kernel patch to force 'removable' flag if device identifies as compactflash I'm not sure how well this kernel patch will go over; would it be better to workaround this problem in userspace (eg udev?)
The plot thickens; apaprently the "Removable Media" feature set has been obsoleted in newer versions of the ATA specification, which explains why my newer CF cards don't have it set. (That implies that setting the 'removable' attribute in the kernel is probably the wrong thing to do) It looks like udev/udisks is where this fix should be implemented after all...
(In reply to comment #12) > The plot thickens; apaprently the "Removable Media" feature set has been > obsoleted in newer versions of the ATA specification, which explains why my > newer CF cards don't have it set. > > (That implies that setting the 'removable' attribute in the kernel is probably > the wrong thing to do) > > It looks like udev/udisks is where this fix should be implemented after all... Yes, that's what I meant with 7 - if the ATA IDENTIFY data indicates the ATA device is a compact flash device, then don't tag it as system_internal. Since I don't have the hardware in question, any chance you can attach the IDENTIFY data as captured with hdparm's --Istdout option? Thanks!
### here ya go.. [pizza@marinara udisks (master)]$ sudo hdparm --Istdout /dev/sdb /dev/sdb: 044a 7945 0000 0010 0000 0240 003f 01dd 7fb0 0000 3230 3130 3131 3135 2020 2020 3031 3430 3030 3441 0002 0002 0004 3230 3130 3130 3038 5453 3136 4743 4634 3030 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 8001 0000 0f00 0000 0200 0000 0007 7945 0010 003f 7fb0 01dd 0100 7fb0 01dd 0000 0007 0003 0078 0078 0078 0078 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 702b 500c 4002 0001 0000 0003 207f 0003 0000 0000 fffe 604f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 81f4 0000 0000 0092 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Created attachment 520824 [details] ata_id patch Please try this patch. Semi-instructions (if needed) $ sudo yum-builddep udev $ git clone git://git.kernel.org/pub/scm/linux/hotplug/udev.git $ cd udev $ git am /path/to/0001-ata_id-Check-for-Compact-Flash-card.patch $ ./autogen.sh $ make $ sudo extras/ata_id/ata_id --export /dev/sdb then attach the output. It should should ID_ATA_CF=1. Thanks!
There's a bug in the patch, but a tweak (patch to follow) and I get this with the newer DMA-enabled cards: [pizza@marinara udev (master)]$ sudo extras/ata_id/ata_id --export /dev/sdb ID_ATA=1 ID_TYPE=disk ID_BUS=ata ID_MODEL=TS16GCF400 ID_MODEL_ENC=TS16GCF400\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 ID_REVISION=20101080 ID_SERIAL=TS16GCF400_20101115_0140004A ID_SERIAL_SHORT=20101115_0140004A ID_ATA_WRITE_CACHE=1 ID_ATA_WRITE_CACHE_ENABLED=0 ID_ATA_FEATURE_SET_PM=1 ID_ATA_FEATURE_SET_PM_ENABLED=0 ID_ATA_FEATURE_SET_SECURITY=1 ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6 ID_ATA_FEATURE_SET_SMART=1 ID_ATA_FEATURE_SET_SMART_ENABLED=1 ID_ATA_FEATURE_SET_APM=1 ID_ATA_FEATURE_SET_APM_ENABLED=0 ID_ATA_CFA=1 I haven't tested this with my older card (left it at the office).
Created attachment 520932 [details] Tweak to the first patch to make it work. I don't immediately see why this patch is even necessary, but it may have something to do with this build warning: CC extras/ata_id/ata_id.o extras/ata_id/ata_id.c: In function ‘main’: extras/ata_id/ata_id.c:705:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
Created attachment 521049 [details] Updated patch OK, here's an updated patch - I'm 99% it's right but would be great to test it nonetheless. Thanks!
Looks good; the build warning's gone and all of my CF cards are identified properly with ID_ATA_CFA=1.
Excellent, thanks for testing - as master.kernel.org is currently down (cf. the recent security breach) I can't push it. But I sent it to the udev maintainer and it's now in his tree and will be part of udev 174.
Yay, one bug down. That said, udisks still needs to be modified, correct?
Indeed. Any chance you can try the following udev rule? ENV{ID_ATA_CFA}=="?*", ENV{ID_DRIVE_FLASH_CF}="1", ENV{ID_DRIVE_MEDIA_FLASH_CF}="1", ENV{UDISKS_SYSTEM_INTERNAL}="0" Thanks! (See also http://hal.freedesktop.org/docs/udisks/udisks.7.html for other udev properties affecting how udisks work)
Actually, I guess, use ENV{ID_ATA_CFA}=="1" instead of ENV{ID_ATA_CFA}=="?*"
Solomon: any chance you can try the rules in comment 22 and comment 23? Thanks!
I put off testing this due to kernel.org being down, preventing me from pulling the udev sources again. (I'd managed to nuke my udev tree) So I'm going to rebuild the udev-167-6 srpm that F15 is using (with that patch) add that rule, and get back to you.
Okay, with the rule in comment 23, my new-sk00l CF cards act the same way as the old ones -- They're no longer being treated as system_internal and I can mount them without being prompted for the root password. None of cards aren't being auto-mounted still though, but I suppose that's specified elsewhere.
I added ENV{UDISKS_AUTOMOUNT_HINT}="always" to the rule in comment 23, but the system is ignoring the hint. (without that explicit rule, there's no hint at all according to udisks --show-info) Any pointers on where to go to enable automounting?
Is upgrade of udev to 174 scheduled for F-16 ? Its currently at 173, so we're close. If not, will it be in F-17 ? Im having trouble getting a working image of voyage onto my CF, and am hoping this fix will resolve my issues. FWIW, when I try to "safely unmount drive" in Nautilus, it appears to flush all the writes to the CF (a dialog box briefly appears, but closes before I can read the entire message), but the boot fails early in the grub-boot, without error messages, and does a bios reboot. Im getting further afield here (sorry), but running sync before "safely unmounting" doesnt help. thanks
I'm happy to report that F17 JustWorks(tm), and I can finally use my ExpressCard CF reader without jumping through any extra hoops.
for me it "mostly works". It is automounting CF when I plug it in, unmounting when I click eject (and popups a "writing to CF" notification), and successfully remounting when I yank and reinsert the CF (that remount is the critical improvement). But my trouble is with writing a Voyage image to the CF: I use the usr/local/sbin/voyage.update script thats in the distro, but it complains when the disk is already mounted, so I unmount it manually: 1st I tried this using eject button, but that caused /dev/sdc1 to disappear, which the script needs in order to do its own mount. 2nd try, I did sudo umount /mnt/cf before running script, and everything seemed to go smoothly, but I cannot cleanly eject the CF, it doesnt show up under Places, MyComputer, and manual umount fails as follows: [jimc@groucho voyage-current]$ sudo umount /mnt/cf umount: /mnt/cf: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) [jimc@groucho voyage-current]$ sudo fuser -auvim /mnt/cf USER PID ACCESS COMMAND /mnt/cf: root kernel mount (root)/mnt/cf [jimc@groucho voyage-current]$ sudo lsof | grep /mnt/cf lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /run/user/jimc/gvfs Output information may be incomplete. [jimc@groucho voyage-current]$ mount | grep sdc /dev/sdc1 on /mnt/cf type ext2 (rw,relatime,seclabel) Can I get some advice ?
(In reply to comment #30) > for me it "mostly works". It is automounting CF when I plug it in, > unmounting when I click eject (and popups a "writing to CF" notification), > and successfully remounting when I yank and reinsert the CF (that remount > is the critical improvement). > > But my trouble is with writing a Voyage image to the CF: > I use the usr/local/sbin/voyage.update script thats in the distro, > but it complains when the disk is already mounted, so I unmount > it manually: > 1st I tried this using eject button, but that caused /dev/sdc1 to > disappear, The eject button in GNOME causes "eject /dev/sdc" to be run (as root) which causes the partition to disappear. This is expected (it's what ejecting means). Just run 'umount /dev/sdc1' yourself from a terminal if you only want to unmount the device. > which the script needs in order to do its own mount. > 2nd try, I did sudo umount /mnt/cf before running script, and > everything seemed to go smoothly, but I cannot cleanly eject the CF, > it doesnt show up under Places, MyComputer, and manual umount > fails as follows: This is also expected, GNOME will only show mounts in /media, /run/media/$USER or $HOME (and /mnt/cf is not one of those). For more details on what is shown in the desktop user interface in F17 and onward, see http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping