Thread: Re: Unable to access firewire hard drive
Brought to you by:
aeb,
bencollins
From: Peter C. <ch...@at...> - 2012-02-22 09:43:58
|
On Monday 20 February 2012 22:54:15 you wrote: > On Feb 20 Clemens Ladisch wrote: > > Peter, 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? Cheers, -- Pete ch...@at... |
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/ |
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 |
From: Stefan R. <st...@s5...> - 2012-02-22 19:12:04
|
On Feb 22 Peter Christy wrote: > Can I leave it to you good folks to pursue? I'm quite happy to try out > potential fixes to see if they work. Sure, I will come up with something when time permits and keep you Cc'ed in case that tests with your disk are required or if upstream people ask for more information or a different approach. -- Stefan Richter -=====-===-- --=- =-==- http://arcgraph.de/sr/ |
From: Peter C. <ch...@at...> - 2012-02-23 12:47:23
|
Many thanks! -- Pete ch...@at... On Wednesday 22 February 2012 19:11:36 Stefan Richter wrote: > On Feb 22 Peter Christy wrote: > > Can I leave it to you good folks to pursue? I'm quite happy to try out > > potential fixes to see if they work. > > Sure, I will come up with something when time permits and keep you Cc'ed in > case that tests with your disk are required or if upstream people ask for > more information or a different approach. |
From: Stefan R. <st...@s5...> - 2012-04-11 12:02:35
|
> On Wednesday 22 February 2012 19:11:36 Stefan Richter wrote: > > On Feb 22 Peter Christy wrote: > > > Can I leave it to you good folks to pursue? I'm quite happy to try > > > out potential fixes to see if they work. > > > > Sure, I will come up with something when time permits and keep you > > Cc'ed in case that tests with your disk are required or if upstream > > people ask for more information or a different approach. Sorry that I haven't followed up upon this yet, will do so at some point... -- Stefan Richter -=====-===-- -=-- -=-== http://arcgraph.de/sr/ |