On Tue, 4 Jan 2011, Warren Block wrote: > On Tue, 4 Jan 2011, Chris Brennan wrote: > > > On Tue, Jan 4, 2011 at 3:56 AM, Ian Smith <smi...@nimnet.asn.au> wrote: > > > > > On Mon, 3 Jan 2011 16:31:17 -0500, Chris Brennan wrote: > > > [.. trimming ccs, selectively quoting and de-gmailing a bit ..] > > > > > > > Trimmings! Oh nevermind. I don't know what possessed me to go and look > > at the debug window. But I do and I see the following. > > > > GEOM: ad4: the primary GPT table is corrupt or invalid. > > GEOM: ad4: using the secondary instead -- recovery strongly advised. > > > > This is even after zero the beginning and the end of the drive .... > > Something is hinky!
Indeed. Well Chris attached the following to his prior email, which made it to the list being text, dmesg didn't, application/octet-stream: http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20110104/c370dd77/dmesg-0001.obj But confirming the GEOM messages shown above, here's the 'smoking gun': 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...| 00004010 2b b3 b7 fa 00 00 00 00 ef 66 54 57 00 00 00 00 |+........fTW....| 00004020 01 00 00 00 00 00 00 00 22 00 00 00 00 00 00 00 |........".......| 00004030 ce 66 54 57 00 00 00 00 45 51 13 4c 0e 0e e0 11 |.fTW....EQ.L....| 00004040 95 6e 00 1d 72 5b f5 d6 cf 66 54 57 00 00 00 00 |.n..r[...fTW....| 00004050 80 00 00 00 80 00 00 00 86 d2 54 ab 00 00 00 00 |..........T.....| 00004060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004200 So that is really the last 33 sectors of the disk (0x4200 = 16896d, / 512 = 33) and the last sector does indeed have the 'GPT EFI' signature (ref: http://en.wikipedia.org/wiki/GUID_Partition_Table), so the seek and count looks right, matching the read command I'd suggested: > dd if=/dev/ad4 iseek=1465149135 count=33 | hd Seems odd that it hasn't been zeroed, but all the sectors before it are (ie there's just the header, no actual 128-byte partition entries if I'm interpreting this correctly), so maybe there's still some off-by-one in counting from the end of the disk for writing, not knowing the actual dd command used .. you're not wrong that negative offsets can be tricky! > Today I also found that zeroing the beginning and end of the drive didn't > seem to be enough. I had the start of a huffy email about how hard it was to > calculate the end of a drive in blocks, and how dd didn't have a negative > oseek to seek backwards from the end. But then I checked gpart(8)... and it > turns out that > > # gpart destroy -F da0 > > works. Be very careful that you've got the right drive there, of course. Saw Chris' later message that -F isn't there for him, but here's what should be, on the data, the sure-fire way to clobber that last sector: dd if=/dev/zero of=/dev/ad4 oseek=1465149167 which command SHOULD report just 512 bytes written (we're sure it can't write past the end of the disk with no count specified), after which: dd if=/dev/ad4 iseek=1465149167 | hd SHOULD show zeroes from 00000000 to 000001ff (ie next block 00000200) If not, there really must be some hardware issue with writing? Hopefully getting there! cheers, Ian _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
