Re: Unable to access firewire hard drive
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2012-02-22 14:42:09
|
On Feb 22 Peter Christy wrote: > On Monday 20 February 2012 22:54:15 you wrote: > > as a quick and dirty test, try "chmod a-x /lib/udev/scsi_id", then > > power on + plug in the disk via FireWire. (Haven't tried this myself; I > > hope udev keeps working despite being denied to run scsi_id.) > > Ha! Yes! When I did that, the drive was immediately recognised on switch-on, > and a prompt appeared asking me if I wanted to mount it! > > I mounted it, and everything worked exactly as expected! > > Bingo! > > So, where do we go from here? I should put an HDD into my PL3507 based ODD bay and check whether its firmware is afflicted in the same way. (It is evidently not affected when running in MMC mode, but might be when running in RBC mode.) Then we should think about whether a fix should be implemented in scsi_id or in /lib/udev/rules.d/60-persistent-storage.rules or in the kernel. And then we should propose a fix at lin...@vg... and lin...@vg... and see whether these folks like it. I tend to think that an udev rules¹ based fix is preferable. A scsi_id based fix and more so a kernel based fix would be more general. But issuing requests like Inquiry outside of the kernel and outside of stock udev operations could be considered an "everyone is entitled to shoot themselves in the foot" case. (Inquiry would be a perfectly safe request in a world without firmware bugs.) ¹) http://reactivated.net/writing_udev_rules.html -- Stefan Richter -=====-===-- --=- =-==- http://arcgraph.de/sr/ |