do not eject all USB/Firewire devices

Thanks for your bug report. Which version of Ubuntu do you use? Do you still have the same problem?

I am currently on holiday, and will be back in a week, but this occurred for me with both dapper and edgy. I have not yet tried fiesty, but will once I get back home. What is the expected behaviour that I should be seeing in this case? Cheers

This was fixed in fiesty UNTIL hal version 0.5.8.1-4ubuntu12 was published - the problem seems to be the readdition of 10.storage-policy.fdi - if this is removed, it works as expected - ie. I can continously mount and unmount a device from nautilus.

So I would say the problem is actually in hal, not g-v-m, can this be reassigned?

I added hal, but I wasn't sure about g-v-m so I left it there for a more experienced user...

Closing g-v-m task, it has nothing to do with this.

Right, some devices need to be ejected, and we have done so for a long time, so I re-added the fdi for it. This needs to be cleaned up properly for gutsy, where we should collect devices which need ejection. It generally works fine to eject all USB/Firewire devices, and e. g. on my computer I can also re-mount them, so this is quite hardware-specific.

Martin:
Your workaround works for me! Thanks.
I hope an update will be released soon.

@Sander50: What workaround??

@pitti: In general I think it *doesn't* work fine to eject all usb devices - especially external USB hard drives - flash drives seem to work okay - except they can't be remounted afterwards and need to be physically removed and reinserted first - but I have an external hard drive which at the moment can't even be ejected - and the same is occurring for anumber of other users - see bug #99498 - which is a pretty bad regression as they can only me unmounted / ejected from the command-line....

So I agree - in general we should only eject those devices which NEED ejection - ipods and the like - but those which can be happily unmounted - usb flash and hard drives to name a few - should NOT require eject...

I disagree that it is a regression that is critical for Feisty; after all, we have ejected all removable devices since Breezy or so. However, I do acknowledge that it causes trouble, so I'll fix it in Gutsy.

But it seems like this (not being able to eject devices using nautilus / drive-mount applet) is definitely a new problem - at least for me I never had problems like this before, and thus this a regression for me - has anything else changed such as the method used to eject the devices which could account for it - ie. I can only eject the device from the command line if I use sudo, but it cannot be ejected using nautilus or the drive-mount applet or using eject as a normal user and thus this problem would appear to be some sort of permissions problem...

I don't understand why this is delayed so long, 6 months is a pretty long time imho, and this would be a usability enhancement, which would I think ease the transision from other OSes for people. This just mixes people up, can I or can I not remove my hdd, because they can't check in syslog if the device was properly unmounted, so the pending write operations terminated. Also, it was working for a while in feisty too, but then this fdi rules file was added for some reason. It is very strange that stuff that can't and doesn't need to be ejected is forced to be ejected, why is this needed?

Interestingly, while I can't eject my external usb harddrive, I can still eject my usb thumb drive, so I have attached the output from DebuggingRemovableDevices from the wiki with first the usb flash (thumb) drive which can be correctly ejected, and then the external usb harddrive which can't be ejected...

udev.log with thumb drive

dmesg with thumb drive - note before running these debugging steps I had previously inserted and ejected the drives a couple times so only the last bit is probably relevant

devices.txt listing sd* devices in /dev

other outputs requested - ie id etc

alex@navajo:~$ id
uid=1000(alex) gid=1000(alex) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),110(netdev),111(lpadmin),113(powerdev),114(scanner),116(admin),1000(alex)
alex@navajo:~$ id hal
id: hal: No such user
alex@navajo:~$ id haldaemon
uid=107(haldaemon) gid=112(haldaemon) groups=112(haldaemon),24(cdrom),25(floppy),46(plugdev),113(powerdev)
alex@navajo:~$ uname -a
Linux navajo 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

Now is attached the same but when the external usb harddrive is attached - I also tried ejecting it so the output in gvm from trying to do that is there too

dmesg output for external usb harddrive which cannot be ejected - Since I did this after the thumbdrive stuff above it also includes that as well...

ls of /dev/sd* with external usb harddrive connected

I think this is a major bug that should've been eliminated right away, this is plain amazing, people not being able to unmount their external usb hdds is a very important bug!
Some people are saying this worked a few weeks ago, why not just roll back this /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi file? btw why is there no place where one can check previous versions of packages? I know it would take a lot of space, but still, it would be a great addition!
I simply can't understand how this bug can be ignored.
Also, I have just seen that the importance has been changed to medium, I am not sure how importance is calculated, but from the number of confirmations I would say this is almost as bad of a bug as a kernel not being able to boot.

