[Lucid] hdparm.conf change doesn't have effect

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in hdparm.

When reporting bugs in the future please use apport, either via the appropriate application's "Help -> Report a Problem" menu or using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Hello, I have same problem.

No harddisk spindown anymore in 10.04

I have build my own nas box around an atom board, and in it I have 4 1.5 Tbyte disks. When I build it I had low power in mind, so the operating system sits on a 2.5 disk that runs 24/7, and the disks that hold the array spin down when not needed.

Two days ago I updated this 9.10 server to 10.04, and discovered I could not spin down the array disks anymore. As stated before, it seemed hdparm.conf was ignored. If however I did hdparm -S 240 /dev/sd[a-d] it issued standby commands to all disks, but instantly the disks seemed to spin up again. In fact, it looked like even this command seemed to do nothing at all.

I then scrapped the whole thing and did a fresh install of 10.04 amd64, and again the disks would not spin down. Somewhere in the process my os disk failed as well, so in the end I put a new 2.5" disk in and installed 9.10 server again. Disks are nicely spun down again and all is like it should.

Tinkering with laptop-mode-tools did not help either, it resulted in a failed array. I had enough downtime here and will keep the box running 9.10 for a while.

Since this box does dhcp / dns and some other stuff that is needed on a daily basis, I cannot test anything as more people depend on functionality on the box. I have no idea whether this is caused by hdparm or something else.

@ Oscar: you can still help by clicking on "This bug affects me" in the upper left corner of this bug report. If you wish to be kept informed about new developments concerning this bug, you can subscribe to it (upper right corner of this bug report).

I'm not sure whether the bug is hdparm related or related to the boot process. The last information of Oscar seems to point in the direction of hdparm itself, though.

@pjotr12345, just clicked on the button, thanks for the tip.

It looks like it is hdparm, as all I did at first was an update of 9.10. All software running on the server was updated nicely and no extra services have been added in the proces. It could also be driver related that the sata drivers do not honor the requests hdparm makes.

Either way, it is a bit of a bummer really.

Sorry my bad, there is no fix yet and status is still 'confirmed'.
I was interested in the different kinds of status. I didnt expect i was able to change the status. Sorry.

Me too. /dev/sda {option, ...} blocks have no effect. Setting hdparm -B ... in /etc/rc.local doesn't do it neither. Unchecking "Park harddisk" in the Gnome energy settings is being ignored as well. Only sudo hdparm in terminal after login works. Was no problem in 9.10. Effect on two note-/netbooks

This bug is very sneaky in that way that i totally neglected is untill i read a thread on the ubuntu forums about it and noticed my laptop HD was doing it all the time while running on the battery.

Since it's killing my hard disk and i sometimes forget to manually input the line in terminal i hope this bug wil be solved...

The the terminal command itself works fine, as usual. It's only the automation of that command during boot, that has no effect. This would suggest that hdparm itself is allright, and that the bug is in the boot process....

Anyway, I would very much like a reaction from the developers in this thread. Please respond, so that we can help you fix this bug...

How about when switching power mode? I.e. going from powered to battery, or from battery to powered. Does /etc/hdparm.conf have any influence here? Is it even supposed to?

I solved my problem by installing laptop-mode-tools and used that to set my hdparm settings.

I've probably found the solution, but I need testers...

It seems that hdparm.conf isn't called anymore, because hdparm itself isn't called during boot. So what you can do is forget about hdparm.conf altogether, and alter the configuration file 20hdparm instead, which is located in /etc/apm/event.d

So:
gksudo gedit /etc/apm/event.d/20hdparm

In the text, you'll see the following text block:
# The APMD_DRIVES setting specifies the drives to be changed. Set
# this to an empty string to disable any changes.
#APMD_DRIVES=

Change the last line into
APMD_DRIVES=/dev/sda

(assuming that your hard drive is sda, which is the most common situation)

At the end of the next text block, you'll see this:
APMD_SPINDOWN=18

Change this into 254:
APMD_SPINDOWN=254

Then you'll see a text block starting with:
power_conserve ()

In that text block, you'll see this line:
"${HDPARM}" -q -S "${APMD_SPINDOWN}" "${DRIVE}" || true

Change the parameters for hdparm (delete -q -S and add -B instead):
"${HDPARM}" -B "${APMD_SPINDOWN}" "${DRIVE}" || true

Then you'll see a text block starting with:
power_performance ()

There, in the hdparm line, delete -q -S as well, and put instead -B. It becomes:
"${HDPARM}" -B 0 "${DRIVE}" || true

