Safely remove is not working (or broken) in Gnome Disks

Bug #1239087 reported by Norbert on 2013-10-12
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
GNOME Disks
Fix Released
Medium
udisks
Confirmed
Medium
gnome-disk-utility (Fedora)
Unknown
Unknown
gnome-disk-utility (Ubuntu)
Undecided
Unassigned
gnome-disk-utility (openSUSE)
Invalid
Medium
oem-workaround-xhci-quirk-dkms (openSUSE)
Fix Released
Medium

Bug Description

In 12.04 I was able to safely remove USB-stick (make its LED off) and USB-HDD (do a spin down).
In 13.04 this option is missed.

In 13.10 it is appeared again, but not working as expected:
+ Gnome Disks normally powers off the USB flash (tested on 4 different flashes and 2 USB cardreaders).
- Gnome Disks does not spin down USB HDD (but udisks --detach does)

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-disk-utility 3.8.2-1ubuntu2
ProcVersionSignature: Ubuntu 3.10.0-1.8-generic 3.10.0-rc7
Uname: Linux 3.10.0-1-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Sat Oct 12 13:39:21 2013
InstallationDate: Installed on 2013-03-06 (219 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130306)
MarkForUpload: True
SourcePackage: gnome-disk-utility
UpgradeStatus: Upgraded to saucy on 2013-06-23 (110 days ago)

Norbert (nrbrtx) wrote :
Changed in gnome-disk-utility:
importance: Unknown → Medium
status: Unknown → Fix Released
Norbert (nrbrtx) wrote :

Bug exists in Saucy final release.

I have Ubuntu 12.04.3 with GNOME 3.4 and udisks 1.0.4-5ubuntu2.1. With this software I can do a Safely remove of a USB-flash or external USB-HDD from nautilus (3.4.2-0ubuntu8) and from gnome-disk-utility (3.0.2-2ubuntu7).