even using the /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi file from the edgy version of hal helps, although it does print out errors about not being able to eject the medium, it does unmount it after all.

I agree that this is an extremely serious bug, which should be fixed as soon as possible. Ubuntu is supposed to be the user-friendly Linux dist, right? Well, one of the most common things the average user does is attach external USB devices (ie. pen drives and hard drives). If a user gets an error every time they try to eject a device, that's a very obvious, aggravating, negative experience.

I'm actually a Linux power user, but when I was considering switching to Ubuntu, one of the first things I tried on the test CD was whether USB drives were auto-detected and handled easily and transparently. It wasn't quite a deal-breaker, but it was an obvious indicator of how polished the UI was. Sure, I can sudo it on the command line; that's not the point. The point is, I really shouldn't _have_ to.

Whoops- I should add that I DO use Ubuntu and have for some time, and in general I love it. :-) But this bug definitely feels like regression to me.

I wonder if a shout to someone would do, or where could one drop it? ubuntu forums? something?

I think the problem is that the fix is a deeper one and this wouldn't fit with the freeze version. But I think that's what we have the rep feisty-updates for. Btw Kubuntu had a similar problem in Dapper or Breezy, don't know anymore, but they had fixed it after release.

Please, if you want to shout, do it in a forum. A bug report is meant to be just that: a report. Comments should be adding new information or discussing a fix. It bites me too, but please relax and let the developers do their job. It's far easier for them if they don't have to filter the comments in a report. Otherwise, the more popular ubuntu becomes, the more difficult it will be to get things done. For example, this bug report has already 10 duplicates. That means, no insult intended, ten people who discovered the same problem, felt they had to report about it, but failed to scan launchpad for a similar report.

dmesg output when inserting and ejecting an USB external harddrive. It is a Zynet Monster 3 IN 1 Data Center, which is a USB 2.0 Hub + Flash Card Readers + USB hard drive combo. The USB/Firewire -> IDE adapter included in this device is produced by Initio. Ejecting the external hard drive used to work in Edgy and Dapper, but not now. Ejecting USB flash drives connected to this device still works well.

BTW, Feisty can eject my 2.5" USB hard drive well. It's also a Zynet enclosure, but has a Cypress Semiconductor Corp. USB-2.0 IDE Adapter.

Feisty can eject this external hard drive well.