Save and close the configuration file. Then reboot your computer. All should be well now. :-)

Note: change 254 into 0, if you want to disable spindown entirely.

As said, I need testers! Please help testing this workaround and post your reactions here.

Unfortunately, I just discovered that altering /etc/apm/event.d/20hdparm doesn't work after all.... Please ignore my previous two messages in this thread.

I've also tried the laptop mode tools. Somehow this seemed to spindown the disks while MD had not flushed its writes to the disks, or it did something else so I ended up with 4 disks and no array. After some crash recovery I managed to get a degraded array back with 3 out of the 4 disks.
I got the 4th disk added to the array, and after some hours array was rebuild. It kinda takes the fun out of testing with live data on the disks. There's a bit over 1 Tbyte of data on the array, and backup / restoring is kinda time consuming.

@pjotr12345, I did not get my disks to spindown from commandline with hdparm -Y /dev/sd[a-d]. I did see "issueing sleep command" for all four disks, but straight after a hdparm -C /dev/sd[a-d] all disks show idle/running instead of standby.

The software repositories of Debian Squeeze hold a newer version of hdparm. This newer version seems to have a positive effect on my netbook. It installs fine in Ubuntu 10.04. Please help with testing!

You can get this newer version here:
32 bit: http://packages.debian.org/squeeze/i386/hdparm
64 bit: http://packages.debian.org/squeeze/amd64/hdparm

Simply double-click the installer. Afterwards, make sure that hdparm.conf has been configured correctly to (as you had to do in 9.10). Then reboot.

Please report the results of your testing in this thread.

It works for me!!
Nice work pjotr!

Let's hope it's gonna come as an update soon then :)

Marking it as confirmed again: a long test on my netbook shows that this workaround works fine for me. For others as well, it seems. The conclusion must be, that hdparm in Lucid is flawed and can easily be replaced by the newer hdparm currently in Debian Squeeze.

I'm not a developer, so I can't get this fix into the updates. So far, no developer has appeared in this thread. Hopefully one of them will react....

Good stuff Pjotr!

Any developer here that can look into getting this in place in the updates?

after several restarts, the new hdparm is still working fine. No problems anymore.
indeed, now its up to the developers to get this in place in the updates.

As said, the current hdparm version (9.27-2) in Debian Testing (Squeeze) fixes the problem. Therefore I've attached a compressed file which contains both the 32-bit version and the 64-bit version of hdparm 9.27-2. Simply double-click the .deb file and it'll install itself automatically. Then reboot.

Maybe this'll help getting it into the updates for Lucid....

@Pjotr (and others)
Can you please try the following configuration in hdparm.conf with the hdparm package from Ubuntu 10.04 (not the one from Debian!):

/dev/sda {
    apm = 255
    apm_battery = 254
}

Feel free to replace the values as you wish (e.g. some people might want to use "apm = 254").

Thanks for intervening, Jan! I'll try your suggestion.

For the benefit of others: you can easily downgrade from the Debian package to the official Ubuntu package, as follows:

System - Administration - Synaptic Package Management

Search for hdparm and click on the installed Debian package (9.27-2)

panel Synaptic - Package - Force version...

select version 9.15-1ubuntu9
..and apply.

Then add the lines which Jan suggests, to hdparm.conf.

Then reboot. And test.... Please report your findings here.

@ Jan: your solution seems to work.

I downgraded hdparm to the official Ubuntu version and added the lines you mentioned, to hdparm.conf (after removing the old lines which I had added, see the message with which I started this topic). Then I rebooted.

The results of nearly two hours testing are thus: the clicking noises of the hard drive don't return, not when the computer is in use and not when it's running idle. I rebooted several times; this caused no troubles.

So it appears that the right situation can be achieved with the official Ubuntu version of hdparm as well. No need to use the newer Debian version.

I'm still curious, though: why does the hdparm version in Lucid need these "new" configuration lines in hdparm.conf, instead of the "old" ones?

@Jan

I to can comfirm your solution did the trick, replaced the lines in hdparm.conf and rebooted, clicking is gone!!!

Thx

Okay, so basically the "problem" is that there is no 'hdparm' init script in Ubuntu anymore, and hdparm settings are set by an udev script. The udev script doesn't use the "command_line { ... }" section of hdparm.conf, so what's in there never gets executed.

Using udev for this makes more sense actually, as it also works with disks that are not present during boot but get added later, etc.

There still remain 2 issues:
1. this should be better documented (in 'man hdparm.conf', in the default 'hdparm.conf' comments, and preferable in the manual too)
2. this breaks backwards compatibility for 'hdparm.conf' ; again, this should be better documented (maybe added to the release notes before 10.04.1?)