In modern linux distros (such as Ubuntu 13.04, 13.10, Mageia 4, Fedora 19, OpenSuse 12.3) there is no Safely remove option in Nautilus (see https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1067876 and https://bugs.freedesktop.org/show_bug.cgi?id=60293).

In gnome-disks Safely remove / Poweroff is appeared again (from 3.8, see https://bugzilla.gnome.org/show_bug.cgi?id=675542), but it does not spin-down external USB-HDD.

In some linux distros I can spin-down my disk with "udisks --detach /dev/sdX", but it is not user-friendly.

So please, enable spin-down on the udisks side.

I understand that external SATA (and IDE) HDDs are hot-pluggable and hot-swappable, but it is not comfortable for me to detach rotating drive.

Changed in udisks:
importance: Unknown → Medium
status: Unknown → Confirmed

Bug exists in Fedora 20 with gnome-disk-utility 3.10.0
UDisks 2.1.1 (built against 2.1.1).

There is no Safely remove option in Nautilus 3.10.1 too.

Norbert (nrbrtx) wrote :

Bug still exists in Ubuntu 14.04 with all installed updates.

Tested again on Arch with
* gnome-disk-utility 3.10.0 UDisks 2.1.1 (built against 2.1.1)
* Nautilus 3.10.1

- the bug exists with both applications. Please fix it.

Norbert (nrbrtx) on 2014-01-19
tags: added: trusty

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

In previous versions of gnome-disk-utility (palimpsest) users were able to do a Safely remove of USB-flash or USB-HDD.
Let's use GNOME Disks 3.0.2 (as in Ubuntu 12.04.3) as example - it uses UDisks v.1 and I'm able to do safely remove (power off) of USB-flash or spin-down USB-HDD.

OpenSuse 13.1 has gnome-disk-utility 3.10.0
UDisks 2.1.1 (built against 2.1.1)
- this version has Safely remove functionality but it seems that is broken.
What I mean by 'broken'?
If I do Safely remove (press Power off the drive button) of USB-flash - it works correctly - so after Safely remove LED on flash is off.
If I do Safely remove of USB-HDD - it works incorrectly - it does not spin-down my HDD.
If I manually to a Safely remove from console with 'udisks --detach /dev/sdX' - LED on my flash is off and my USB-HDD is spinned down.

So gnome-disks have a bug with Safely remove of USB-HDD.

Reproducible: Always

Steps to Reproduce:
1. Connect USB-HDD to your PC running Fedora 20
2. Do some work on USB-HDD partition(s)
3. Try to do Safely remove of USB-HDD with gnome-disks.
Actual Results:
After safely remove USB-HDD is not spinned-down (keep rotating), removed from system (there is no USB-HDD lsusb) and will spin-down only by disconnecting USB-cable.

Expected Results:
After Safely remove USB-HDD is spinned-down (not rotating) and may be safely removed.

I understand that USB-mass storage devices may be safely detached from computer after unmount (and sync) and that USB-HDD with SATA interface are hot-pluggable and hot-swappable.
But why safely remove functionality is removed in the newest versions of udisks (and Nautilus, Gnome Disks)?
For me it’s more comfortable to detach USB-flash with switched off LED and spinned-down USB-HDD.

The only one working method for safe detaching of USB-device is to call “udisks --detach /dev/sdXN”, but it does not user-friendly and modern GNU/Linux distros does not have udisks v.1 pre-installed (if I remember correctly - Fedora 20, OpenSuSe 12.3, may be others).

Recently I have brought external USB 3.0 HDD (Western Digital My Passport Ultra 2 TB), it has WD Utilities for Windows.
This WD Utilities has special option (in windows tray) for doing Safely remove of the HDD.
How it works? It spins HDD down, switch off the LED and suggests to detach USB cable after that.
So WD, the 1st HDD manufacturer spins-down their HDD before unplugging (it seems that Ejecting unmounted drive it is not enough for them).
Safely remove for this HDD is working as expected on Ubuntu 12.04.3 too (in both Nautilus and palimpsest).

By "1. Connect USB-HDD to your PC running Fedora 20" I mean of course
"1. Connect USB-HDD to your PC running OpenSuSe 13.1", I'm sorry.
The problem is distro-wide (see See Also section).

Changed in gnome-disk-utility (openSUSE):
importance: Unknown → Medium
status: Unknown → Confirmed

The reason that

 $ udisks --detach /dev/sdX

spins down the disk properly but clicking the "Power off" menu item in the GNOME Disks application doesn't has to do with the fact that the udisks program is from udisks version 1 and was rewritten in udisks version 2.

udisks v1: http://cgit.freedesktop.org/udisks/tree/src/helpers/job-drive-detach.c?id=1.0.4

udisks v2: http://cgit.freedesktop.org/udisks/tree/src/udiskslinuxdrive.c?id=2.1.2#n1195

As you can see, both v1 and v2 does this by writing a '1' to the 'remove' sysfs attribute on the parent USB device, as per

 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=253e05724f9230910344357b1142ad8642ff9f5a

and this makes most USB-attached disk drives actually power down - at least all the different devices that I've tested with.

However, what's missing in v2 (and present in v1) is the following steps

 1. sending the SCSI SYNCHRONIZE CACHE command
 2. sending START/STOP UNIT command
 3. unbinding the USB Mass Storage kernel driver

Notably, there's actually a TODO item in v2 for doing this:

 /* TODO: Send the eject? Send SCSI START STOP UNIT? */

Now, I don't think that 3. is necessary as it happens as part of writing to the 'remove' sysfs file. That leaves 1. and 2.

Here's what I'd like to you try. Does

 sg_start --stop /dev/sdX

do what you want? If so, we should add 1. and 2. to v2.

Dear David!
First of all I would like to thank you for answer and recommendation!

I tested my USB-harddrives with sg_start utility. Thank you for hint, I did not know about SCSI utilities before.

I made such tests under Ubuntu 12.04.4, Fedora 20 and OpenSuSe 13.1 with all installed updates.
* Ubuntu 12.04.4 does not have udisks2, it has udisks 1.0.4-5ubuntu2.1, sg3-utils 1.33-1.
* Fedora 20 has udisks-1.0.4-12.fc20.i686, udisks2-2.1.2-1.fc20.i686, sg3_utils-1.37-2.fc20.i686.
* OpenSuSe 13.1 has udisks-1.0.4-13.1.3.i586, udisks2-2.1.1-2.1.3.i586, sg3_utils-1.36-3.1.2.i586.

For more adequate results I disabled auto-mount feature in GNOME with dconf-editor (as recommended here - https://help.ubuntu.com/community/Mount/USB#Configuring_Automounting).

My test results are the following:
1. For my USB-HDD (Seagate ST9750420A in USB 2.0 Tsunami e-data 2500 enclosure,
  lsusb - 04fc:0c25 Sunplus Technology Co., Ltd SATALink SPIF225A)
    1.1. command “sg_start --stop /dev/sdX” really spin-downs my drive (sometimes on 2nd or 3rd attempt - I don’t know why), device remains in system and spin-up again only on my demand.
    1.2. command “udisks --detach /dev/sdX” spin-downs my drive (always on 1st attempt), device is completely removed from system after detach.

2. For my USB 3.0 WD My Passport Ultra (WD WD20NMVW,
  lsusb - 1058:0743 Western Digital Technologies, Inc.)
    2.1. command “sg_start --stop /dev/sdX” is ignored by this HDD (it make one click, but does not spin-down). Maybe it is because of proprietary/non-fully-compliant ATA-command set in WD’s controller.
    2.2. command “udisks --detach /dev/sdX” spin-downs my drive (on 1st attempt always), device is completely removed from system after detach.

So the results are identical for all three distros.
For me it seems, that “udisks --detach” works better and in 100% (on all distros and with proprietary WD HDD-controller).
So if you have time, please, do deeper comparison between udisks v.1, udisks v.2 and sg_start.

I'm ready to do more testing if you send me concrete instruction, but I am not expert and I do not know how to debug/trace/log ATA and udisks.

Debian, udisks2 v 2.1.2-1. When I do safely remove of Seagate Portable from Thunar, udisks2 doesn't switch off a disk power when detaching. But udisks1 switch off a disk power.

Changed in udisks:
status: Confirmed → Incomplete

Thanks for testing. I'll look into making udisks2 sending SYNCHRONIZE CACHE and START/STOP UNIT commands. Stay tuned.

OK, I just made that change

 http://cgit.freedesktop.org/udisks/commit/?id=fcdd8f48b6ac9b1b6da82fdf5f59230fc2ea6feb

and tested it with a couple of different units. Notes

 - One of my devices (bus-powered) does not accept the START STOP UNIT
   command so we just continue if it fails. That is, this patch should
   not break existing behavior.

 - Another device (not bus-powered) used to spin down a couple of seconds
   after removing power to the USB port. With this patch it spins down
   immediately. (Which is actually nicer.)

 - Still works on USB sticks etc.

 - I didn't add SCSI SYNCHRONIZE CACHE as that command failed on all my
   devices. I also don't think it's necessary as the device drivers will
   issue something like this in part of the fsync(2) call that we do
   before this.

Please test if the patch works and report back - thanks!

> command “sg_start --stop /dev/sdX” really spin-downs my drive (sometimes
> on 2nd or 3rd attempt - I don’t know why), device remains in system and
> spin-up again only on my demand.

Btw, this is because the sg_start command opens the device node with O_RDWR which causes an uevent 'change' event to fire when the command completes. This in turn causes udev rules to fire which accesses the disk which causes it to spin up again. In the patch I committed to udisks to do this, we use O_RDONLY to avoid this.

Changed in udisks:
status: Incomplete → Fix Released

Thank you for your commits, David!

I installed all build-dependencies on my Ubuntu 14.04 system with 'apt-get install build-dep', did a 'git clone git://anongit.freedesktop.org/udisks', did './autogen.sh', did 'make', did 'sudo checkinstall make install', verified that I have udisks 2.1.3 installed with 'apt-cache policy', did 'mv /usr/local/share/polkit-1/actions/org.freedesktop.udisks2.policy /usr/share/polkit-1/actions/' and rebooted my machine.

Please note: automount is disabled.
What I get after reboot?

1. for USB-HDDs (both drives have EXT4 and NTFS partitions)
1.1. Seagate - 'Safely remove drive' option in Nautilus spinned-down it, gnome-disks spinned-down it after click on 'Power off the drive'. The 'udisksctl power-off -b /dev/sdX' works too.
If I enable automount, the 'Safely remove drive'/'Power off the drive' spins-down my drive. It's very good!

1.2. WD - 'Safely remove drive' option in Nautilus spinned-down it, gnome-disks 'Power off the drive' and 'udisksctl power-off -b /dev/sdX' works too.
But there is a little difference - if I enable automount the 'Safely remove drive'/'Power off the drive' does not spin-down the disk (disk plates rotating, but device is removed from system), I reopen the bug because of this.

2. for USB-flashes
There is no 'Safely remove drive' option in Nautilus for my USB-flashes. After 'Eject' the parent device remains in system and may be powered-off by gnome-disks. For me it's a good compromise between udisks1 and udisks2 behavior.

I'm ready to test and collect logs of my WD USB-HDD. I can't understand why Seagate drive unmounts all partitions before power-off, but WD does not.
What logs can help you to understand the problem?

Hey, thanks for testing the patches.

(In reply to comment #10)
> 1.2. WD - 'Safely remove drive' option in Nautilus spinned-down it,
> gnome-disks 'Power off the drive' and 'udisksctl power-off -b /dev/sdX'
> works too.
> But there is a little difference - if I enable automount

I have an idea of what's wrong here but before I speculate on that, what exactly does "enable automount" mean? Are you referring to having the 'auto' option in the /etc/fstab file?

> the 'Safely remove
> drive'/'Power off the drive' does not spin-down the disk (disk plates
> rotating, but device is removed from system), I reopen the bug because of
> this.
>
> 2. for USB-flashes
> There is no 'Safely remove drive' option in Nautilus for my USB-flashes.
> After 'Eject' the parent device remains in system and may be powered-off by
> gnome-disks. For me it's a good compromise between udisks1 and udisks2
> behavior.
>
>
> I'm ready to test and collect logs of my WD USB-HDD. I can't understand why
> Seagate drive unmounts all partitions before power-off, but WD does not.
> What logs can help you to understand the problem?

When the system is running with the WD USB-HDD, please include the output of 'gvfs-mount -li' from a non-root shell in a terminal in the desktop session.

Download full text (5.4 KiB)

Thank you for reply, David!

>I have an idea of what's wrong here but before I speculate on that, what exactly does "enable automount" mean? Are you referring to having the 'auto' option in the /etc/fstab file?

By "enable automount" I mean these dconf-editor parameters: org.gnome.desktop.media-handling.automount and org.gnome.desktop.media-handling.automount-open (see comment #5). So if I set both parameters to true (in dconf-editor) I get all two partitions of my drive mounted in Nautilus on device connection.

>When the system is running with the WD USB-HDD, please include the output of 'gvfs-mount -li' from a non-root shell in a terminal in the desktop session.

The output of 'gvfs-mount -li' for my WD USB-HDD is as follows:
 Drive(3): WD My Passport 0743
   Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
   ids:
    unix-device: '/dev/sdc'
   themed icons: [drive-harddisk-usb] [drive-harddisk] [drive]
   symbolic themed icons: [drive-harddisk-usb-symbolic] [drive-harddisk-symbolic] [drive-symbolic] [drive-harddisk-usb] [drive-harddisk] [drive]
   is_media_removable=0
   has_media=1
   is_media_check_automatic=1
   can_poll_for_media=0
   can_eject=0
   can_start=0
   can_stop=1
   start_stop_type=shutdown
   sort_key=01hotplug/1391451089446989
   Volume(0): WD_2TB_NTFS
     Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
     ids:
      class: 'device'
      unix-device: '/dev/sdc2'
      uuid: '32BA1ADB5E526052'
      label: 'WD_2TB_NTFS'
     themed icons: [drive-harddisk-usb] [drive-harddisk] [drive]
     symbolic themed icons: [drive-harddisk-usb-symbolic] [drive-harddisk-symbolic] [drive-symbolic] [drive-harddisk-usb] [drive-harddisk] [drive]
     can_mount=1
     can_eject=0
     should_automount=1
     sort_key=gvfs.time_detected_usec.1391451089661368
   Volume(1): WD_2TB_EXT4
     Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
     ids:
      class: 'device'
      unix-device: '/dev/sdc1'
      uuid: '6d296a81-e054-4e09-a092-cee6a0041e0c'
      label: 'WD_2TB_EXT4'
     themed icons: [drive-harddisk-usb] [drive-harddisk] [drive]
     symbolic themed icons: [drive-harddisk-usb-symbolic] [drive-harddisk-symbolic] [drive-symbolic] [drive-harddisk-usb] [drive-harddisk] [drive]
     can_mount=1
     can_eject=0
     should_automount=1
     sort_key=gvfs.time_detected_usec.1391451089662205
     Mount(0): WD_2TB_EXT4 -> file:///run/media/flash/WD_2TB_EXT4
       Type: GProxyMount (GProxyVolumeMonitorUDisks2)
       default_location=file:///run/media/flash/WD_2TB_EXT4
       themed icons: [drive-harddisk-usb] [drive-harddisk] [drive]
       symbolic themed icons: [drive-harddisk-usb-symbolic] [drive-harddisk-symbolic] [drive-symbolic] [drive-harddisk-usb] [drive-harddisk] [drive]
       can_unmount=1
       can_eject=0
       is_shadowed=0
       sort_key=gvfs.time_detected_usec.1391451089941622

For my Seagate HDD I have:

 Drive(3): ST950042 0AS
   Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
   ids:
    unix-device: '/dev/sdc'
   themed icons: [drive-harddisk-usb] [drive-harddisk] [drive]
   symbolic themed icons: [drive-harddisk-usb-symbolic] [drive-harddisk-symbolic] [drive-symbolic] [d...

Read more...

(Hmm, the drives have

   can_stop=1
   start_stop_type=shutdown

so everything should be good. My guess is that it's the NTFS partition that is the culprit. Specifically, unmounting it via udisks somehow fails.)

If you manually unmount the partitions, does powering down the drive work? Specifically, try this

 1. Unmount all partitions using Disks
    - if that fails, try 'umount /dev/sdXN' from a terminal. Does that work?
 2. Press the "Power off" button in Disks when everything has been unmounted.

Does that work?

Also, please include all messages from udisks from syslog (e.g. /var/log/messages or similar) when pressing the "Power off" button in Disks. It should contain some useful info.

Today I tested 5 other drives with different paritioning schemes (1 primary + 1 extended partition with some logical partitions in it):
3 of them were successfully Safely removed (in Nautilus) and Powered off (in Disks),
2 of them were successfully Safely removed (in Nautilus) and Powered off (in Disks) only after manual unmount.

>If you manually unmount the partitions, does powering down the drive work?
>Specifically, try this
>
> 1. Unmount all partitions using Disks
> - if that fails, try 'umount /dev/sdXN' from a terminal. Does that work?
did it in Disks with my WD drive

> 2. Press the "Power off" button in Disks when everything has been unmounted.
did it in Disks - my WD drive is spinned down.

>Does that work?
So it works.

Created attachment 93407
Syslog/Message for my WD USB-HDD (from plugging-in to Safely remove) - Ubuntu 14.04 with UDisks 2.1.3

>Also, please include all messages from udisks from syslog (e.g. /var/log/messages or similar) when pressing the "Power off" button in Disks. It should contain some useful info.

I attached full log-file for my WD USB-HDD. It contains device plugging-in, detection by automount feature, un-mounting both partiotion in Disks, Powering off in Disks, device plugging-out as you recommended.

Created attachment 93414
Syslog/Message for my WD USB-HDD (from plugging-in to Safely remove) - Ubuntu 12.04 with UDisks 1.0.4-5ubuntu2.1

If that can help I prepared syslog/messages for my WD-HDD in Ubuntu 12.04 too. Sequence is identical to comment 15.

Let me see if I understand this correctly:

 1. Manually unmount, then power-off via the Disks GUI works as expected.
 2. The "safely remove drive" button in Nautilus does not work as expected.

Is that about right?

It seems that my english is not perfect. I'm sorry.

Let's consider only WD-HDD.

>Let me see if I understand this correctly:
> 1. Manually unmount, then power-off via the Disks GUI works as expected.
Yes.
> 2. The "safely remove drive" button in Nautilus does not work as expected.
No. It works as expected on other drives, but not WD.
>Is that about right?
Yes and no.

Safely remove (in Nautilus) and Power off (in Disks) works as expected only if I manually unmount all WD partitions before Safe removal / Power off.

If I unmount all WD partitions manually and then do Safe removal / Power off HDD spins down.

OK, I'm interested in output of /var/log/messages when it doesn't work with the WD. Or is that what you posted in comment 15?

>OK, I'm interested in output of /var/log/messages when it doesn't work with the WD. Or is that what you posted in comment 15?
I tested it again - the log in comment 15 represent both situations - when drive spinned-down and when it does not. Only timestamps differ, messages order is the same.

With udisks1 this WD-HDD spins-down (by Safely remove in Nautilus or Power off in Disks) even if all partitions mounted, with udisks2 it does not.
There is a little difference between udisks1 and udisks2 "powering off drive" algorithms. What other log-file can I attach to help you to understand the problem?

(In reply to comment #20)
> >OK, I'm interested in output of /var/log/messages when it doesn't work with the WD. Or is that what you posted in comment 15?
> I tested it again - the log in comment 15 represent both situations - when
> drive spinned-down and when it does not. Only timestamps differ, messages
> order is the same.
>
>
> With udisks1 this WD-HDD spins-down (by Safely remove in Nautilus or Power
> off in Disks) even if all partitions mounted, with udisks2 it does not.
> There is a little difference between udisks1 and udisks2 "powering off
> drive" algorithms. What other log-file can I attach to help you to
> understand the problem?

Your testing with udisks1 is on an older version of Ubuntu (12.04 vs. 14.04) isn't it? If so, any chance you can install the udisks1 package on the same OS as you tested with udisks2? The packages are parallel-installable (and called 'udisks' and 'udisks2') so it should be as simple as 'apt-get install udisks' and then run "udisks --detach /dev/sdX".

I'm asking for this because I think this is due to a kernel and/or ntfs-3g problem.

Another thing to try would be to see if it happens if the filesystem type is *not* ntfs, e.g. try with ext4. (I realize this may not be possible as you may not want to reformat the disk.)

To recap, the only difference now from udisks1 is that udisks2 does not send SYNCHRONIZE CACHE before START STOP UNIT (it didn't work on any of my devices when I make the recent udisks2 changes). If it turns out that udisks1 works as expected on 14.04, I will try to add this change to see if it makes the difference...

Created attachment 93492
log-files for my WD-HDD (Ubuntu 14.04 with udisks1 and udisks2)

Thank you for reply, David.

>Your testing with udisks1 is on an older version of Ubuntu (12.04 vs. 14.04) isn't it? If so, any chance you can install the udisks1 package on the same OS as you tested with udisks2? The packages are parallel-installable (and called 'udisks' and 'udisks2') so it should be as simple as 'apt-get install udisks' and then run "udisks --detach /dev/sdX".
I have already installed udisks1 (1.0.4-8ubuntu1) on Ubuntu 14.04 and it works as expected on all my drives if I unmount all partitions manually (from console, Nautilus or Disks - it does not matter).

>I'm asking for this because I think this is due to a kernel and/or ntfs-3g problem.
For me it seems that we have timing/race issue in udisks2.

>Another thing to try would be to see if it happens if the filesystem type is *not* ntfs, e.g. try with ext4. (I realize this may not be possible as you may not want to reformat the disk.)
I have 500Gb of data on my NTFS partition, so I do not want to reformat my HDD. I'm sorry for this.

>To recap, the only difference now from udisks1 is that udisks2 does not send SYNCHRONIZE CACHE before START STOP UNIT (it didn't work on any of my devices when I make the recent udisks2 changes). If it turns out that udisks1 works as expected on 14.04, I will try to add this change to see if it makes the difference...
If there are no other differences - please add SYNCHRONIZE CACHE, I'm ready to do a test and report back.

I prepared an archive of log-files for my WD-HDD on Ubuntu 14.04 with udisks1 and udisks2 installed.
The log-files are: "tailf /var/log/syslog", "gvfs-mount -o", "udisksctl monitor", "udisks --monitor-detail".
The test-cases are:
1. udisks2 Safely remove from Disks (mounted) = FAIL - not spinned down
    connect, auto-mount by Nautilus, clicked Power off in Disks, disconnect
2. udisks2 Safely remove from Disks (unmounted) = SUCCESS - spinned down
    connect auto-mount by Nautilus, unmount in Nautilus, clicked Safely remove drive in Nautilus, disconnect
3. udisks2 Safely remove from Nautilus (mounted) FAIL - not spinned down
    connect, auto-mount by Nautilus, clicked Safely remove drive in Nautilus, disconnect
4. udisks2 Safely remove from Nautilus (unmounted) = SUCCESS - spinned down
    connect, auto-mount by Nautilus, unmount in Nautilus, clicked Safely remove drive in Nautilus, disconnect
5. udisks --detach Safely remove (unmounted) = SUCCESS - spinned down
    connect, auto-mount by Nautilus, unmount in Nautilus, sent "udisks --detach /dev/sdX" in console, disconnect

On FAIL-cases there are interesting lines in "udisks --monitor-detail"
    (udisks:2365): udisks-WARNING **: Couldn't call GetAll() to get properties for /org/freedesktop/UDisks/devices/sdc2: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist
may be it cause problems. I do not know.

I'm ready to test your new commits.

(In reply to comment #22)
> I have 500Gb of data on my NTFS partition, so I do not want to reformat my
> HDD. I'm sorry for this.

Fair enough. I'll try to see if I can repro on my hardware.

> If there are no other differences - please add SYNCHRONIZE CACHE, I'm ready
> to do a test and report back.

Will do - thanks for testing!

> I prepared an archive of log-files for my WD-HDD on Ubuntu 14.04 with
> udisks1 and udisks2 installed.

Thanks for doing that - it's very helpful!

> On FAIL-cases there are interesting lines in "udisks --monitor-detail"
> (udisks:2365): udisks-WARNING **: Couldn't call GetAll() to get
> properties for /org/freedesktop/UDisks/devices/sdc2: Method "GetAll" with
> signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist
> may be it cause problems. I do not know.

This is likely not a problem.

Changed in udisks:
status: Fix Released → Confirmed

When I try execute (udisks2 installed):

$ udisksctl power-off -b /dev/sde

It says: "Unknown command `power-off'"

What do I do not so?

Hello, Programmist11180!
From comment #8 to #23 we talk about unrelease udisks2 version from git-repository.

If you are on Ubuntu (or Mint, or other Debian/Ubuntu based distro) you can follow my instruction (in comment #10) to compile udisks2 from latest sources and test "udisksctl power-off -b /dev/sde" again.

I have compiled deb-package for 14.04 i686 - I can post it here if you have any problems with compilation.

Hello nrbrtx.
I have compiled and installed udisks 2.1.3. And I have a problem. udisksctl not work.

$ udisksctl power-off -b /dev/sde

(process:3807): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:3807): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:3807): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:3807): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:3807): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:3807): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:3807): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:3807): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:3807): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:3807): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:3807): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Error connecting to the udisks daemon: Ошибка вызова StartServiceByName для org.freedesktop.UDisks2: Время ожидания истекло

/var/log/syslog

Feb 8 18:54:37 debian-terminal dbus[2839]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper)
Feb 8 18:54:37 debian-terminal udisksd[3540]: udisks daemon version 2.1.3 starting
Feb 8 18:55:02 debian-terminal dbus[2839]: [system] Failed to activate service 'org.freedesktop.UDisks2': timed out
Feb 8 18:55:07 debian-terminal dbus[2839]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper)
Feb 8 18:55:07 debian-terminal udisksd[3810]: udisks daemon version 2.1.3 starting
Feb 8 18:55:32 debian-terminal dbus[2839]: [system] Failed to activate service 'org.freedesktop.UDisks2': timed out