Okay, I found some working policy files in the opensuse HAL package, I'm not sure how clean this is, or whether it'll blow up something (I'd think not as they use the same version of HAL), so here are the files, if someone's brave enough to test them, please do, check ubuntuforums post http://ubuntuforums.org/showpost.php?p=2539063&postcount=49 in thread http://ubuntuforums.org/showthread.php?t=401591 for info about this workaround. Also, I'm not sure you need both files, I'll try with only one or the other, the only problem is I have to reboot every time.

I guess the 99-storage-policy-fixed-drives.fdi policy file is not needed.

Just for the record: among the three external hard drives I have access to, feisty can eject two Cypress CY7C68300C-56PVXC based external hard drives smoothly; it cannot eject the one based on Initio INIC-1530L. Perhaps it is a bug in the usb_storage driver?

I hope the problem will be fixed soon. In the meanwhile, I'll just use the pumount command to unmount the INIC-1530L based external hard drive.

This is *very* probably a HAL bug, if you can mount/unmont the thing, it means the kernel driver and udev is working properly, as the device node is created. Can you please try with the above ( https://bugs.launchpad.net/ubuntu/+source/gnome-volume-manager/+bug/63090/comments/33 ) workaround?

J wrote:
> This is *very* probably a HAL bug, if you can mount/unmont the thing, it
> means the kernel driver and udev is working properly, as the device node
> is created. Can you please try with the above (
> https://bugs.launchpad.net/ubuntu/+source/gnome-volume-
> manager/+bug/63090/comments/33 ) workaround?

Just tried your 20-storage-methods.fdi. It doesn't solve the problem for
the INIC-1530L based external hard drive.

I've also got the same prob when I've upgrade to Feisty

Some work around with nautilus-scripts.

$ gedit .gnome2/nautilus-scripts/Eject
-Paste----------------------------------------------------
for uri in $NAUTILUS_SCRIPT_SELECTED_URIS; do
 device=`echo $uri | sed 's/file:\/\///g'`
 gksudo "eject $device" &
done
------------------------------------------------------------
add below to /etc/sudoers to skip enter passwd for ejects only.
%admin eject = NOPASSWD:/usr/bin/eject

Is it possible that part of the problem is because the value in /sys/block/sdb/removable is 0 not 1?

After installing the hal update (0.5.9-1ubuntu2~feisty1) released several days ago, eject becomes unmount on the context menu for USB hard drives. I think It is a workaround for this problem, but it's not a nice solution.

This is still an issue, and there are numerous bug reports and complaints in the forums. This is a pretty major bug, and yes it is a regression. It has been 8 months with still no fix in place.

Bug is solved upstream. So wait for a backport of hal

Linux hb 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

On my machine the problem is solved. I can unmount devices (USB, ext. IDE) no problem.

Wolf

This has been fixed a while ago in version 0.5.9-1ubuntu1 in gutsy.

This version is in feisty-backports, too, so feel free to install this on feisty if it causes problems for you in feisty.

Adding Feisty task since the demand for fixing this in Feisty is quite high. However, we have ejected all devices since Hoary. It is not such a big problem, after all, and is more convenient if your hard disk has several partitions. With eject, all of them are unmounted at the same time, so that you don't need to unmount every single of them.

For now there is the feisty-backports package of hal, so people who are affected by this can install that.

I believe eject is the expected functionality of an external USB drive. The solution should be to make eject work well with all USB hard drives, and to make gnome-volume-manager aware of ejects, instead of disabling eject.

Based on the observation that eject works well with those Cyrpress-based usb hard drives in Feisty, and with all USB harddrives in Dapper and Breezy, it is probably a kernel regression introduced in Feisty.

Also, I don't think those "eject failure" duplicates are really duplicates of this bug. This bug is about the inconsistent problem in gnome-volume-manager only; i.e., when a USB drive is ejected, it should disppear from the "Computer" window.

the feisty-backports package of hal correct this bug
but with a MacBook2 Feisty64 after upgrading hal
the gnome-power-manager and key F1 & F2 for light don't works

Under MacBook it's better change /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi

Confirming, the feisty-backports package solves the problem by suggesting to unmount a partition instead of ejecting the whole drive.

It's a shame that eject has gone in Gutsy. I have keys with multiple partitions and using eject meant I knew the key could be pulled out because all partitions had been unmounted.

Sitsofe,

If I may quote my comment on bug #36252, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/36252/comments/40 , perhaps if my suggestion (last part) was implemented, it would solve your problem?

[quote]
How Kubuntu does it:
I ejected (allthough it's called 'safely unmount' in Kubuntu Feisty) an external USB harddrive with an ext3 filesystem. It worked exactly as expected:
-The drive spun down and stopped
-The icon disappeared from the desktop
-The drive was no longer accessible

I believe this is how the 'eject' function in Nautilus / gnome-volume-manager should work as well (although I'm not sure how I would want it to behave if I had several partitions on my external drive... probably I would want the system to be smart enough to notice the difference between partitions on a disk and the disk itself. And give two options when I right click on one of those partitions on the desktop: 1) 'Unmount this partition on drive [foo]' and 2) 'Eject entire drive [foo]', followed by a popup, warning the user which partitions will also be unmounted when he/she continues. Or something similar, but this would probably be something for a blueprint? :-) ...).
[/quote]

In other words, would this be worth a blueprint?

This has been fixed a while ago. I suppose to close this in order to reduce the amount of open issues.

I do this for this incident (#63090). If anyone objects, please reopen.

Thanks,

Wolf

This was fixed a while ago. Why carry it with us?

I don't know if hal in feisty backports is solving; I'm not /don't want to use backports (stability reason on professional laptop).
In feisty (official ports) fully updated, this is not solved (see attachement)

Hi all, I have a 500Gb Maxtor external USB HD. It has 2 FAT32 partitions.
I was experiencing the same problem and I tried the suggested workaround:

sudo mv /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi.orig

My question now is: should I worry at all to have (re)moved that file?

Many thanks in advance,
                                         Marco