For the record, this was just discussed in #u-release:
pitti cjwatson: it looks like you just remove the -B option, while Jeroen's
change disables hdparm altogether (hdparm-functions has other bits); but I
believe -B is the only thing we actually ship by default
cjwatson that was my assessment from reading the code
cjwatson double-checking wouldn't hurt
pitti cjwatson: it seems to be that the bug doesn't happen on that particular
operation, but on the initial IDENTIFY DEVICE
pitti (incidentally that's very similar to the recent udisks-probe-ata-smart
bug)
pitti cjwatson: so from what I can see, if an user would customize
/etc/hdparm.conf to set other options than -B, they would again be done for
firefire drives, too, and again break them?
pitti (conversely, with Jeroen's variant you couldn't ever run custom hdparm
commands on any firewire drive)
cjwatson I think so
cjwatson though hdparm.conf can be disk-specific
pitti sounds like being between a rock and a hard place :(
pitti ah, it can?
pitti ok, then I prefer your fix indeed :)
pitti ah, right, these come in /dev/foo { } blocks
cjwatson such is my understanding
cjwatson a release note mightn't hurt
I don't think that one of the two approaches is "obviously" right, but I
think Colin's approach is more flexible for actually being able to
control some fw drives with hdparm (with customized configuration), and
it will stop the corruption on a default installation.
--
hdparm's IDENTIFY DEVICE command breaks firewire devices
https://bugs.launchpad.net/bugs/548513
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