Oh, I'd like to add: if you know any "how-to" or "guide" which recommends to use the 'command_line' section, please inform them about this and ask them to change this ASAP. The device-name sections that work with udev also work with older Ubuntu versions (I'm not sure up to which version?) so it should be generally safe.

I reverted the bug status to confirmed, as I'm not sure if this is intended behaviour, it might be a bug in the udev script. I'd like someone from the ubuntu foundations team to comment on this (either its a bug in the udev script, or it's a bug in the manpage and other documentation).

The solution in comment #21 works fine here, too.

Yes, I confirm that the solution works on my toshiba NB200 netbook.

Correction: the solution does NOT work after waking up from standby. The harddisk's load cyle count then still dramatically increases. Please confirm.

I don't confirm. After suspend (standby) i checked hdparm -B value, and it was unchanged. I checked load cycle count in 5 min and it didn't increase.

I just checked again and the solution definitively doesn't work on my Asus F3JA.

Before suspending/standby (s2ram):
$ sudo hdparm -I /dev/sda | grep "Advanced power management level"
 Advanced power management level: 254

After waking up:
$ sudo hdparm -I /dev/sda | grep "Advanced power management level"
 Advanced power management level: 128

The load cycle count immediatley starts to increase again and I have to set the APM to 254 manually with `sudo hdparm -B 254 /dev/sda`. hdparm.conf seems to be ignored when waking up from s2ram.

ok tried updating to the newer version of hdparm (hdparm_9.27-2_amd64)
this seems to work ok and the hdparm.conf is used during boot

hdparm -S24 /dev/sda this sets the drive standby time to 2 mins

i use sudo hdparm -C /dev/sda after 2-3 minutes but always returns

drive state is: active/idle

the drive never spinsdown

i have always used hdparm on 8.04 with no problems why with 10.04 this no longer works?

I've experienced the same with not being able to spin down idle disks.

Maybe this is a separate issue of hdparm / udev?

OscarMuntenaar, I have the same issue. I think it is related to this bug also. So far installing the package from Debian Squeeze and then doing "/etc/init.d/hdparm restart", helps. But when I reboot the HDs still do not spindown. I need to manually run "/etc/init.d/hdparm restart".

Telling people to use the "newer hdparm from Debian" doesn't help fixing this issue. Using the same package version of hdparm from Debian as is in Ubuntu will work too, as nothing got fixed in the newer version, and the fact that it works is only because Debian still uses a legacy method. What we need to figure out is why for some people it doesn't work with the new methods used in Ubuntu.

@daniel_L: I think 's2ram' isn't supported in Ubuntu? Are you sure this isn't a bug in that software?

@Jan Claeys: Sorry for the misunderstanding, I'm using Ubuntu's built-in function to suspend my notebook (= System -> Power Off -> Suspend in the main menu; I don't know the exact english menu descriptions because I'm using german as the system's main language), not the program s2ram or sth else. I just thought s2ram was the technical term for suspending to ram (now I know that this mode actullay is called S3 / Suspend-To-RAM (STR)).

I am just posting my findings after a couple of days snooping around. I have removed the Debian package that I previously installed and I am using Ubuntu hdparm package that comes with 10.04.

Just to clarify I am only concerned with disks not spinning down after upgrade to 10.04, as I have AC powered desktop. It does look to be a related issue however. If I am wrong then please let me know.

It looks like the stuff from "/etc/init.d/hdparm" was moved into "/lib/udev/hdparm" and "/lib/hdparm/hdparm-functions". Which is fine, as /etc/hdparm.conf should still work.

The udev rule in "/lib/udev/rules.d/85-hdparm.rules" calls "/lib/udev/hdparm" when udev "add" event is triggered for new drives, which in turn should set spindown intervals or any other settings you specified in "/etc/hdparm.conf" for your drives.

If I run "sudo udevadm trigger", which triggers udev "add" events for all devices, the settings do get applied just fine.

However if I reboot, then the settings do not get applied during boot.

So it seems the functionality in the new scripts works as it should, its just that they are not triggered during boot.

I added some "echo" lines to "/lib/udev/hdparm" just to debug, and when I manually trigger "add" events, my debug logs are created. After reboot no debug logs are created.

So I am guessing that either the rules script does not get triggered during boot, or may be it is triggered to early, which causes it to fail (e.g. file system not mounted etc).

@Maxim,

Thanks for shining some light on this. Hopefully this gets sorted.

I hope it gets sorted also. And I am happy I noticed this as this is quite a sneaky bug / behaviour change. I have a 4 disk raid 5 array in a server, and I only started looking into disk spindown because I was suspicious of getting more SMART temperature warnings after upgrading to 10.04.

In any case I don't think I know enough about udev / hdparm to start fixing anything.

But as a temporary workaround for disk spindown I added the following to "/etc/rc.local".

# workaround for hdparm disk spindown in 10.04
(echo "\n$(date)" && for devname in $(cat /etc/hdparm.conf | grep -o "/dev/sd[a-z]"); do export DEVNAME="$devname" && (/lib/udev/hdparm || true); done) >> /var/log/hdparm_fix.log

This looks into "/etc/hdparm.conf", gets all "sd*" device names and then runs "/lib/udev/hdparm" script in the same way the "/lib/udev/rules.d/85-hdparm.rules" rule does. This helps to set the settings I have in "/etc/hdparm.conf" during boot. For new devices plugged into the system after boot, the standard rule should work just fine. In case if anybody uses it, check the "/var/log/hdparm_fix.log" after boot to make sure it set the settings you have in your config.

When this problem will be resolved, I will just remove the line.

That's a nice workaround Maxim. I have reverted my server back to 9.10 as I wanted it to be working the way it was supposed to be. So I will wait until this gets fixed before I will update the server to 10.04 again.

For now I use the following workaround to set the APM values after resuming from Suspend-To-RAM. I created /etc/pm/sleep.d/99_load_cycle_count_fix and made it executable and the inserted the following script:

#!/bin/bash
case "$1" in
        hibernate|suspend)
                echo "nothing to do"
                ;;
        thaw|resume)
  hdparm -B 254 /dev/sda
                ;;
        *)
                echo "no parameter given"
                ;;
