# udevadm test /block/sda 2>&1 | grep "^util_run_program:.*started"
util_run_program: 'ata_id --export /dev/sda' started
util_run_program: 'scsi_id --whitelisted --replace-whitespace -p0x80 -d/dev/sda' started
util_run_program: 'path_id /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sda' started
util_run_program: '/sbin/blkid -o udev -p /dev/sda' started
util_run_program: 'edd_id --export /dev/sda' started
util_run_program: 'devkit-disks-part-id /dev/sda' started
util_run_program: 'devkit-disks-probe-ata-smart /dev/sda' started
This did trigger the HSM violation.
Testing more, I think that devkit-disks-probe-ata-smart is the one triggering the violation (devkit is new in Karmic?). However, it doesn't always show.
I think it might be related to the delay between the different commands. If the delay is too big it doesn't always show . But if the delay is too small, we cannot be sure which one triggered the command.
The delay between running devkit-disks-probe-ata-smart and the actual violation being logged is not constant. Maybe devkit-disks-probe-ata-smart sets things up, but the actual violation only triggers after some other activity occurs (e.g. simple disk access).
Scott,
# udevadm test /block/sda 2>&1 | grep "^util_ run_program: .*started" whitespace -p0x80 -d/dev/sda' started pci0000: 00/0000: 00:1f.2/ host1/target1: 0:0/1:0: 0:0/block/ sda' started disks-part- id /dev/sda' started disks-probe- ata-smart /dev/sda' started
util_run_program: 'ata_id --export /dev/sda' started
util_run_program: 'scsi_id --whitelisted --replace-
util_run_program: 'path_id /devices/
util_run_program: '/sbin/blkid -o udev -p /dev/sda' started
util_run_program: 'edd_id --export /dev/sda' started
util_run_program: 'devkit-
util_run_program: 'devkit-
This did trigger the HSM violation.
Testing more, I think that devkit- disks-probe- ata-smart is the one triggering the violation (devkit is new in Karmic?). However, it doesn't always show.
I think it might be related to the delay between the different commands. If the delay is too big it doesn't always show . But if the delay is too small, we cannot be sure which one triggered the command.
The delay between running devkit- disks-probe- ata-smart and the actual violation being logged is not constant. Maybe devkit- disks-probe- ata-smart sets things up, but the actual violation only triggers after some other activity occurs (e.g. simple disk access).
I will try again to isolate it.
Raf.