systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5.

Status changed to 'Confirmed' because the bug affects multiple users.

I get the same error, and I've found the cause of it on my system:
- /lib/udev/rules.d/85-hdparm.rules calls /lib/udev/hdparm for every sdX and shX drive
- /lib/udev/hdparm loads functions from /lib/hdparm/hdparm-functions
- When the 'hdparm_options' function is called it sets a default global APM policy
- Because I'm on AC power, with a stock /etc/hdparm.conf file, this results in -B 254 getting set.

While you can change the APM value via hdparm.conf, the -B switch is going to get set, no matter what. And not all of my drives support that. I understand why this is being done, but, we need the ability to disable it. My suggestion is another option in hdparm.conf, say "noapm" :)

In the meantime, because I actually wish to use hdparm.conf and easily see any errors on boot, I've edited:
 /lib/hdparm/hdparm-functions, mine was line 88, comment out 'hdparm_set_option -B254'

Same bug has been reported against xenial: https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1568474

A solution could be, that support for APM is checked before trying to set APM level.

user@hostname:~/$ sudo hdparm -B /dev/sda
[sudo] salasana henkilölle user:

/dev/sda:
 APM_level = not supported
user@hostname:~/$

The other bug suggested this could be repeated by running (where sdX is the name of your block device, e.g. sda from /dev/sda):
sudo udevadm trigger --action=add /sys/block/sdX --verbose

Another way debug this without a reboot for a drive that's not mounted, you can disconnect the device and re-scan to add it.

# #Comment: First, figure out which logical port the drive is connected to:
# #Comment: In the output, make note of the host0 part. Other output may have host1 etc.
# #Comment: you may need to put a sudo in front of readlink.
# readlink /sys/block/sdX #e.g. for /dev/sda it would be readlink /sys/block/sda
../devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:1/0:0:1:0/block/sda

# #Comment: Force disconnect the device (you may have to "sudo su -" first, or use sudo with tee):
# echo 1 > /sys/block/sdX/device/delete

# #Comment: Trigger rescan (you may have to "sudo su -" first, or use sudo with tee).
# #Comment: Note host0 matches from the readlink call above:
# echo "- - -" > /sys/class/scsi_host/host0/scan

If you want to apply the workaround for xenial, you need to comment out both "hdparm_set_option -B254" and the "else" above it in /lib/hdparm/hdparm-functions. If you don't properly comment out the else section, then you'll get something like:
systemd-udevd[XXX]: Process '/lib/udev/hdparm' failed with exit code 2.

A workaround that didn't work for me was to add "hdparm_set_option -q" on the line before "hdparm_set_option -B254" /lib/hdparm/hdparm-functions . Just changing it to "hdparm_set_options -q -B254" results in the -B254 not getting set as a parameter, which may be good enough for some people.

To add some debugging code, add the following to line 2 of /lib/udev/hdparm like suggested in bug 1568474.
set -x; exec 2>>/tmp/hdparm.txt
When incorrectly commenting out the "-B254" part, you may see something in /tmp/hdparm.txt like:
/lib/udev/hdparm: 89: /lib/hdparm/hdparm-functions: Synax error: "fi" unexpected

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795025 says "the -B254 option status is written to the unavailable output and generates the IO error."

The correct solution seems to be, as suggested test if the -B option is accepted before using it, having hdparm ignore the error (with a -q on line 88?), or changing the hdparm code's handling of the -B option failing. It would be nice to know when it fails with a warning in syslog instead of this error. It may also be useful to somehow get the output of hdparm going directly to the syslog when there is a non-0 error code, or even adding some information about what the command line was for the statement that failed if /lib/udev/hdparm is allowed to write to syslog.

For me this may be a problem that comes and goes as I need to look at older drives where the APM_level is not supported. For the one drive I'm currently looking at I see:
user@host:~$ sudo /sbin/hdparm -B254 /dev/sda

/dev/sda:
 Setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error
 APM_level = not supported
user@host:~$ sudo /sbin/hdparm /dev/sda

/dev/sda:
 multcount = 16 (on)
 IO_support = 1 (32-bit)
 readonly = 0 (off)
 readahead = 2...

I can confirm this for ubuntu 16.04 with Kernel 4.4 (up-to-date).

I see this error in syslog, during boot (I'm using Luks-encrypted software raid (dmraid)).

I'm also using WD hard disks: WD30EURS

I ran into this (using hdparm 9.48+ds-1 running under Ubuntu
16.04.1 LTS) with some HP Enterprise MB4000GCWLV drives that don't
have APM support (i.e.
  hdparm -I /dev/sdb | grep "Advanced Power"
returns no output, or [as mentioned in comment #5] "hdparm -B"
reports "not supported").

For these drives, along with the "failed with exit code 5" log
messages, the default behavior of /lib/udev/hdparm triggered a
"SMART error (ErrorCount) detected on host" email from smartd each
time the system was rebooted (one email for each affected drive).

Each warning email had a message similar to:
   Device: /dev/sdb [SAT], ATA error count increased from 33 to 34
... and sure enough, "smartctl -l error /dev/sdb" showed errors
like this one:

Error 30 [1] occurred at disk power-on lifetime: 5380 hours (224 days + 4 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT LBA_48 LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  04 -- 51 00 00 00 00 00 00 00 00 00 00 Error: ABRT

  Commands leading to the command that caused the error were:
  CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- -- --------------- --------------------
  ef 00 05 01 fe dc d8 08 00 00 00 40 08 10:18:04.515 SET FEATURES [Enable APM]
  2f 00 00 00 01 00 00 00 00 00 11 00 08 10:17:53.325 READ LOG EXT
  2f 00 00 00 01 00 00 00 00 06 04 00 08 10:17:53.091 READ LOG EXT
  2f 00 00 00 01 00 00 00 00 05 04 00 08 10:17:52.857 READ LOG EXT
  2f 00 00 00 01 00 00 00 00 04 04 00 08 10:17:52.618 READ LOG EXT

Once I tracked these errors down to the default settings in the
hdparm udev script, I was able to avoid them by setting the "apm"
option to blank in a hdparm.conf device block, e.g.

/dev/disk/by-id/wwn[...] {
apm =
}

(This causes the script to end up running "hdparm -B" instead of
"hdparm -B254" for the drive in question, thus skipping the attempt
to enable APM on the drive, and as a result avoiding both the
error exit status message and a new instance of the error in the
ATA error log.)

       Nathan

I no longer see this bug in Ubuntu 16.10. Can anyone else confirm?

Seems this has been indirectly fixed somewhere in the past.