$ ps aux | grep udisks
nikts 3531 0.0 0.0 205256 3312 ? Sl 18:54 0:00 /usr/lib/gvfs/gvfs-udisks2-volume-m
root 3540 0.0 0.1 366324 4912 ? Sl 18:54 0:01 /usr/local/lib/udisks2/udisksd --no
root 3810 0.0 0.1 366324 4916 ? Sl 18:55 0:01 /usr/local/lib/udisks2/udisksd --no

Hello, Programmist11180!

Did you completely followed my instruction in comment #10? Have you rebooted PC after udisks 2.1.3 installation?
Do you have Ubuntu 14.04 as me?

Does power-off work from gnome-disks or Nautilus?

nrbrtx, I have Debian Wheezy (with some Sid), and Thunar filemanager.
The paths in built udisks and udisks from repository differs.
This solve the problem
sudo cp /usr/local/etc/dbus-1/system.d/org.freedesktop.UDisks2.conf /etc/dbus-1/system.d/

But there is an another problem:
$ udisksctl power-off -b /dev/sde
Error looking up object for device /dev/sde

The 'eject' option not available in Thunar with built udisks. Therefore I can't check power-off.

Programmist11180, you can always detect which devices are connected with
"fdisk -l" (called by root) or watch syslog on device connection. It seems that /dev/sde device does not exist. Also you can check which storage devices are connected in gnome-disks (previously palimsest).

