Date: Wed, 5 Jan 2011 16:44:12 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Warren Block <wblock@wonkity.com> Cc: Bruce Cran <bruce@cran.org.uk>, FreeBSD Questions <freebsd-questions@freebsd.org>, Chris Brennan <xaero@xaerolimit.net> Subject: Re: a new hard-drive in a 2y/o laptop Message-ID: <20110105152725.U49334@sola.nimnet.asn.au> In-Reply-To: <alpine.BSF.2.00.1101041840310.14633@wonkity.com> References: <20101229120038.3DFB0106591A@hub.freebsd.org> <20101230133126.O36121@sola.nimnet.asn.au> <AANLkTinCZuupW%2BGFMeL70nPO90tZAAJNj8g0SaOztsR3@mail.gmail.com> <20101231105353.S36121@sola.nimnet.asn.au> <AANLkTinSbE8d=iYES78GJmYO2PyOAGHMjwQ%2B2HT45yxc@mail.gmail.com> <20110102102255.00004f57@unknown> <20110102230702.N49334@sola.nimnet.asn.au> <20110103022619.O49334@sola.nimnet.asn.au> <AANLkTimkCdtULT9jfNtwKcfxF8R-TQ_j=qZgS-Y-YGfu@mail.gmail.com> <20110104143245.P49334@sola.nimnet.asn.au> <AANLkTi=Aqh4cpmdkHx1QsTyoYh7nhinEfDUuPO3fUAh5@mail.gmail.com> <alpine.BSF.2.00.1101041840310.14633@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <smithi@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110105152725.U49334>