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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1470014 Title: systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1470014/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
