Description of problem: When I power up/plugin a USB hard drive with a LUKS encrypted ext4 file system, the file system fails to mount/be detected. I see this in /var/;og/messages: Dec 3 10:59:45 tlondon kernel: [ 7562.237086] usb 1-5.3: new high-speed USB device number 11 using ehci_hcd Dec 3 10:59:45 tlondon kernel: [ 7562.343746] usb 1-5.3: New USB device found, idVendor=059b, idProduct=0370 Dec 3 10:59:45 tlondon kernel: [ 7562.343759] usb 1-5.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Dec 3 10:59:45 tlondon kernel: [ 7562.343767] usb 1-5.3: Product: Iomega Dec 3 10:59:45 tlondon kernel: [ 7562.343773] usb 1-5.3: Manufacturer: Iomega Dec 3 10:59:45 tlondon kernel: [ 7562.343779] usb 1-5.3: SerialNumber: FF310005280000000000009FF307FF Dec 3 10:59:46 tlondon mtp-probe: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.3" Dec 3 10:59:46 tlondon mtp-probe: bus: 1, device: 11 was not an MTP device Dec 3 10:59:46 tlondon kernel: [ 7562.937894] usbcore: registered new interface driver uas Dec 3 10:59:46 tlondon kernel: [ 7562.955311] Initializing USB Mass Storage driver... Dec 3 10:59:46 tlondon kernel: [ 7562.956183] scsi4 : usb-storage 1-5.3:1.0 Dec 3 10:59:46 tlondon kernel: [ 7562.959108] usbcore: registered new interface driver usb-storage Dec 3 10:59:46 tlondon kernel: [ 7562.959112] USB Mass Storage support registered. Dec 3 10:59:47 tlondon kernel: [ 7563.967845] scsi 4:0:0:0: Direct-Access Iomega E xternal HD 0000 PQ: 0 ANSI: 4 Dec 3 10:59:47 tlondon kernel: [ 7563.994560] sd 4:0:0:0: Attached scsi generic sg2 type 0 Dec 3 10:59:47 tlondon kernel: [ 7563.994960] sd 4:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) Dec 3 10:59:47 tlondon kernel: [ 7564.001464] sd 4:0:0:0: [sdb] Write Protect is off Dec 3 10:59:47 tlondon kernel: [ 7564.008164] sd 4:0:0:0: [sdb] No Caching mode page present Dec 3 10:59:47 tlondon kernel: [ 7564.008168] sd 4:0:0:0: [sdb] Assuming drive cache: write through Dec 3 10:59:47 tlondon kernel: [ 7564.026253] sd 4:0:0:0: [sdb] No Caching mode page present Dec 3 10:59:47 tlondon kernel: [ 7564.026258] sd 4:0:0:0: [sdb] Assuming drive cache: write through Dec 3 10:59:47 tlondon kernel: [ 7564.036853] sdb: sdb1 Dec 3 10:59:47 tlondon kernel: [ 7564.053814] sd 4:0:0:0: [sdb] No Caching mode page present Dec 3 10:59:47 tlondon kernel: [ 7564.053819] sd 4:0:0:0: [sdb] Assuming drive cache: write through Dec 3 10:59:47 tlondon kernel: [ 7564.053828] sd 4:0:0:0: [sdb] Attached SCSI disk Dec 3 10:59:47 tlondon ata_id[8553]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument Version-Release number of selected component (if applicable): udev-175-1.fc17.x86_64 kernel-3.2.0-0.rc4.git1.4.fc17.x86_64 How reproducible: Appears every time I power up/plugin USB drive Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I can manually mount/umount the LUKS/ext4 fs manually after the above error using: cryptsetup luksOpen /dev/sdb1 external mount /dev/mapper/external /mnt ... umount /mnt cryptsetup luksClose external
Google provides this: Drive errors in the system log files /dev/sda: HDIO_GET_IDENTITY failed: Invalid argument This error is produced by hdparm when using the -i switch on some SCSI and SATA disk drives. hdparm was not designed to be used with SCSI or SATA drives. No tweaks that hdparm can provide are needed for SCSI or SATA drives. Fix: Disable any Cpanel IDE hard drive tweaks and remove any hdparm settings in local startup files.
Hello Tom. Have You experienced the same behavior with Fedora 15 or 16 ? Regards, Jaromir.
No, this is a quite recent change (4-6 weeks) of rawhide. Prior to that, this worked well, and I had no problem running my 'rsync backup' to my USB hard drive.
Ok ... I have a different question ... does it work with a vfat formated USB flash?
I've checked f15 and rawhide sources and both of them contain rules for fallback from ata_id to usb_id ... therefore it doesn't seem to be directly related to the ata_id failure. But ... we could try to do a simple test. 1.) Backup Your /lib/udev/ata_id binary somewhere ... 2.) mv /lib/udev/ata_id /lib/udev/ata_id.orig 3.) (echo '#!/bin/bash';echo '/lib/udev/ata_id.orig $@';echo 'exit 0')>/lib/udev/ata_id 4.) chmod 755 /lib/udev/ata_id and then test it again
I hope You can manage the unwanted line wrapping between 3.) and 4.) in my last comment ...
To avoid confusions ... this is the step #3 split to 5 lines ... ( echo '#!/bin/bash' echo '/lib/udev/ata_id.orig $@' echo 'exit 0' ) > /lib/udev/ata_id --------- Please, test it by calling: /lib/udev/ata_id /dev/sdb echo $? it should return 0 and the /var/log/messages should contain the "HDIO_GET_IDENTITY failed" message.
I 'modified' your script just a bit: [root@tlondon ~]# cat /lib/udev/ata_id #!/bin/bash echo "/lib/udev/ata_id.orig $@" >>/tmp/ata_id /lib/udev/ata_id.orig $@ exit 0 [root@tlondon ~]# and did a 'chmod +x /lib/udev/ata_id' and a 'setenforce 0'. When I turn on the USB hard drive, I see this in /var/log/messages: Dec 14 23:58:44 tlondon kernel: [ 1021.787291] usb 1-5.3: new high-speed USB device number 14 using ehci_hcd Dec 14 23:58:44 tlondon kernel: [ 1021.890133] usb 1-5.3: New USB device found, idVendor=059b, idProduct=0370 Dec 14 23:58:44 tlondon kernel: [ 1021.890137] usb 1-5.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Dec 14 23:58:44 tlondon kernel: [ 1021.890140] usb 1-5.3: Product: Iomega Dec 14 23:58:44 tlondon kernel: [ 1021.890142] usb 1-5.3: Manufacturer: Iomega Dec 14 23:58:44 tlondon kernel: [ 1021.890144] usb 1-5.3: SerialNumber: FF310005280000000000009FF307FF Dec 14 23:58:44 tlondon kernel: [ 1021.908165] scsi9 : usb-storage 1-5.3:1.0 Dec 14 23:58:44 tlondon mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.3" Dec 14 23:58:44 tlondon mtp-probe: bus: 1, device: 14 was not an MTP device Dec 14 23:58:45 tlondon kernel: [ 1022.921372] scsi 9:0:0:0: Direct-Access Iomega E xternal HD 0000 PQ: 0 ANSI: 4 Dec 14 23:58:45 tlondon kernel: [ 1022.945123] sd 9:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) Dec 14 23:58:45 tlondon kernel: [ 1022.945336] sd 9:0:0:0: Attached scsi generic sg2 type 0 Dec 14 23:58:45 tlondon kernel: [ 1022.951582] sd 9:0:0:0: [sdb] Write Protect is off Dec 14 23:58:45 tlondon kernel: [ 1022.958102] sd 9:0:0:0: [sdb] No Caching mode page present Dec 14 23:58:45 tlondon kernel: [ 1022.958106] sd 9:0:0:0: [sdb] Assuming drive cache: write through Dec 14 23:58:45 tlondon kernel: [ 1022.974601] sd 9:0:0:0: [sdb] No Caching mode page present Dec 14 23:58:45 tlondon kernel: [ 1022.974607] sd 9:0:0:0: [sdb] Assuming drive cache: write through Dec 14 23:58:45 tlondon kernel: [ 1023.002498] sdb: sdb1 Dec 14 23:58:45 tlondon kernel: [ 1023.018355] sd 9:0:0:0: [sdb] No Caching mode page present Dec 14 23:58:45 tlondon kernel: [ 1023.018360] sd 9:0:0:0: [sdb] Assuming drive cache: write through Dec 14 23:58:45 tlondon kernel: [ 1023.018369] sd 9:0:0:0: [sdb] Attached SCSI disk Dec 14 23:58:45 tlondon dbus-daemon[796]: dbus[796]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Dec 14 23:58:45 tlondon dbus[796]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Dec 14 23:58:45 tlondon ata_id[2613]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument [I deleted the SELinux messages that followed.] I see this in /tmp/ata_id: /lib/udev/ata_id.orig --export /dev/sdb If I now try to run '/lib/udev/ata_id /dev/sdb', I see: Dec 15 00:02:56 tlondon ata_id[2694]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument and /tmp/ata_id has this appended: /lib/udev/ata_id.orig /dev/sdb
BTW, if I plugin in a VFAT thumb drive, I do not see ata_id message in /var/log/messages, nor does the system mount the device. If I manually run '/lib/udev/ata_id --export /dev/sdc', I then get the message in /var/log/messages: [root@tlondon ~]# /lib/udev/ata_id --export /dev/sdc [root@tlondon ~]# echo $? 0 [root@tlondon ~]# and Dec 15 00:05:44 tlondon ata_id[2749]: HDIO_GET_IDENTITY failed for '/dev/sdc': Invalid argument
Appears I need to be in 'permissive mode' to run /lib/udev/ata_id from the console. When I'm in enforcing mode, I get Dec 15 00:18:26 tlondon ata_id[3038]: unable to open '/dev/sdb' when running ata_id from a console. I do not get this when I power on the drive (just when I run it from the console).
Ok ... so, to make it more clear ... the ata_id now returns 0 as exitcode even if the ata_id.orig fails, but the volume is still not mounted automatically when You plug the USB drive in, right? (Sorry, I forgot I have SELinux disabled temporarily, but You apparently managed that well). Do You use Gnome/KDE/Xfce or something else?
I use Gnome.
I just installed rawhide and tested that in Xfce and Gnome. I had to enable volume management in Xfce/Thunar first, but it works correctly in both sessions. I can't reproduce this issue. Could You please install the latest updates and then test that again with the VFAT formatted USB flash?
Sure. I pretty much run Rawhide/koji. Below shows output of yum showing "no more updates", plus an 'inotail -f /var/log/messages' showing the messages I get when I insert a USB Flash drive: [root@tlondon ~]# yum update Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit Setting up Update Process No Packages marked for Update [root@tlondon ~]# inotail -f /var/log/messages Dec 15 07:01:01 tlondon systemd-logind[750]: New session 3 of user root. Dec 15 07:01:01 tlondon systemd-logind[750]: Removed session 3. Dec 15 07:05:02 tlondon kernel: [ 525.629463] rhythmbox used greatest stack depth: 2160 bytes left Dec 15 07:11:17 tlondon systemd-tmpfiles[2214]: Successfully loaded SELinux database in 16ms 370us, size on heap is 504K. Dec 15 07:12:15 tlondon ntpd[743]: 0.0.0.0 c612 02 freq_set kernel 20.318 PPM Dec 15 07:12:15 tlondon ntpd[743]: 0.0.0.0 c615 05 clock_sync Dec 15 07:45:39 tlondon dbus-daemon[771]: dbus[771]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Dec 15 07:45:39 tlondon dbus[771]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Dec 15 07:45:40 tlondon dbus[771]: [system] Successfully activated service 'org.freedesktop.PackageKit' Dec 15 07:45:40 tlondon dbus-daemon[771]: dbus[771]: [system] Successfully activated service 'org.freedesktop.PackageKit' Dec 15 07:54:34 tlondon kernel: [ 3497.502192] usb 2-2: new high-speed USB device number 2 using ehci_hcd Dec 15 07:54:34 tlondon kernel: [ 3497.618807] usb 2-2: New USB device found, idVendor=1e3d, idProduct=2093 Dec 15 07:54:34 tlondon kernel: [ 3497.618819] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 15 07:54:34 tlondon kernel: [ 3497.618827] usb 2-2: Product: v3.3.9.1 Dec 15 07:54:34 tlondon kernel: [ 3497.618834] usb 2-2: Manufacturer: CHIPSBNK Dec 15 07:54:34 tlondon kernel: [ 3497.618840] usb 2-2: SerialNumber: 0910440064456F05 Dec 15 07:54:34 tlondon mtp-probe: checking bus 2, device 2: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-2" Dec 15 07:54:34 tlondon mtp-probe: bus: 2, device: 2 was not an MTP device Dec 15 07:54:34 tlondon kernel: [ 3498.012888] usbcore: registered new interface driver uas Dec 15 07:54:35 tlondon kernel: [ 3498.032955] Initializing USB Mass Storage driver... Dec 15 07:54:35 tlondon kernel: [ 3498.037341] scsi4 : usb-storage 2-2:1.0 Dec 15 07:54:35 tlondon kernel: [ 3498.043279] usbcore: registered new interface driver usb-storage Dec 15 07:54:35 tlondon kernel: [ 3498.043284] USB Mass Storage support registered. Dec 15 07:54:36 tlondon kernel: [ 3499.046443] scsi 4:0:0:0: Direct-Access CHIPSBNK v3.3.9.1 5.00 PQ: 0 ANSI: 2 Dec 15 07:54:36 tlondon kernel: [ 3499.071871] sd 4:0:0:0: [sdb] 1966080 512-byte logical blocks: (1.00 GB/960 MiB) Dec 15 07:54:36 tlondon kernel: [ 3499.072862] sd 4:0:0:0: [sdb] Write Protect is off Dec 15 07:54:36 tlondon kernel: [ 3499.073578] sd 4:0:0:0: [sdb] No Caching mode page present Dec 15 07:54:36 tlondon kernel: [ 3499.073582] sd 4:0:0:0: [sdb] Assuming drive cache: write through Dec 15 07:54:36 tlondon kernel: [ 3499.077738] sd 4:0:0:0: Attached scsi generic sg2 type 0 Dec 15 07:54:36 tlondon kernel: [ 3499.079248] sd 4:0:0:0: [sdb] No Caching mode page present Dec 15 07:54:36 tlondon kernel: [ 3499.079252] sd 4:0:0:0: [sdb] Assuming drive cache: write through Dec 15 07:54:36 tlondon kernel: [ 3499.080539] sdb: sdb1 Dec 15 07:54:36 tlondon kernel: [ 3499.085755] sd 4:0:0:0: [sdb] No Caching mode page present Dec 15 07:54:36 tlondon kernel: [ 3499.085760] sd 4:0:0:0: [sdb] Assuming drive cache: write through Dec 15 07:54:36 tlondon kernel: [ 3499.085768] sd 4:0:0:0: [sdb] Attached SCSI removable disk 'ls -l /dev/' shows that the special files were created: [tbl@tlondon ~]$ ls -l /dev/sdb* brw-rw----. 1 root disk 8, 16 Dec 15 07:54 /dev/sdb brw-rw----. 1 root disk 8, 17 Dec 15 07:54 /dev/sdb1 [tbl@tlondon ~]$ But 'df' does not show the fs mounted: [tbl@tlondon ~]$ df df: `/var/lib/nfs/rpc_pipefs': Permission denied Filesystem 1K-blocks Used Available Use% Mounted on rootfs 481533604 370896132 86534972 82% / devtmpfs 1948228 0 1948228 0% /dev tmpfs 1992748 1356 1991392 1% /dev/shm tmpfs 1992748 51492 1941256 3% /run /dev/mapper/vg_tlondon-lv_root 481533604 370896132 86534972 82% / tmpfs 1992748 51492 1941256 3% /run tmpfs 1992748 0 1992748 0% /sys/fs/cgroup tmpfs 1992748 51492 1941256 3% /var/run tmpfs 1992748 51492 1941256 3% /var/lock tmpfs 1992748 0 1992748 0% /media /dev/sda1 202770 113211 79319 59% /boot [tbl@tlondon ~]$ And there are no mount points in /media: [tbl@tlondon ~]$ ls -la /media total 4 drwxr-xr-x. 2 root root 40 Dec 15 06:56 . dr-xr-xr-x. 25 root root 4096 Nov 11 04:54 .. [tbl@tlondon ~]$ Also, I can manually mount the fs: [root@tlondon ~]# mount /dev/sdb1 /mnt [root@tlondon ~]# [root@tlondon ~]# ls /mnt Backbase Research.docx HeroesPremierAnnouncement.pdf Beverly Hills Gateway Tower.pdf LNT_61,_65,_66_Series_Firmware.exe [root@tlondon ~]# Next, if I 'umount /mnt' and run 'nautilus', the device shows up in the 'Devices' list and I can mount it there. Finally, if I power up my USB hard drive, I also see it in the nautilus Devices list, and I can mount it there: Dec 15 08:01:55 tlondon ata_id[11908]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument Dec 15 08:02:57 tlondon kernel: [ 4000.580567] padlock_sha: VIA PadLock Hash Engine not detected. Dec 15 08:02:57 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/3.2.0-0.rc5.git2.2.fc17.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device Dec 15 08:02:58 tlondon kernel: [ 4001.459489] EXT4-fs (dm-2): warning: checktime reached, running e2fsck is recommended Dec 15 08:02:58 tlondon kernel: [ 4001.516410] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) Dec 15 08:02:58 tlondon dbus-daemon[771]: Cd-WARNING **: CdProfileStore: failed to get filesystem type: Error getting filesystem info: Permission denied [In the above, I only listed the log messages from the 'HDIO_GET_IDENTITY failed' message.]
Well ... this really doesn't seem to be udev related. This is a matter of the volume manager used by Your WM session. The volumes and their automounts were previously managed by the gnome-volume-manager, later by nautilus (it was running in the background and waiting for events), but now they're handled by the gnome-setting-daemon and it's possible, that it's just a matter of the gnome configuration. Have You tried to create a new user (with clean home) and test it from his account? Anyway ... I'm changing the component to gnome-settings-daemon. It would be nice if You plug the USB flash in and then collect the following info: udisks --dump > udisks-dump.txt and attach the udisks-dump.txt to this bug ... The gnome-settings-daemon maintainer could either help You or change the component back if he believes it's really udev related, but I'm strongly convinced it isn't.
Created attachment 548238 [details] Output of 'udisks --dump' with USB thumb drive inserted, but not "automagic" mount Thanks for the help. Per #16, I'm attaching the output of 'udisks --dump'
Using Fedora 16 after updating today (which bought in KDE 4.8.1 and 3.2.10-3.fc16.x86_64) I am also seeing this message in the logs - I am unable to connect to my external disk although using comment 1 instructions does work.
I got it on console
(In reply to comment #19) > I got it on console init level 3 udev-173-3.fc16.i686 kernel-3.3.4-3.fc16.i686 May 7 12:47:16 serjux kernel: [822842.433098] usb 1-1: new high-speed USB device number 2 using ehci_hcd May 7 12:47:16 serjux kernel: [822842.554481] usb 1-1: New USB device found, idVendor=07ab, idProduct=fc73 May 7 12:47:16 serjux kernel: [822842.554491] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 May 7 12:47:16 serjux kernel: [822842.554499] usb 1-1: Product: Freecom MD Classic 3.0 May 7 12:47:16 serjux kernel: [822842.554505] usb 1-1: Manufacturer: Freecom May 7 12:47:16 serjux kernel: [822842.554511] usb 1-1: SerialNumber: 0000000000006136 May 7 12:47:16 serjux kernel: [822842.930586] Initializing USB Mass Storage driver... May 7 12:47:16 serjux kernel: [822842.930832] scsi2 : usb-storage 1-1:1.0 May 7 12:47:16 serjux kernel: [822842.931239] usbcore: registered new interface driver usb-storage May 7 12:47:16 serjux kernel: [822842.931245] USB Mass Storage support registered. May 7 12:47:18 serjux kernel: [822844.229985] scsi 2:0:0:0: Direct-Access SAMSUNG HM100UI 2AM1 PQ: 0 ANSI: 2 May 7 12:47:18 serjux kernel: [822844.233194] sd 2:0:0:0: Attached scsi generic sg2 type 0 May 7 12:47:18 serjux kernel: [822844.235683] sd 2:0:0:0: [sdb] 1953525165 512-byte logical blocks: (1.00 TB/931 GiB) May 7 12:47:18 serjux kernel: [822844.236418] sd 2:0:0:0: [sdb] Write Protect is off May 7 12:47:18 serjux kernel: [822844.237169] sd 2:0:0:0: [sdb] No Caching mode page present May 7 12:47:18 serjux kernel: [822844.237288] sd 2:0:0:0: [sdb] Assuming drive cache: write through May 7 12:47:18 serjux kernel: [822844.242786] sd 2:0:0:0: [sdb] No Caching mode page present May 7 12:47:18 serjux kernel: [822844.242840] sd 2:0:0:0: [sdb] Assuming drive cache: write through May 7 12:47:18 serjux kernel: [822844.250260] sdb: sdb1 May 7 12:47:18 serjux kernel: [822844.259428] sd 2:0:0:0: [sdb] No Caching mode page present May 7 12:47:18 serjux kernel: [822844.259540] sd 2:0:0:0: [sdb] Assuming drive cache: write through May 7 12:47:18 serjux kernel: [822844.259658] sd 2:0:0:0: [sdb] Attached SCSI disk May 7 12:47:19 serjux ata_id[8049]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument May 7 12:47:22 serjux kernel: [822848.033968] usb 1-1: USB disconnect, device number 2
Hi, I plug my "Freecom MD Classic 3.0", that I wrote about in previous comment, in my laptop (other Fedora 16), which work in 64 bits and connect without problem. I just got this warning : [ 6440.940038] EXT4-fs (sdb1): mounting ext3 file system using the ext4 subsystem [ 6441.014565] EXT4-fs (sdb1): warning: checktime reached, running e2fsck is recommended [ 6441.016992] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) So I had done $ e2fsck /dev/sdb1 e2fsck 1.41.14 (22-Dec-2010) FREECOM has gone 290 days without being checked, check for Pass 1: Checking inodes, block Error reading block 114015883 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 28475395. Ignore error<y>? no Extended attribute in inode 40984954 has a value size (0) which is invalid Clear<y>? yes after clean this minor errors, I get back to my old laptop with 32 bits and pluged I got this message in /var/log May 12 01:42:14 serjux ata_id[26539]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument but sdb1 was identified , and I could mount it without problems, before e2fsck I got hub 1-0:1.0: unable to enumerate USB device on port 1
This bug is actually udev and hdparm, I believe. See original thread with patch: https://bugs.archlinux.org/task/27060 And from there, link to applied patch: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=4b50a3d0048d13f6e37126f20f96e8bef262cbe2
(In reply to comment #22) > This bug is actually udev and hdparm, I believe. See original thread with > patch: > https://bugs.archlinux.org/task/27060 > > And from there, link to applied patch: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit; > h=4b50a3d0048d13f6e37126f20f96e8bef262cbe2 hide message will not fix my problem ... , but could be other problem I will check that, soon as possible.
Why is an error message returned by ata_id (and part of udev/systemd) assigned to gnome-settings-daemon, I have no idea.
Hello Bastien. Forget the ata_id part of this bug. The whole issue is about inability of the volume manager to automount hot-plugged volumes. Tom just thought it's related to the ata_id message, but later we found, that it has nothing to do with that. The bug description should be changed to something relevant. Regards, Jaromir.
Changing subject. Reassigning from udev back to g-s-d.
gvfs (and lower down the stack, udisks2 and udev) handle the detection of removable media, and gnome-shell handles the automounting. Attach the output of: udisksctl dump and gvfs-mount -li to this bug. Reassigning to gnome-shell as the top-level component of the stack.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.