Re: Unable to access firewire hard drive
Brought to you by:
aeb,
bencollins
From: Peter C. <ch...@at...> - 2012-02-22 18:38:41
|
OK, but as I intimated in my orignal post, I would not consider myself a programmer! I used to do 8-bit machine code and assembler as a hobby may years ago, and I can fumble my way around C to an extent, but that's about my limit. Knowing what to do here, or how to fix it is a bit over my head! Can I leave it to you good folks to pursue? I'm quite happy to try out potential fixes to see if they work. Cheers, -- Pete ch...@at... On Wednesday 22 February 2012 14:41:46 Stefan Richter wrote: > 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 |