[Bug 466575] Re: secure remove of external USB-HDD produces error
** Attachment added: "udisks-helper-drive-detach" http://launchpadlibrarian.net/52495957/udisks-helper-drive-detach -- secure remove of external USB-HDD produces error https://bugs.launchpad.net/bugs/466575 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 466575] Re: secure remove of external USB-HDD produces error
** Attachment added: "job-drive-detach.c.orig" http://launchpadlibrarian.net/52495946/job-drive-detach.c.orig -- secure remove of external USB-HDD produces error https://bugs.launchpad.net/bugs/466575 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 466575] Re: secure remove of external USB-HDD produces error
** Attachment added: "job-drive-detach.c" http://launchpadlibrarian.net/52495942/job-drive-detach.c -- secure remove of external USB-HDD produces error https://bugs.launchpad.net/bugs/466575 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 466575] Re: secure remove of external USB-HDD produces error
Having done some tests with various drives, I have come to believe that
it is actually safe to ignore the error messages produced by sg3-utils.
I think so for the following reasons:
1. I could not find evidence that Hardy Heron (the release I used before Lucid)
made use of sg3-utils to flush caches/stop devices before unmounting USB
devices. And still, the filesystems were closed cleanly.
2. Even if Hardy made use of the problematic sg3-utils functions
("sg_ll_sync_cache_10" and "sg_ll_start_stop_unit"), they still would have
failed, because the relevant code is identical.
3. Even though the sg3 functions fail, udisks-daemon still invokes the "umount"
command, so the filesystem is not left in an inconsistent state, when the
device is removed.
For these reasons, I slightly modified udisks-helper-drive-detach to
simply not report back error messages to the user. It still invokes the
error-producing sg3 functions, but does not pass the errors on to the
user. This way, the functions are still called for devices where they
can be executed successfully. And for the devices where they fail, it is
not any different - only that the user does not know anything about
this. Anyhow, I have come to believe that the errors are caused by a
crappy implementation of the SCSI protocol by my USB disk, which is in
arbitrary 3.5" disk in a cheap disk enclosure, which I bought
separately. The controller of the enclosure seems to produce errors no
matter what command you throw at it. :-/
I am attaching the modified version of "job-drive-detach.c", which only
differs from the original version ("job-drive-detach.c.orig") by one
statement (setting return value to success; line 213). For your
convenience, I'm also attaching a precompiled version of "udisks-helper-
drive-detach", which is responsible for passing the error to the user.
If you are fed up with the error messages like me, place the file in
/usr/lib/udisks and you won't be bothered anymore. Make sure to create a
backup of the original file. Also you will have to place my modified
version there, whenever an update overwrites it (which doesn't happen
too often anyway).
Please note that this is not really a patch, as it does not fix the
underlying problem. But I don't really mind, since it wasn't any
different in Hardy. The only difference is that I didn't notice it back
then and now I am bothered with it every time I unplug a device. If you
think so, too, then you are welcome to use my modified version of
"udisks-helper-drive-detach".
--
secure remove of external USB-HDD produces error
https://bugs.launchpad.net/bugs/466575
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 466575] Re: secure remove of external USB-HDD produces error
Having the same issue with two USB disks: SAMSUNG_SV2042H and
Myson_Century__Inc._USB_Mass_Storage_Device_100.
I did some debugging and this is what I came up with:
When you right-click on a USB drive and choose "Safely remove drive", this is
what happens in the background:
1. Nautilus calls udisks --umount "
2. udisks contact a background-process named "udisks-daemon".
3. udisks-daemon inturn invokes "/usr/lib/udisks/udisks-helper-drive-detach".
4. udisks-helper-drive-detach calls some sg3-utils to synchronize the cache and
stop the device ("sg_ll_sync_cache_10" at line ~184 and "sg_ll_start_stop_unit"
at line ~202 in source file "job-drive-detach.c"). Both of these functions
return an error message.
You can easily reproduce the error messages caused by sg3-utils by
running the sg3-utils manually. In order to reproduce the first error
message ("SYNCHRONIZE CACHE: FAILED: No such file or directory"), run
this command:
sg_sync --verbose
Example: sg_sync --verbose /dev/sdc
This yields the precise error message returned by the sg3 backend:
synchronize cache(10) cdb: 35 00 00 00 00 00 00 00 00 00
synchronize cache(10): Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
bad field in Synchronize cache command
In order to reproduce the second error message ("STOP UNIT: FAILED: No
such file or directory"), run this command:
sg_start --stop --verbose
Example: sg_start --stop --verbose /dev/sdc
Again, this yields a more precise error message than the general "No
such file or directory" as shown by the graphical front-end:
Start stop unit command: 1b 00 00 00 00 00
start stop unit: Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
invalid field in cdb
START STOP UNIT command failed
In conclusion, it looks like the sg3-utils send the wrong commands to
the SCSI layer or wherever these commands go (I am not that much into
low level SCSI programming, my apologies). However, I don't see any
adverse effects from these erroneous commands. Even though the sg3-utils
functions return an error, udisk-daemon properly continues and cleanly
unmounts the USB drive as far as I can tell (it invokes umount, which
should sync the cache anyway). To try this out, I removed the two calls
to the functions "sg_ll_sync_cache_10" and "sg_ll_start_stop_unit" from
the source code of udisks "job-drive-detach.c" and recompiled the thing.
Nautilus stopped whining about the failure of these two functions and
the drives are unmounted perfectly. :-)
I would have attached a patch, but I do not really have a clue about
what these two functions do precisely. In fact, it might have been a bad
thing to remove the function calls from "job-drive-detach.c". I cannot
say, if this may result in loss of data (someone with some SCSI
programming knowledge please explain). Plus, I imagine that for most
users it may actually be useful that these functions are called. So it
would not really be a patch.
--
secure remove of external USB-HDD produces error
https://bugs.launchpad.net/bugs/466575
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 549727] Re: [10.04] Touchpad stops working after login
Poster #83 got it right. The issue is caused by gnome-settings-daemon. There is, however, no need to adjust/recompile any code. Hi, I was having the same issue. I believe that the Synaptics touchpad driver and Gnome both disable the touchpad individually. For some reason, Gnome (in particular gnome-settings-daemon) fails to re-enable it; which is why you end up with a dead touchpad, once you disable it. Here is what fixed it for me (HP Pavilion DV6730ec): First of all, open a terminal. Press Alt+F1 to open the applications menu and choose the Terminal application from the accessories or use an external mouse to so. To bring your touchpad back to life, enter the following command: Code: gconftool --type bool --set /desktop/gnome/peripherals/touchpad/touchpad_enabled true The key "/desktop/gnome/peripherals/touchpad/touchpad_enabled" is where gnome-settings-daemon remembers that you disabled your touchpad. This is the reason, why it is disabled even after a reboot. The issue will re-appear, next time you disable your touchpad. You need to prevent gnome-settings-daemon from disabling your touchpad in the first place, because the Synaptics touchpad driver does this already. To do so, run the following command in a terminal: Code: gconftool-2 --type string --set /apps/gnome_settings_daemon/keybindings/touchpad "" This dissociates the key to lock your touchpad from gnome-settings- daemon. If for any reason, the latter command breaks the lock touchpad support for you, than you probably have a different issue. To re- associate the key with gnome-settings-daemon, run this command: gconftool-2 --type string --set /apps/gnome_settings_daemon/keybindings/touchpad XF86TouchpadToggle Hope this helps. I recommend rebooting after this procedure and check if this really fixed it for good. I noticed that the error only occurs only once after a reboot. -- [10.04] Touchpad stops working after login https://bugs.launchpad.net/bugs/549727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 509660] Re: Unlock dialog should be displayed when resuming from standby or hibernation
Until this is fixed, you might want to use this workaround that I scripted quickly: create a file /etc/pm/sleep.d/90-gnome-screensaver.sh with the following content: --- snip --- #!/bin/sh . /usr/share/acpi-support/power-funcs case "$1" in thaw) # now, we should poke xscreensaver so you get a dialog if pidof gnome-screensaver > /dev/null; then for x in /tmp/.X11-unix/*; do displaynum=`echo $x | sed s#/tmp/.X11-unix/X##` getXuser; if [ x"$XAUTHORITY" != x"" ]; then export DISPLAY=":$displaynum" su $user -c "(gnome-screensaver-command --poke)" fi done fi ;; *) ;; esac --- snip --- Then, make the script executable: chmod a+x /etc/pm/sleep.d/90-gnome- screensaver.sh The script is largely based on a script that was included for xscreensaver in hardy. I just adapted it for gnome-screensaver. -- Unlock dialog should be displayed when resuming from standby or hibernation https://bugs.launchpad.net/bugs/509660 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
