Bug#725284: marked as done (hdparm + systemd: Configuration not restored after resume)

Your message dated Thu, 17 Mar 2016 10:34:56 + with message-id and subject line Bug#725284: fixed in hdparm 9.48+ds-1 has caused the Debian Bug report #725284, regarding hdparm + systemd: Configuration not restored after resume to be marked as done. This means that you claim that the problem

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#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: marked as done (hdparm + systemd: Configuration not restored after resume)

Your message dated Tue, 24 Feb 2015 11:33:50 + with message-id and subject line Bug#725284: fixed in hdparm 9.43-2 has caused the Debian Bug report #725284, regarding hdparm + systemd: Configuration not restored after resume to be marked as done. This means that you claim that the problem

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-rc-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