FS#6030 - [hal] Removal of usb device without unmount freezes hal's usb.
Attached to Project:
Arch Linux
Opened by Bradley (beejayzed) - Monday, 18 December 2006, 02:37 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 14 December 2007, 18:51 GMT
Opened by Bradley (beejayzed) - Monday, 18 December 2006, 02:37 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 14 December 2007, 18:51 GMT
|
Details
I think this is the same or a similar bug:
http://bugs.archlinux.org/task/5582
, except I've found the problem has nothing to do with
ivman.
When a sub storage device is plugged in, hal picks it up and ivman mounts it. If it is unmounted the unplugged, everything works fine. If it is removed without being unmounted though, it is not removed from hal's database. It also remains in /etc/mtab and /proc/mounts. The /dev/sd* entry is removed. When it is plugged back in, even though the e.g /dev/sda* entry is removed, a /dev/sdb* entry is made. The previous stale entry remains in hal's database (in this case /dev/sda). I launched hald with --daemon=no --verbose=yes to see if anything interesting comes up. Hald was started when the usb storage device was already plugged in. The entry for it is /dev/sdb. I mounted it using thunar, then unplugged it. I have attached a file with the parts after: 06:31:59.573 [I] hald.c:619: Device probing completed 06:31:59.573 [I] hald_dbus.c:4074: entering 
hald
(7.5 KiB)
|
This task depends upon
Closed by Aaron Griffin (phrakture)
Friday, 14 December 2007, 18:51 GMT
Reason for closing: None
Additional comments about closing: No response to status request
Friday, 14 December 2007, 18:51 GMT
Reason for closing: None
Additional comments about closing: No response to status request
- stop hal
- insert a USB stick (set the write-protect tab to be sure you don't wreck the contents)
- mount it
- go inside the mountpoint
- pull the stick out
- run "ls"
- if that works, try to cd out of the directory and umount the lost USB stick
- report what happens then
I guess you'll get a shitload of I/O errors and you're unable to umount it, because the kernel just lost a mountpoint.
I'm just thinking of idea of making use of the fact that udev removes dev node when device is removed. :)
This is not related to this "bug" which IMHO can be closed as "Not a bug" (even because if HAL learns how to recover from such bad situations better - it's a mainstream issue, not distro-specific).
Basically, removing a device without unmounting should produce the same enduser results as unmounting it first (except there may be data corruption).
JGC, I did your test. The results are attached.
Basically when it was removed the directory showed up as empty, and no errors came up from umount when it was unmounted.
I noticed dmesg errors came up when trying to ls the mounted directory after the device had been removed. They were:
FAT: Directory bread(block 493) failed
scsi 3:0:0:0: rejecting I/O to dead device
FAT: Directory bread(block 494) failed
scsi 3:0:0:0: rejecting I/O to dead device
(and that block xxx increased to 524)