> What if you set "apm = 64" in hdparm.conf? Is it overwritten with 254
> by the acpi-support script? Please file a new bug then, this one is
> already far too long...
I don't know. Due to bug #222458 I manually process /etc/hdparm.conf
a second time after booting has finished.
> If setting the apm level in hdparm.conf works it's not a real problem
> IMO as users need to edit hdparm.conf anyway to get the spindown.
Don't forget the user that, like me, added the spindown at least in
April 2008, if not before. A few days ago, his drive stopped spinning
down because of acpi-support's changes. It's not obvious to him to
think he needs to further modify the year-old /etc/hdparm.conf. Instead
he has to investigate and hopefully, like me, find this bug. As I said
earlier, that's one reason I'm describing the problem.
As I see it, the released fix can stop some drives spinning down that
were correctly configured before.
> What if you set "apm = 64" in hdparm.conf? Is it overwritten with 254
> by the acpi-support script? Please file a new bug then, this one is
> already far too long...
I don't know. Due to bug #222458 I manually process /etc/hdparm.conf
a second time after booting has finished.
awk '$1 ~ /^\/dev\/disk\// && $2 == "{" && NF == 2 { print $1 }' \
/etc/hdparm. conf |
while read d; do
sudo env DEVNAME=$d /lib/udev/hdparm
done
> If setting the apm level in hdparm.conf works it's not a real problem
> IMO as users need to edit hdparm.conf anyway to get the spindown.
Don't forget the user that, like me, added the spindown at least in
April 2008, if not before. A few days ago, his drive stopped spinning
down because of acpi-support's changes. It's not obvious to him to
think he needs to further modify the year-old /etc/hdparm.conf. Instead
he has to investigate and hopefully, like me, find this bug. As I said
earlier, that's one reason I'm describing the problem.
As I see it, the released fix can stop some drives spinning down that
were correctly configured before.