esac

The solution of comment #21 works to me too, but when i shutdown the Ubuntu, i got a big sound CLACK! in hd...
Anyone has any other solution for this?

My laptop: HP Compaq Presario CQ40-713BR

I used to use hdparm -y /dev/sdb in Karmic to manually put a backup drive into standby mode. This no longer works in Lucid, which is a pity. I love these regression bugs. Examining the status of the drive with hdparm -C /dev/sdb in Karmic after -y would show the drive in standby. In Lucid, it shows it as active/idle. The drive does not spin down because in Karmic I could hear it and in Lucid I can't hear it spinning down.

Saw solution in comment 21 but missed details of patch in comment 20. Thanks to pjotr12345.

Installed attached hdparm. -y still does not spin the drive down as it did in Karmic :(

I have been avoiding using my notebook for weeks now waiting on a fix. I've changed laptop-mode.conf to 254 even on battery (and then rebooted), and the age-old ubuntu problem of 100+ load cycles an hour (until a fix is found) is still occurring. You are causing damage to people's machines by not fixing this!

The 'command_line' feature of hdparm.conf is no longer supported and there is no plan to reintroduce support for it. If you want to run an hdparm command unconditionally on boot, you can add an init script or an upstart job to your system; there's no reason this should be in a config file like hdparm.conf.

The fact that this is still listed in the manpage and in the default hdparm.conf is an oversight that will be addressed in the next upload.

This bug was fixed in the package hdparm - 9.27-2ubuntu2

---------------
hdparm (9.27-2ubuntu2) maverick; urgency=low

  * debian/hdparm.conf, debian/hdparm.conf.5: drop 'command_line' example
    from the default hdparm.conf since it's no longer supported, and update
    the manpage to match. LP: #568120.
 -- Steve Langasek <email address hidden> Mon, 14 Jun 2010 14:47:50 -0700

@ steve:

What about the issue seen with spinning down disks also declared in /etc/hdparm.conf, they're not classed in the command_line section, but I cannot seem to spin down my disks when idle the way it is running with ubuntu server 9.10, when I upgraded it to lucid, and when that not worked installing lucid from scratch.

Is that a different bug (and need to be posted separately) ?

Oscar,

The original bug report only talks about use of the command_line block, which is obsolete. You don't provide a copy of your hdparm.conf anywhere in the bug history, so I don't know what problem you're having; but it probably is not related.

Steve,

The problem is kind of related because previously init.d script used to set the spindown interval during boot. After init.d script was removed, the spindown interval is not being set during boot, which causes hard drives to always spin.

However on the other hand side, it is different, because spindown interval is not set inside command_line block.

My findings are in comment #38, and a temp workaround in comment #40, but I don't know how to fix the actual issue properly.

I consider this a serious issue, as I only noticed due to smartd sending me emails of high disk temperatures. It definitely needs to be addressed.

The thing to work out is if a separate bug needs to be created for this, or should we change this bug's description to cover the wider problem of moving away from init.d script?

my hdparm.conf just in case

cat /etc/hdparm.conf
# 60/240 (5min/20min)

/dev/sda {
    spindown_time = 240
}

/dev/sdb {
    spindown_time = 240
}

/dev/sdc {
    spindown_time = 240
}

/dev/sdd {
    spindown_time = 240
}

/dev/sde {
    spindown_time = 240
}

/dev/sdf {
    spindown_time = 240
}

/dev/sdg {
    spindown_time = 240
}

Maxim,

> My findings are in comment #38, and a temp workaround in comment #40,
> but I don't know how to fix the actual issue properly.

That issue is also unrelated to the original bug reported here. Please file a separate bug report if /lib/udev/hdparm is not being executed on boot.

Ok I created a separate bug for spindown issue #595138.

https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/595138

How can you say a fix was released?

My notebook's hard drive is still getting hundreds(!) of load cycles a day, whether plugged in or not, because it's not at 255. The old way to change it (in the old laptop-mode-related hdparm config files) didn't fix this. hdparm.conf AFAIK is not executed on suspend/resume. WHERE in laptop-mode-tools can the -B be configured to be set to 255 (or 254 or whatever) unconditionally?

I have been avoiding using my notebook for weeks now waiting on a fix. I've changed laptop-mode.conf to 254 even on battery (and then rebooted), and the age-old ubuntu problem of 100+ load cycles an hour (until a fix is found) is still occurring. You are causing damage to people's machines by not fixing this!

The files are not in these locations anymore, yet pm-utils still has this in it's hdparm config:

    if [ -e /usr/sbin/laptop_mode ] ; then
            LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf && ec
            if [ "$LMT_CONTROL_HD_POWERMGMT" != 0 ] \
               && [ -e /var/run/laptop-mode-tools/enabled ]
            then
                    # Laptop mode controls hdparm -B settings, we don't.
                    return
            fi
    fi

How is this not a bug?

THE BUG IS:

The file /usr/lib/pm-utils/power.d/95hdparm-apm owned by package "hdparm" version 9.15-1ubuntu9 in lucid (32-bit) checks for presence of laptop-mode-tools at the wrong location on the disk, then proceeds to manage the APM setting for the hard drive itself when laptop-mode-tools should be handling it.

Specifically, the files /usr/sbin/laptop_mode and /var/run/laptop-mode-tools/enabled have AFAICT been deprecated/moved. The bash script excerpt in my previous comment (which comes from the described file) includes the uses of these paths that urgently need correcting.

The bug I am reporting fits the original description in this bug but not the recently updated one. I apologize for not noticing that. Moving this laptop-mode-tools bug into bug 513706 and undoing status change.

[Correction for the record: Re my comments 44-46 previously. I am using hdparm 9.27-2 and "-y" is spinning the drive down as expected. I'm not sure why this was not the case when I tested previously.]

The solution Jan Claeys wrote on post #21 works very well.
Thank you vary much guy! :)

will choosing a lower apm value do anything? like.. 126/2 = 63 ?

How do you test the hdparm.conf settings? In other words, is there a way to execute the udev rules from the command line?

@ cmcginty:
For testing purposes you can use this command in the terminal (use copy/paste):
sudo hdparm -B 254 /dev/sda

Press Enter. Type your password when required; this will remain entirely invisible, not even dots will show, this is normal.
Then press Enter again.

As Jan Claeys already described, you can make the hdparm change permanent as follows:

In the terminal (use copy/paste in order to avoid typing errors):
gksudo gedit /etc/hdparm.conf

Press Enter.

Now Gedit starts with a text document. Add the following lines at the very end of this text document (use copy/paste):

/dev/sda {
    apm = 254
    apm_battery = 254
}

Save and close the text document. Now reboot your computer. You're done. :-)

I'm running 10.04 LTS server (no gui front end) and the contents of hdparm.conf are ignored.

I can put the disks to sleep with hdparm -y without problems. But the attached hdparm.conf never causes a spindown.

@Bob Harvey:
Maybe the syntax of your script is wrong: a missing space.

Your script is:
/dev/sda{

This should be:
/dev/sda {

Does adding the space help?

@ Pjotr
Just found this and tried it. It makes no difference. Thanks anyway.

I am now running 12.04LTS, and the problem is unsolved.

I suspect this bug should be marked as a duplicate of Bug 595138 ?