Bug#725284: Bug#779787: damaging default apm_on_ac configuration

Am Wed, 9 Mar 2016 17:09:51 +0100 schrieb Raphael Hertzog : > On Wed, 09 Mar 2016, Chris wrote: > > Great, thanks! > > Does it trigger and re-apply the setting on resume events for you? > > I don't think so, this is why #725284 is still open. > OK, thanks, others may test changing the hdparm u

Bug#725284: hdparm + systemd: Configuration not restored after resume

Package: hdparm Version: 9.43-2 Followup-For: Bug #725284 Dear Maintainer, Is there any new about this bug ? BR -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: am

Bug#779412: Bug#725284: proper resume hooks

reassign 779412 src:systemd Am Mon, 27 Apr 2015 15:03:23 +0200 schrieb Ralf Jung : > udev is part of systemd, so I expected this to be about udev. The > problem surfaces not just if systemd is used as init. You are right > though that it is attached to the systemd binary package (and not just >

Bug#779412: Bug#725284: proper resume hooks

Hi, >> I should add that there already is a bug open against udev for this: >> > > That links to a systemd bug, not a udev bug about async supend/resume, > as I had expected from your messages. Did I misunderstood you? udev is part of sy

Bug#725284: proper resume hooks

Am Mon, 27 Apr 2015 14:26:46 +0200 schrieb Ralf Jung : > I should add that there already is a bug open against udev for this: > That links to a systemd bug, not a udev bug about async supend/resume, as I had expected from your messages. D

Bug#725284: proper resume hooks

Am Mon, 27 Apr 2015 14:21:01 +0200 schrieb Ralf Jung : > > "OnClockChange=yes" > > This does not sound to me like it applies to hdparm. We are not caring > about the clock here, we are caring about devices re-appearing after > suspend-resume and hence needing reconfiguration. All system resumes

Bug#725284: proper resume hooks

>> And in >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780956 >> the dev showed that udev already has proper hooks for resume events. >> >> So these may be proper mechanisms for packages to ship with a >> resume hook. And the last one is already tried and proven by >> laptop-mode-tools. >

Bug#725284: proper resume hooks

Hi, > In the face of the race condition with systemd unit files, reported > by Michael Biebl, there seem to exist different alternatives. > > > > Lennart Poettering: > https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=744753#40 > "a service which needs to be restarted on > cases like

Bug#725284: proper resume hooks

In the face of the race condition with systemd unit files, reported by Michael Biebl, there seem to exist different alternatives. Lennart Poettering: https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=744753#40 "a service which needs to be restarted on cases like this sounds wrong. Th

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi, > This doesn't guarantee that the service is run on resume. > Those targets are activated on suspend/hibernate, so there is a race and > you might actually run /usr/lib/pm-utils/power.d/95hdparm-apm *before* > the system is suspended. You'd have to order this service after the > *service* whic

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Am Tue, 21 Apr 2015 14:53:36 +0200 schrieb Michael Biebl : > This doesn't guarantee that the service is run on resume. Many thanks for your help in solving this, Michael! (Unfortunately, I had only tried the imperfect unit file, and I had just luck (or not) so that I did not see it fail.) --

Bug#725284: Bug#779412: block devices loosing state after resume: trigger udev rules to re-apply settings

Am 28.02.2015 um 09:30 schrieb Chris: > A draft for such a central systemd unit file: > > [Unit] > Description=Trigger all block device udev rules on resume, to re-apply all > non-permanent device settings (e.g. smartctl and hdparm rules). > After=suspend.target After=hibernate.target > After=hy

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

On Wed, 25 Dec 2013 17:33:04 +0100 Ralf Jung wrote: > Dear maintainer, > > adding the attached systemd unit fixes restoring the hdparm > configuration when systemd is used. I'd appreciate if you could add this > (or a similar solution) to the package. This proposed patch doesn't work as-is, due

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi, > The specific one you posted above could probably use "oneshot": > > [Service] > Type=oneshot Thanks! I'm not sure if I want anything to wait for hdparm being done with this (which seems to be the only consequence), but in any case it sounds more appropriate to what that unit is doing. Kin

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

> I don't know whether udev just doesn't trigger > after a resume Either a generic systemd unit file is required to trigger an udev change event http://bugs.debian.org/779412, or a hdparm specific one to trigger just the hdparm script. The specific one you posted above could probably use "oneshot

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi again, sorry for the noise. This is just to confirm that there simply is no event for the disks on resume: > $ sudo udevadm monitor -uk > monitor will print the received events for: > UDEV - the event which udev sends out after rule processing > KERNEL - the kernel uevent > > KERNEL[49453.633

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi again, I did some quick debugging, and it seems like the script /lib/udev/hdparm is never even run on suspend-resume. I'm not really familiar with udev, so I don't know whether udev just doesn't trigger after a resume, or whether there's some other problem here. The second mail in this bug con

Bug#725284: Bug#779412: block devices loosing state after resume: trigger udev rules to re-apply settings

Am Sat, 28 Feb 2015 09:38:27 +0100 schrieb Michael Biebl : > I don't think working around this in udev/systemd is a good idea. Idealy and in the long run, the kernel drivers should keep state, yes. But until then, better not to make releases with default configurations that deliver serious proble

Bug#725284: Bug#779412: block devices loosing state after resume: trigger udev rules to re-apply settings

Am 28.02.2015 um 09:30 schrieb Chris: > (http://bugs.debian.org/779412 explanation) > > There is a general problem with non-permanent block devices settings > (hard disks, optical disks, usb storage, ...), that are not restored > when resuming from suspend (instead using factory defaults and > l

Bug#725284: block devices loosing state after resume: trigger udev rules to re-apply settings

(http://bugs.debian.org/779412 explanation) There is a general problem with non-permanent block devices settings (hard disks, optical disks, usb storage, ...), that are not restored when resuming from suspend (instead using factory defaults and loosing all pre-suspend settings). And as long as

Bug#725284:

Control: reopen 725284 Udev rules are only trigged when devices appear/disapper, but not when the kernel suspends (with the device staying present and only entering a low power state) A systemd unit file is required to recover all hdparm settings that devices wrongly initialize back to factory d

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi, > I just uploaded 9.43-2 with the patch mentioned in this bug report. However, > I lack the hardware to test hdparm. So please test it before I file an > unblock request. This doesn't seem to work: After suspend-resume, my disk behaves as if hdparm was not run at all. I did not yet investigat

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

I just uploaded 9.43-2 with the patch mentioned in this bug report. However, I lack the hardware to test hdparm. So please test it before I file an unblock request. Also I'm not sure if it's a wise idea to remove the init file at this stage of the release. Thanks. Michael -- Michael Meskes Mic

Bug#725284: hdparm + systemd: Configuration not restored after resume

* https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1248012 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725284#10 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725284#54 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

On Wed, 25 Dec 2013 17:33:04 +0100 Ralf Jung wrote: > adding the attached systemd unit fixes restoring the hdparm > configuration when systemd is used. I'd appreciate if you could add this > (or a similar solution) to the package. I second this (works for me), although I suppose it would be even

Bug#725284: hdparm + systemd: Configuration not restored after resume

severity 725284 serious thanks Looking at RC bugs, there are some bugs related to systemd integration, and this one specifically affects hardware lifetime, so I thought it would be right to mark it as RC. Apologies in advance if it's not appropriate. -- To UNSUBSCRIBE, email to debian-bugs-

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi, >> Well, I guess that depends on what "support" exactly means, but with >> udev assigning device names dynamically, it seems pretty unreliable to >> me to use /dev/sd? in the hdparm configuration. > But udev is assigning device names dynamically right now already? I > don’t see how the change

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi Ralf, Ralf Jung writes: >> Ralf Jung writes: I’d rather see the Ubuntu solution in the Debian packages: in Ubuntu, they call a small script from udev when devices appear. That script uses /lib/hdparm/hdparm-functions to parse the file and run hdparm for the newly appeared

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi, > Ralf Jung writes: >>> I’d rather see the Ubuntu solution in the Debian packages: in Ubuntu, >>> they call a small script from udev when devices appear. That script uses >>> /lib/hdparm/hdparm-functions to parse the file and run hdparm for the >>> newly appeared device. The init script can b

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi Ralf, Ralf Jung writes: >> I’d rather see the Ubuntu solution in the Debian packages: in Ubuntu, >> they call a small script from udev when devices appear. That script uses >> /lib/hdparm/hdparm-functions to parse the file and run hdparm for the >> newly appeared device. The init script can be

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi, > I’d rather see the Ubuntu solution in the Debian packages: in Ubuntu, > they call a small script from udev when devices appear. That script uses > /lib/hdparm/hdparm-functions to parse the file and run hdparm for the > newly appeared device. The init script can be dropped entirely then. > >

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Hi Ralf, Ralf Jung writes: > adding the attached systemd unit fixes restoring the hdparm > configuration when systemd is used. I'd appreciate if you could add this > (or a similar solution) to the package. I’d rather see the Ubuntu solution in the Debian packages: in Ubuntu, they call a small scr

Bug#725284: hdparm + systemd: Patch to restore configuration after resume

Dear maintainer, adding the attached systemd unit fixes restoring the hdparm configuration when systemd is used. I'd appreciate if you could add this (or a similar solution) to the package. Kind regards Ralf [Unit] Description=hdparm resume actions After=suspend.target After=hibernate.target Afte

Bug#725284: hdparm + systemd: Configuration not restored after resume

Package: hdparm Version: 9.43-1 Severity: normal Dear Maintainer, when using hdparm and systemd, the HDD configuration is not properly restored after resuming the system from standby. Instead, the default value (APM = 128) is used again which lets the disk click all the time. Kind regards Ralf