Usually /dev/sda is your hard disk, the removable devices start from /dev/sdb.

sudo cp /usr/local/lib/libudisks2.so.0.0.0 /usr/lib/x86_64-linux-gnu/libudisks2.so.0.0.0

And after reboot 'eject' became available in Thunar.

This is my small test:
1. Seagate Portable. Filesystem - one big NTFS volume. Eject from Thunar - no power-off. Disable volume and then eject from Thunar - disk power-offs. Umount volume and udisksctl power-off -b /dev/sde also spin-down disk.

2. U3 flash. Filesystem - one big FAT32. Eject from Thunar - flash power-offs.

3. WD Passport. Filesystem - one big NTFS. No power-off in all cases. Also no power-off in old udisks. I think that this disk may not support this feature.

Created attachment 95371
strace nautilus with udisks2, WD-HDD safely remove (ok - unmounted, fail - mounted)

Dear, David!
I look udisks2 git-repo, it seems that there are no changes since last comments.

I prepared two strace logs for nautilus with my WD-HDD connected:
* nautilus_ok.txt represent case no 4 of my comment #22
* nautilus_fail.txt represent case no 3 of my comment #22

I hope that this log-files will help determine the root of the safely-remove problems. Also I still hope that we can get udisks1 functionality in new udisks2.

Norbert (nrbrtx) wrote :

