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     = 256 (on)
 geometry      = 25694/255/63, sectors = 234441658, start = 0