Comment 37 for bug 595138

I fixed this by using this patch (https://launchpadlibrarian.net/73763550/hdparm-functions.patch) that translates (unlinks) HDD path symlink inside /etc/hdparm.conf to /dev/sdX

but I also had to create this patch to the /lib/udev/hdparm, because I had to:
1) convert (readlink) DEVNAME input parameter to hdparm_options function in '/lib/hdparm/hdparm-functions' - this fixes issue when as input to /lib/udev/hdparm someone puts symlink
2) trim the trailing digits from the DEVNAME, because the udev rule puts disk device as well as partitions as input into the /lib/udev/hdparm

Example scenario I had:
1) udev rule runs /lib/udev/hdparm and passes /dev/sda1 as DEVNAME => outcome was that /dev/sda1 was not in /etc/hdparm.conf which made it apply DEFAULT settings
2) udev rule runs /lib/udev/hdparm and passes /dev/sda as DEVNAME => outcome was that /dev/sda was in /etc/hdparm.conf which made it apply CORRECT settings
3) udev rule runs /lib/udev/hdparm and passes /dev/sda2 as DEVNAME => outcome was that /dev/sda2 was not in /etc/hdparm.conf which made it apply DEFAULT settings

All in all, for me, between reboots, the order was random. Sometimes the disk came last and applied correct settings and sometimes partition came into play and was overwriting the /etc/hdparm.conf with the DEFAULTS