The ThinkPad UltraBay eject switch causes a udev event, but by default this event is ignored. The effect of this is that you can run into trouble if anything on the block device your trying to eject is mounted. http://www.thinkwiki.org/wiki/How_to_hotswap_Ultrabay_devices The above URL describes how to create a UDEV rule that acts on the Ultrabay eject switch and runs a custom Ultrabay eject script. Note that the Talk page on the wiki contains an alternate eject script. The insert script also mentioned should not be needed for modern kernels, but the HAL script helps to prevent the password prompt for a user to be able to mount a filesystem. It would be nice if DeviceKit-disks could include such a Bay eject handler and script. The tricky part is that there is possibly some overlap with DeviceKit-power since those same Bays can also contain batteries. But batteries do not require any eject handling so that should be fine. Note that there is one other uses case that is not fixed with the above, and that is a password-protected HDD. If you plug in such a disk today into a running system, it seems the libata EH goes crazy (even preventing the system from entering suspend), and the hdparm utility will not allow you to unlock the disk (perhaps because of the EH). It would be nice if somehow the EH would be fixed, and detect the disk is PW protected and cause an event that gnome-disk-utility could act on to ask the user the PW for the disk, which in turn would unlock the disk and allow the filesystems to be mounted.
(In reply to comment #0) > The ThinkPad UltraBay eject switch causes a udev event, but by default this > event is ignored. The effect of this is that you can run into trouble if > anything on the block device your trying to eject is mounted. > > http://www.thinkwiki.org/wiki/How_to_hotswap_Ultrabay_devices > > The above URL describes how to create a UDEV rule that acts on the Ultrabay > eject switch and runs a custom Ultrabay eject script. > > Note that the Talk page on the wiki contains an alternate eject script. > > The insert script also mentioned should not be needed for modern kernels, but > the HAL script helps to prevent the password prompt for a user to be able to > mount a filesystem. > > It would be nice if DeviceKit-disks could include such a Bay eject handler and > script. The tricky part is that there is possibly some overlap with > DeviceKit-power since those same Bays can also contain batteries. But batteries > do not require any eject handling so that should be fine. Most of the infrastructure for doing this is in place already, see http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=5b7350df8b63cf4178a2fe69ee740b5222130421 http://elliotli.blogspot.com/2009/01/safely-remove-usb-hard-drive-in-linux.html http://bugzilla.gnome.org/show_bug.cgi?id=585591 for some background. In a nutshell, DeviceKit-disks now supports a property :drive-can-detach that is TRUE exactly when the a drive can be powered off. The user session can do this via the new DriveDetach() method. The UI for this is already in GNOME too. For non-optical drives, the "Eject" option does this http://people.freedesktop.org/~david/nautilus-poweroff-2.png For optical drives (where "Eject" will eject the media), there is a new menu option called "Safely Remove Drive" http://people.freedesktop.org/~david/nautilus-drive-poweroff.png Note that right now we only support USB optical drives, support for Ultrabay devices is possible to add but it requires that the kernel exports a relationship in sysfs between the bay and disk device. Matthew Garrett (added to Cc) is working with Jeff Garzik on adding this to the kernel. Once this is in the kernel, we can take advantage of it in DeviceKit-disks with having to change anything above it. Note that we still need to add a handler for calling DriveDetach() when the dock button is pressed. I'll add that to Nautilus (which is the policy manager for storage in GNOME, e.g. automounting and so on) once the Ultrabay bits has landed. Shouldn't be much work. > Note that there is one other uses case that is not fixed with the above, and > that is a password-protected HDD. If you plug in such a disk today into a > running system, it seems the libata EH goes crazy (even preventing the system > from entering suspend), and the hdparm utility will not allow you to unlock the > disk (perhaps because of the EH). It would be nice if somehow the EH would be > fixed, and detect the disk is PW protected and cause an event that > gnome-disk-utility could act on to ask the user the PW for the disk, which in > turn would unlock the disk and allow the filesystems to be mounted. This seems to be independent of Ultrabay. I'll look into that when I'll add support in DeviceKit-disks for ATA's SECURITY UNLOCK command (so it is easy to use ATA devices with a password) - the GIO APIs are already there as mentioned in GNOME bug #585591 so adding this should be really easy.
Sorry to bug, but is there any progress in getting the patch upstream to get sysfs to export the relationship between the bay and the disk device?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.