Re: Unable to access firewire hard drive
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2012-02-20 22:54:27
|
On Feb 20 Clemens Ladisch wrote: > Stefan Richter wrote: > > ... the FireWire firmware might return false size information, read from > > bogus offsets, or give whatever else false information. > > Peter Christy wrote: > | USB: > | ~$ xxd -g1 /dev/sdd | head -32 > | 0000000: fc 31 c0 8e d0 31 e4 8e d8 8e c0 be 00 7c bf 00 .1...1.......|.. > | 0000010: 06 b9 00 01 f3 a5 be ee 07 b0 08 ea 20 06 00 00 ............ ... > | 0000020: 80 3e b3 07 ff 75 04 88 16 b3 07 80 3c 00 74 04 .>...u......<.t. > | ... > | ~$ xxd -g1 /dev/sdd1 | head -32 > | 0000000: eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 .R.NTFS ..... > | 0000010: 00 00 00 00 00 f8 00 00 3f 00 ff 00 00 08 00 00 ........?....... > | 0000020: 00 00 00 00 80 00 80 00 ff 37 a1 12 00 00 00 00 .........7...... > | ... > | FireWire: > | ~$ xxd -g1 /dev/sdd | head -32 > | 0000000: 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b 20 53 tem formatRack S > | 0000010: 79 73 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b ystem formatRack > | 0000020: 20 53 79 73 fc 31 c0 8e d0 31 e4 8e d8 8e c0 be Sys.1...1...... > | 0000030: 00 7c bf 00 06 b9 00 01 f3 a5 be ee 07 b0 08 ea .|.............. > | 0000040: 20 06 00 00 80 3e b3 07 ff 75 04 88 16 b3 07 80 ....>...u...... > | ... > | ~$ xxd -g1 /dev/sdd1 | head -32 > | 0000000: 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b 20 53 tem formatRack S > | 0000010: 79 73 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b ystem formatRack > | 0000020: 20 53 79 73 eb 52 90 4e 54 46 53 20 20 20 20 00 Sys.R.NTFS . > | 0000030: 02 08 00 00 00 00 00 00 00 f8 00 00 3f 00 ff 00 ............?... > | 0000040: 00 08 00 00 00 00 00 00 80 00 80 00 ff 37 a1 12 .............7.. > | ... > > There's 36 bytes of garbage prepended to each sector, and the 36 bytes > from the end are missing. > > The system _did_ manage to find the correct first sector of the > partition, so it seems that this error did not occur when the kernel > first read the partition table. So maybe udev's scsi_id helper program asked for a Vital Product Data page, got it (or something else), and the firmware has a corrupted buffer pointer left over from that Inquiry. That's what PL3507 FireWire firmwares tend to do when faced with an Inquiry other than the very first one. Windows and presumably older Linux userspace might not have sent such an impertinent Inquiry. 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.) But! According to the manual page of the scsi_id version which I have here, scsi_id per default does not poke at devices which were not whitelisted in /etc/scsi_id.config. So maybe the confusion comes from somewhere else, I don't know. -- Stefan Richter -=====-===-- --=- =-=-- http://arcgraph.de/sr/ |