Am Wed, 9 Mar 2016 13:08:48 +0100
schrieb Raphael Hertzog :
> /lib/hdparm/hdparm-functions seems to be the place to host common
> code...
>
> So can you let us know what function needs to move there?
In 95hdparm-apm, the code does't seem to contain separate hardcoded
default values anymore (prop
Control: retitle -1 Refactor pm-utils and apmd specific functions
Control: severity -1 wishlist
On Wed, 04 Mar 2015, Chris wrote:
> So this report is just to cover the refactoring of the former
> pm-utils and apmd specific functions (maybe also into
> some /lib/hdparm/hdparm.sh) and call that from
Hello,
I'm trying to solve a similar issue with laptop-mode-tools in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780956#30 (it hasn't
worked so far, but it might be some race issue).
What might be relevant to this bug (and the related ones like
http://bugs.debian.org/725284) might be a proto
Actually, I now filed a separate bug report for the proper default
wildard configuration. https://bugs.debian.org/779787
And the systemd unit file to call hdparm on resume is covered by
https://bugs.debian.org/725284
So this report is just to cover the refactoring of the former
pm-utils and apmd
With udev rules that call a script to applies the apm_on_ac or apm_on_battery
settings accordingly,
the systemd resume could be handled with a unit file like this:
[Unit]
Description=Trigger all block device udev rules on resume to re-apply
non-permanent device settings (e.g. smartctl and hdpar
Package: hdparm
Severity: serious
The apm/pm-utils suspend/resume functionalities, provided by shipping the
files 20hdparm and 95hdparm-apm scripts, do not work with systemd.
(missing systemd unit files)
To allow setting defaults I would suggest to support wildcards in hdparm.conf.
And ship with
6 matches
Mail list logo