It seems that problem is fixed with the newest version udisks2 2.1.3-1 in Trusty.
From NEWS file:
      Send SCSI START STOP UNIT when powering down a drive (see this commit - http://cgit.freedesktop.org/udisks/commit/?id=fcdd8f48b6ac9b1b6da82fdf5f59230fc2ea6feb)
      udisksctl: add power-off verb to power off drives (see this commit - http://cgit.freedesktop.org/udisks/commit/?id=a54c2fa14c522487a78828d4a9dfd89f916a3576)

It spins down my USB-HDDs and flashes. It's great.

Hi, sorry for the lack of updates. Nothing special, just been busy with work, I'm still planning on adding the SYNCHRONIZE CACHE command. Hopefully I'll get to look at it soon. Thanks.

For me the command “udisks --detach /dev/sdX” detaches the device for a second and the device is then redetected and mounted again always

How ever the command “sg_start --stop /dev/sdX” does the same in the first try and actually detached and turned off my hdd
in the first try but after that I've been getting the same results as above

I performed these tests with my Seagate Backup Plus Drive on Ubuntu 13.10

Viola, it actually worked this time
My steps on the same configuration were:

1."sg_start --start /dev/sdX"
2."sg_start --stop /dev/sdX"

And my drive i.e Seagate Backup Plus Drive was powered down for about 1 minute or so then I don't know why or how it restarted

Ubuntu 13.10

Hi, finally got around to making udisks also send the SYNCHRONIZE CACHE command. Please check if it works. The patch is on master and here:

 http://cgit.freedesktop.org/udisks/commit/?id=429892f2ec39d66732bee0f78d093eb6d2c5433f

Thanks!

I don't see a difference after applying this patch.

Norbert (nrbrtx) on 2014-03-29
Changed in gnome-disk-utility (Ubuntu):
status: New → Fix Released

Thank you for your commit, David!

But as Programmist11180 I don't see any differences after applying this patch. My WD HDD acts as before.

How I can get full debug log about low-level actions which are performed during Safely remove from Nautilus or Disks?

HI,

tested on OpenSuse 13.10 and the patch doesn't work.
The HDD led remains switched ON (Toshiba Canvio Usb 3.0, 2.0TB)
Bye :-)

FYI, when you unbind the scsi disk driver by writing the 1 to the delete knob in sysfs, it takes care of issuing the synchronize cache and start/stop unit commands. You can see this in dmesg. You mentioned the usb mass storage driver, which I would not have thought of. I'd bet that is the issue. My guess is that most drives appear to work because they shut off their LED when given the STOP UNIT command when the scsi disk driver unbinds, but if the usb mass storage driver is still bound, some drives decide to keep the LED on.

Abhirav Kumar (akabhirav) wrote :

I now have Ubuntu 14.04 and it does not have udisks or sg_start but the problem is still there for USB 3.0

Created attachment 627090
Output of systemd-journalctl

Powering usb drive ("Safely Remove Drive") isn't working, the HDD gets reattached again.

Does "Eject" also behave same? It should really detach without re-probe.
If "Eject" works, it's the answer -- why there are two distinct entries.

(Maybe there aren't on GNOME... It exists on XFCE4, at least.)

The "Eject" button works (Gnome) but it only unmount the partition and does not actually deactivate the disk.

If the disk is connected to an usb 2.0 port "Safely Remove Drive" works, turning off the disk.

Oliver, this seems like a regression with xhci (with respect to ehci). Is there a known fix / workaround?

I also remember that one of my USB disks behaves like this.

(In reply to Takashi Iwai from comment #4)
> Oliver, this seems like a regression with xhci (with respect to ehci). Is
> there a known fix / workaround?
>
> I also remember that one of my USB disks behaves like this.

One workaround is to attach the HDD to an USB 2.0 port.

What does the eject command on a terminal do?

Download full text (7.0 KiB)

(In reply to Oliver Neukum from comment #6)
> What does the eject command on a terminal do?

Hi Oliver,

The eject command just unmount the partitions.

medina:~ # eject /dev/sdb

systemd-journalctl log:

Jun 30 13:12:50 medina.novell.com udisksd[2047]: Cleaning up mount point /run/media/luis/LUIS (device 8:17 is not mounted)
Jun 30 13:12:50 medina.novell.com ntfs-3g[4472]: Unmounting /dev/sdb1 (LUIS)
Jun 30 13:12:50 medina.novell.com udisksd[2047]: Cleaning up mount point /run/media/luis/ALBERTO (device 8:18 is not mounted)

However, if detach the hdd it gets remounted in my USB 3.0 port.

medina:~ # udisksctl power-off -b /dev/sdb

systemd-journalctl log:

Jun 30 13:13:01 medina.novell.com udisksd[2047]: Powering off /dev/sdb - successfully sent SCSI command START STOP UNIT
Jun 30 13:13:01 medina.novell.com kernel: sd 7:0:0:0: [sdb] Synchronizing SCSI cache
Jun 30 13:13:01 medina.novell.com udisksd[2047]: Powered off /dev/sdb - successfully wrote to sysfs path /sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/remove
Jun 30 13:13:01 medina.novell.com kernel: sd 7:0:0:0: [sdb]
Jun 30 13:13:01 medina.novell.com kernel: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: USB disconnect, device number 5
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: new SuperSpeed USB device number 6 using xhci_hcd
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: New USB device found, idVendor=0bc2, idProduct=2321
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: Product: Expansion
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: Manufacturer: Seagate
Jun 30 13:13:01 medina.novell.com kernel: usb 3-1: SerialNumber: NA4BQHLX
Jun 30 13:13:01 medina.novell.com kernel: scsi8 : uas
Jun 30 13:13:01 medina.novell.com kernel: scsi 8:0:0:0: Direct-Access Seagate Expansion 0502 PQ: 0 ANSI: 6
Jun 30 13:13:01 medina.novell.com kernel: sd 8:0:0:0: Attached scsi generic sg1 type 0
Jun 30 13:13:01 medina.novell.com kernel: sd 8:0:0:0: [sdb] 3907029167 512-byte logical blocks: (2.00 TB/1.81 TiB)
Jun 30 13:13:01 medina.novell.com kernel: sd 8:0:0:0: [sdb] 4096-byte physical blocks
Jun 30 13:13:01 medina.novell.com kernel: sd 8:0:0:0: [sdb] Write Protect is off
Jun 30 13:13:01 medina.novell.com kernel: sd 8:0:0:0: [sdb] Mode Sense: 4f 00 00 00
Jun 30 13:13:01 medina.novell.com kernel: sd 8:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 30 13:13:01 medina.novell.com mtp-probe[4516]: checking bus 3, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
Jun 30 13:13:01 medina.novell.com mtp-probe[4516]: bus: 3, device: 6 was not an MTP device
Jun 30 13:13:03 medina.novell.com kernel: sdb: sdb1 sdb2 sdb3
Jun 30 13:13:03 medina.novell.com kernel: sd 8:0:0:0: [sdb] Attached SCSI disk
Jun 30 13:13:03 medina.novell.com kernel: hfsplus: write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.
Jun 30 13:13:03 medina.novell.com udisksd[2047]: Mounted /dev/sdb2 at /run/media/luis/ALBERTO on behalf of uid 1000
Jun 30 13...

Read more...

Duplicate of 922634

*** This bug has been marked as a duplicate of bug 922634 ***

*** Bug 859374 has been marked as a duplicate of this bug. ***

This is currently handled upstream. The patches are not yet ready. Something is wrong with the port state machine.

Changed in oem-workaround-xhci-quirk-dkms (openSUSE):
importance: Unknown → Medium
Changed in gnome-disk-utility (openSUSE):
status: Confirmed → Invalid

It's perhaps ready now :).

(In reply to Jiri Slaby from comment #12)
> It's perhaps ready now :).

Indeed. Please test KOTD.

Download full text (5.0 KiB)

Same results with 4.2.rc6-1.1.g4a2cf4a

medina:~ # eject /dev/sdb

systemd-journalctl log:

Aug 13 10:45:10 medina.novell.com udisksd[1953]: Cleaning up mount point /run/media/luis/LUIS (device 8:17 is not mounted)
Aug 13 10:45:10 medina.novell.com ntfs-3g[3278]: Unmounting /dev/sdb1 (LUIS)
Aug 13 10:45:10 medina.novell.com udisksd[1953]: Cleaning up mount point /run/media/luis/ALBERTO (device 8:18 is not mounted)

medina:~ # udisksctl power-off -b /dev/sdb

systemd-journalctl log:

Aug 13 10:45:21 medina.novell.com bluetoothd[997]: Endpoint unregistered: sender=:1.28 path=/MediaEndpoint/A2DPSource
Aug 13 10:45:21 medina.novell.com bluetoothd[997]: Endpoint unregistered: sender=:1.28 path=/MediaEndpoint/A2DPSink
Aug 13 10:45:21 medina.novell.com systemd[1321]: pam_unix(systemd-user:session): session closed for user gdm
Aug 13 10:45:22 medina.novell.com udisksd[1953]: Powering off /dev/sdb - successfully sent SCSI command START STOP UNIT
Aug 13 10:45:22 medina.novell.com kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
Aug 13 10:45:23 medina.novell.com kernel: sd 6:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Aug 13 10:45:23 medina.novell.com udisksd[1953]: Powered off /dev/sdb - successfully wrote to sysfs path /sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/remove
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: USB disconnect, device number 4
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: new SuperSpeed USB device number 5 using xhci_hcd
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: New USB device found, idVendor=0bc2, idProduct=2321
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: Product: Expansion
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: Manufacturer: Seagate
Aug 13 10:45:23 medina.novell.com kernel: usb 3-1: SerialNumber: NA4BQHLX
Aug 13 10:45:23 medina.novell.com kernel: scsi host7: uas
Aug 13 10:45:23 medina.novell.com kernel: scsi 7:0:0:0: Direct-Access Seagate Expansion 0502 PQ: 0 ANSI: 6
Aug 13 10:45:23 medina.novell.com kernel: sd 7:0:0:0: Attached scsi generic sg1 type 0
Aug 13 10:45:23 medina.novell.com kernel: sd 7:0:0:0: [sdb] 3907029167 512-byte logical blocks: (2.00 TB/1.81 TiB)
Aug 13 10:45:23 medina.novell.com kernel: sd 7:0:0:0: [sdb] 4096-byte physical blocks
Aug 13 10:45:23 medina.novell.com kernel: sd 7:0:0:0: [sdb] Write Protect is off
Aug 13 10:45:23 medina.novell.com kernel: sd 7:0:0:0: [sdb] Mode Sense: 4f 00 00 00
Aug 13 10:45:23 medina.novell.com kernel: sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 13 10:45:23 medina.novell.com mtp-probe[3392]: checking bus 3, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
Aug 13 10:45:23 medina.novell.com mtp-probe[3392]: bus: 3, device: 5 was not an MTP device
Aug 13 10:45:25 medina.novell.com kernel: sdb: sdb1 sdb2 sdb3
Aug 13 10:45:25 medina.novell.com kernel: sd 7:0:0:0: [sdb] Attached SCSI disk
Aug 13 10:45:25 medina.novell.com kernel: iwlwifi 0000:03:00.0: request for firmware file 'iwlwifi-7265D-11.ucode' failed.
Aug 13 10:45:25...

Read more...

Ok, then this is not the port status issue.
Please activate dynamic debugging of xhci
echo "modules xhci_hcd +p" > /sys/kernel/debug/dynamic_debug/control
and retest.

Created attachment 646177
systemd-journalctl output

Oliver,

Started "systemd-journalctl -f" and then the following commands and/or actions where ejecuted:

{1.- Activate dynamic debugging of xhci}

  medina:~ # date; echo "modules xhci_hcd +p" > /sys/kernel/debug/dynamic_debug/control
  Thu Sep 3 14:35:29 CDT 2015
  -bash: echo: write error: Invalid argument
  medina:~ # date; echo "module xhci_hcd +p" > /sys/kernel/debug/dynamic_debug/control
  Thu Sep 3 14:35:37 CDT 2015

{2.- Inserted HDD}

{3.- Eject HDD}

  medina:~ # date; eject /dev/sdb
  Thu Sep 3 14:36:17 CDT 2015

{4.- PowerOff HDD (with automatic remouting)}

  medina:~ # date; udisksctl power-off -b /dev/sdb
  Thu Sep 3 14:36:29 CDT 2015

{5.- Disable dynamic debugging of xhci}

  medina:~ # date; echo "module xhci_hcd -p" > /sys/kernel/debug/dynamic_debug/control
  Thu Sep 3 14:36:56 CDT 2015

Could you please redo and split the logs when you do something?

Created attachment 646529
systemd-journalctl divided by action

Sure,

I attached a tar.gz with three files:

01-insertHDD.log, inserting the HDD...

02-ejectHDD.log, execution of the command "eject /dev/sdb"

03-powerOffHDD.log, powering off and automatic remounting, command "udisksctl power-off -b /dev/sdb"

medina:~ # date; eject /dev/sdb
Tue Sep 8 09:44:07 CDT 2015
medina:~ # date; udisksctl power-off -b /dev/sdb
Tue Sep 8 09:44:33 CDT 2015

Inconclusive. Something crashes the drive. Possibly LPM is too much for your device. Please try this kernel disabling it:

https://build.opensuse.org/project/monitor?project=home%3Aoneukum%3Abnc922634_disableLPM

Same issue here, reported there:
https://bugzilla.redhat.com/show_bug.cgi?id=1278944

It is not consistent between disks, even when there are from the same vendor or the same model.
Of course, the controller may be totally different.

Note that it all cases, they spin down correctly under Mac OS or Windows.

Upstream has provided a fix:

commit 91ff70db0c49d22fac1b249bd16949978406c271
Author: Mathias Nyman <email address hidden>
Date: Mon Aug 29 14:45:17 2016 +0300

    usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices

    USB-3 does not have any link state that will avoid negotiating a connection
    with a plugged-in cable but will signal the host when the cable is
    unplugged.

    For USB-3 we used to first set the link to Disabled, then to RxDdetect to
    be able to detect cable connects or disconnects. But in RxDetect the connected
    device is detected again and eventually enabled.

    Instead set the link into U3 and disable remote wakeups for the device.
    This is what Windows does, and what Alan Stern suggested.

fix added to kernel trees

Changed in oem-workaround-xhci-quirk-dkms (openSUSE):
status: Unknown → Fix Released

openSUSE-SU-2016:2583-1: An update that solves four vulnerabilities and has 21 fixes is now available.

Category: security (important)
Bug References: 1000287,1000304,1000907,1001462,1001486,1004418,1004462,1005101,799133,881008,909994,911687,922634,963655,972460,978094,979681,987703,991247,991665,993890,993891,996664,999600,999932
CVE References: CVE-2016-5195,CVE-2016-7039,CVE-2016-7425,CVE-2016-8658
Sources used:
openSUSE Leap 42.1 (src): drbd-8.4.6-10.1, hdjmod-1.28-26.1, ipset-6.25.1-7.1, kernel-debug-4.1.34-33.1, kernel-default-4.1.34-33.1, kernel-docs-4.1.34-33.3, kernel-ec2-4.1.34-33.1, kernel-obs-build-4.1.34-33.1, kernel-obs-qa-4.1.34-33.1, kernel-obs-qa-xen-4.1.34-33.1, kernel-pae-4.1.34-33.1, kernel-pv-4.1.34-33.1, kernel-source-4.1.34-33.1, kernel-syms-4.1.34-33.1, kernel-vanilla-4.1.34-33.1, kernel-xen-4.1.34-33.1, lttng-modules-2.7.0-4.1, pcfclock-0.44-268.1, vhba-kmp-20140928-7.1

This is an autogenerated message for OBS integration:
This bug (922634) was mentioned in
https://build.opensuse.org/request/show/437000 13.2 / kernel-source

openSUSE-SU-2016:2625-1: An update that solves 12 vulnerabilities and has 19 fixes is now available.

Category: security (important)
Bug References: 1000287,1001486,1003077,1003925,1003931,1004045,1004418,1004462,881008,909994,911687,922634,951155,960689,978094,980371,986570,989152,991247,991608,991665,993890,993891,994296,994520,994748,994752,994759,996664,999600,999932
CVE References: CVE-2015-7513,CVE-2015-8956,CVE-2016-0823,CVE-2016-1237,CVE-2016-5195,CVE-2016-5696,CVE-2016-6327,CVE-2016-6480,CVE-2016-6828,CVE-2016-7117,CVE-2016-7425,CVE-2016-8658
Sources used:
openSUSE 13.2 (src): bbswitch-0.8-3.22.1, cloop-2.639-14.22.1, crash-7.0.8-22.1, hdjmod-1.28-18.23.1, ipset-6.23-22.1, kernel-debug-3.16.7-45.1, kernel-default-3.16.7-45.1, kernel-desktop-3.16.7-45.1, kernel-docs-3.16.7-45.2, kernel-ec2-3.16.7-45.1, kernel-obs-build-3.16.7-45.1, kernel-obs-qa-3.16.7-45.1, kernel-obs-qa-xen-3.16.7-45.1, kernel-pae-3.16.7-45.1, kernel-source-3.16.7-45.1, kernel-syms-3.16.7-45.1, kernel-vanilla-3.16.7-45.1, kernel-xen-3.16.7-45.1, pcfclock-0.44-260.22.1, vhba-kmp-20140629-2.22.1, virtualbox-5.0.28-54.2, xen-4.4.4_05-51.2, xtables-addons-2.6-24.1

SUSE-SU-2016:2912-1: An update that solves 11 vulnerabilities and has 111 fixes is now available.

Category: security (important)
Bug References: 1000189,1000287,1000304,1000776,1001419,1001486,1002165,1003079,1003153,1003400,1003568,1003866,1003925,1003964,1004252,1004462,1004517,1004520,1005666,1006691,1007615,1007886,744692,772786,789311,857397,860441,865545,866130,868923,874131,876463,898675,904489,909994,911687,915183,921338,921784,922064,922634,924381,924384,930399,931454,934067,937086,937888,940545,941420,946309,955446,956514,959463,961257,962846,966864,967640,970943,971975,971989,974406,974620,975596,975772,976195,977687,978094,979451,979928,982783,983619,984194,984419,984779,984992,985562,986445,987192,987333,987542,987565,987621,987805,988440,988617,988715,989152,989953,990245,991247,991608,991665,992244,992555,992591,992593,992712,993392,993841,993890,993891,994296,994438,994520,994748,995153,995968,996664,997059,997299,997708,997896,998689,998795,998825,999577,999584,999600,999779,999907,999932
CVE References: CVE-2015-8956,CVE-2016-5696,CVE-2016-6130,CVE-2016-6327,CVE-2016-6480,CVE-2016-6828,CVE-2016-7042,CVE-2016-7097,CVE-2016-7425,CVE-2016-8658,CVE-2016-8666
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP1 (src): kernel-default-3.12.67-60.64.18.1
SUSE Linux Enterprise Software Development Kit 12-SP1 (src): kernel-docs-3.12.67-60.64.18.3, kernel-obs-build-3.12.67-60.64.18.1
SUSE Linux Enterprise Server 12-SP1 (src): kernel-default-3.12.67-60.64.18.1, kernel-source-3.12.67-60.64.18.1, kernel-syms-3.12.67-60.64.18.1, kernel-xen-3.12.67-60.64.18.1
SUSE Linux Enterprise Module for Public Cloud 12 (src): kernel-ec2-3.12.67-60.64.18.1
SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12-SP1_Update_9-1-6.3
SUSE Linux Enterprise Desktop 12-SP1 (src): kernel-default-3.12.67-60.64.18.1, kernel-source-3.12.67-60.64.18.1, kernel-syms-3.12.67-60.64.18.1, kernel-xen-3.12.67-60.64.18.1

SUSE-SU-2016:2976-1: An update that solves 13 vulnerabilities and has 87 fixes is now available.

Category: security (important)
Bug References: 1000189,1001419,1002165,1003077,1003344,1003568,1003677,1003866,1003925,1004517,1004520,1005857,1005896,1005903,1006917,1006919,1007944,763198,771065,799133,803320,839104,843236,860441,863873,865783,871728,907611,908458,908684,909077,909350,909484,909618,909994,911687,915183,920016,922634,922947,928138,929141,934760,951392,956514,960689,963655,967716,968010,968014,971975,971989,973203,974620,976867,977687,979514,979595,979681,980371,982218,982783,983535,983619,984102,984194,984992,985206,986337,986362,986365,986445,987565,988440,989152,989261,989764,989779,991608,991665,991923,992566,993127,993890,993891,994296,994436,994618,994759,994926,995968,996329,996664,997708,998399,998689,999584,999600,999907,999932
CVE References: CVE-2013-4312,CVE-2015-7513,CVE-2015-8956,CVE-2016-0823,CVE-2016-3841,CVE-2016-4998,CVE-2016-5696,CVE-2016-6480,CVE-2016-6828,CVE-2016-7042,CVE-2016-7097,CVE-2016-7117,CVE-2016-7425
Sources used:
SUSE Linux Enterprise Software Development Kit 11-SP4 (src): kernel-docs-3.0.101-88.3
SUSE Linux Enterprise Server 11-SP4 (src): kernel-bigmem-3.0.101-88.1, kernel-default-3.0.101-88.1, kernel-ec2-3.0.101-88.1, kernel-pae-3.0.101-88.1, kernel-ppc64-3.0.101-88.1, kernel-source-3.0.101-88.1, kernel-syms-3.0.101-88.1, kernel-trace-3.0.101-88.1, kernel-xen-3.0.101-88.1
SUSE Linux Enterprise Server 11-EXTRA (src): kernel-default-3.0.101-88.1, kernel-pae-3.0.101-88.1, kernel-ppc64-3.0.101-88.1, kernel-trace-3.0.101-88.1, kernel-xen-3.0.101-88.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src): kernel-bigmem-3.0.101-88.1, kernel-default-3.0.101-88.1, kernel-ec2-3.0.101-88.1, kernel-pae-3.0.101-88.1, kernel-ppc64-3.0.101-88.1, kernel-trace-3.0.101-88.1, kernel-xen-3.0.101-88.1

openSUSE-SU-2016:3021-1: An update that solves 12 vulnerabilities and has 118 fixes is now available.

Category: security (important)
Bug References: 1000189,1000287,1000304,1000776,1001419,1001486,1002165,1003079,1003153,1003400,1003568,1003866,1003925,1004252,1004418,1004462,1004517,1004520,1005666,1006691,1007615,1007886,744692,772786,789311,799133,857397,860441,865545,866130,868923,874131,875631,876145,876463,898675,904489,909994,911687,915183,921338,921784,922064,922634,924381,924384,930399,931454,934067,937086,937888,940545,941420,946309,954986,955446,956514,959463,961257,962846,963655,963767,966864,967640,970943,971975,971989,974406,974620,975596,975772,976195,977687,978094,979451,979681,979928,982783,983619,984194,984419,984779,984992,985562,986445,987192,987333,987542,987565,987621,987805,988440,988617,988715,989152,989953,990245,991247,991608,991665,992244,992555,992591,992593,992712,993392,993841,993890,993891,994296,994438,994520,994748,994758,995153,995968,996664,997059,997299,997708,997896,998689,998795,998825,999577,999584,999600,999779,999907,999932
CVE References: CVE-2013-5634,CVE-2015-8956,CVE-2016-2069,CVE-2016-5696,CVE-2016-6130,CVE-2016-6327,CVE-2016-6480,CVE-2016-6828,CVE-2016-7042,CVE-2016-7097,CVE-2016-7425,CVE-2016-8658
Sources used:
openSUSE 13.1 (src): cloop-2.639-11.36.1, crash-7.0.2-2.36.1, hdjmod-1.28-16.36.1, ipset-6.21.1-2.40.1, iscsitarget-1.4.20.3-13.36.1, kernel-debug-3.12.67-58.1, kernel-default-3.12.67-58.1, kernel-desktop-3.12.67-58.1, kernel-docs-3.12.67-58.2, kernel-ec2-3.12.67-58.1, kernel-pae-3.12.67-58.1, kernel-source-3.12.67-58.1, kernel-syms-3.12.67-58.1, kernel-trace-3.12.67-58.1, kernel-vanilla-3.12.67-58.1, kernel-xen-3.12.67-58.1, ndiswrapper-1.58-37.1, openvswitch-1.11.0-0.43.1, pcfclock-0.44-258.37.1, vhba-kmp-20130607-2.36.1, virtualbox-4.2.36-2.68.1, xen-4.3.4_10-69.1, xtables-addons-2.3-2.35.1

SUSE-SU-2016:3304-1: An update that solves 13 vulnerabilities and has 118 fixes is now available.

Category: security (important)
Bug References: 1000189,1000287,1000304,1000776,1001419,1001486,1002165,1003079,1003153,1003400,1003568,1003925,1004252,1004418,1004462,1004517,1004520,1005666,1006691,1007615,1007886,744692,789311,857397,860441,865545,866130,868923,874131,875631,876145,876463,898675,904489,909994,911687,915183,921338,921784,922064,922634,924381,924384,930399,934067,937086,937888,941420,946309,955446,956514,959463,961257,962846,963655,963767,966864,967640,970943,971975,971989,974406,974620,975596,975772,976195,977687,978094,979451,979681,979928,980371,981597,982783,983619,984194,984419,984779,984992,985562,986362,986365,986445,987192,987333,987542,987565,987621,987805,988440,988617,988715,989152,989953,990058,990245,991247,991608,991665,991667,992244,992555,992568,992591,992593,992712,993392,993841,993890,993891,994167,994296,994438,994520,994758,995153,995968,996664,997059,997299,997708,997896,998689,998795,998825,999577,999584,999600,999779,999907,999932
CVE References: CVE-2015-8956,CVE-2016-2069,CVE-2016-4998,CVE-2016-5195,CVE-2016-5696,CVE-2016-6130,CVE-2016-6327,CVE-2016-6480,CVE-2016-6828,CVE-2016-7042,CVE-2016-7097,CVE-2016-7425,CVE-2016-8658
Sources used:
SUSE Linux Enterprise Real Time Extension 12-SP1 (src): kernel-compute-3.12.67-60.27.1, kernel-compute_debug-3.12.67-60.27.1, kernel-rt-3.12.67-60.27.1, kernel-rt_debug-3.12.67-60.27.1, kernel-source-rt-3.12.67-60.27.1, kernel-syms-rt-3.12.67-60.27.1

SUSE-SU-2017:0181-1: An update that solves 13 vulnerabilities and has 127 fixes is now available.

Category: security (important)
Bug References: 1000118,1000189,1000287,1000304,1000433,1000776,1001169,1001171,1001310,1001462,1001486,1001888,1002322,1002770,1002786,1003068,1003566,1003581,1003606,1003813,1003866,1003964,1004048,1004052,1004252,1004365,1004517,1005169,1005327,1005545,1005666,1005745,1005895,1005917,1005921,1005923,1005925,1005929,1006103,1006175,1006267,1006528,1006576,1006804,1006809,1006827,1006915,1006918,1007197,1007615,1007653,1007955,1008557,1008979,1009062,1009969,1010040,1010158,1010444,1010478,1010507,1010665,1010690,1010970,1011176,1011250,1011913,1012060,1012094,1012452,1012767,1012829,1012992,1013001,1013479,1013531,1013700,1014120,1014392,1014701,1014710,1015212,1015359,1015367,1015416,799133,914939,922634,963609,963655,963904,964462,966170,966172,966186,966191,966316,966318,966325,966471,969474,969475,969476,969477,969756,971975,971989,972993,974313,974842,974843,978907,979378,979681,981825,983087,983152,983318,985850,986255,986987,987641,987703,987805,988524,988715,990384,992555,993739,993841,993891,994881,995278,997059,997639,997807,998054,998689,999907,999932
CVE References: CVE-2015-1350,CVE-2015-8964,CVE-2016-7039,CVE-2016-7042,CVE-2016-7425,CVE-2016-7913,CVE-2016-7917,CVE-2016-8645,CVE-2016-8666,CVE-2016-9083,CVE-2016-9084,CVE-2016-9793,CVE-2016-9919
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP2 (src): kernel-default-4.4.38-93.1
SUSE Linux Enterprise Software Development Kit 12-SP2 (src): kernel-docs-4.4.38-93.3, kernel-obs-build-4.4.38-93.1
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): kernel-default-4.4.38-93.1, kernel-source-4.4.38-93.1, kernel-syms-4.4.38-93.1
SUSE Linux Enterprise Server 12-SP2 (src): kernel-default-4.4.38-93.1, kernel-source-4.4.38-93.1, kernel-syms-4.4.38-93.1
SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12-SP2_Update_4-1-2.1
SUSE Linux Enterprise High Availability 12-SP2 (src): kernel-default-4.4.38-93.1
SUSE Linux Enterprise Desktop 12-SP2 (src): kernel-default-4.4.38-93.1, kernel-source-4.4.38-93.1, kernel-syms-4.4.38-93.1

SUSE-SU-2017:1102-1: An update that solves 27 vulnerabilities and has 114 fixes is now available.

Category: security (important)
Bug References: 1003077,1003344,1003568,1003677,1003813,1003866,1003925,1004517,1004520,1005857,1005877,1005896,1005903,1006917,1006919,1007615,1007944,1008557,1008645,1008831,1008833,1008893,1009875,1010150,1010175,1010201,1010467,1010501,1010507,1010711,1010716,1011685,1011820,1012411,1012422,1012832,1012851,1012917,1013018,1013038,1013042,1013070,1013531,1013533,1013542,1013604,1014410,1014454,1014746,1015561,1015752,1015760,1015796,1015803,1015817,1015828,1015844,1015848,1015878,1015932,1016320,1016505,1016520,1016668,1016688,1016824,1016831,1017686,1017710,1019148,1019165,1019348,1019783,1020214,1021258,748806,763198,771065,786036,790588,795297,799133,800999,803320,821612,824171,851603,853052,860441,863873,865783,871728,901809,907611,908458,908684,909077,909350,909484,909491,909618,913387,914939,919382,922634,924708,925065,928138,929141,953233,956514,960689,961589,962846,963655,967716,968010,969340,973203,973691,979681,984194,986337,987333,987576,989152,989680,989764,989896,990245,992566,992991,993739,993832,995968,996541,996557,997401,998689,999101,999907
CVE References: CVE-2004-0230,CVE-2012-6704,CVE-2013-6368,CVE-2015-1350,CVE-2015-8956,CVE-2015-8962,CVE-2015-8964,CVE-2016-10088,CVE-2016-3841,CVE-2016-5696,CVE-2016-7042,CVE-2016-7097,CVE-2016-7117,CVE-2016-7910,CVE-2016-7911,CVE-2016-7916,CVE-2016-8399,CVE-2016-8632,CVE-2016-8633,CVE-2016-8646,CVE-2016-9555,CVE-2016-9576,CVE-2016-9685,CVE-2016-9756,CVE-2016-9793,CVE-2016-9794,CVE-2017-5551
Sources used:
SUSE Linux Enterprise Real Time Extension 11-SP4 (src): kernel-rt-3.0.101.rt130-68.1, kernel-rt_trace-3.0.101.rt130-68.1, kernel-source-rt-3.0.101.rt130-68.1, kernel-syms-rt-3.0.101.rt130-68.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src): kernel-rt-3.0.101.rt130-68.1, kernel-rt_debug-3.0.101.rt130-68.1, kernel-rt_trace-3.0.101.rt130-68.1

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.