Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jul 2009 20:30:18 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: `gpart show` and secondary GPT header
Message-ID:  <A6416A11-1D78-41A9-B535-76F4FD512B87@mac.com>
In-Reply-To: <4A6F944D.6040909@omnilan.de>
References:  <permail-200906131853081e86ffa80000190b-a_best01@message-id.uni-muenster.de> <A7C988A9-DCFD-422B-B39D-B912FECEFD0D@mac.com> <4A344A9F.5020708@jrv.org> <BD2A6E6D-EC33-408E-913B-CAF96F774ACD@mac.com> <4A344C67.8000101@jrv.org> <ADAD4EA3-0D07-4CD5-8805-3D21BB40A5AD@mac.com> <4A37C1A7.1070801@omnilan.de> <19563E0A-3A5A-4B0C-BB89-934A44CF4A82@mac.com> <4A6F944D.6040909@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jul 28, 2009, at 5:14 PM, Harald Schmalzbauer wrote:

> Marcel Moolenaar schrieb am 16.06.2009 18:28 (localtime):
>> On Jun 16, 2009, at 9:00 AM, Harald Schmalzbauer wrote:
>>> Marcel Moolenaar schrieb am 2009-06-14 07:23 (localtime):
>>> ...
>>>>>>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT  
>>>>>>> table is
>>>>>>> corrupt or invalid.
>>>>>>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary  
>>>>>>> only --
>>>>>>> recovery suggested.
>>>
>>> I'm curious what the correct way to recover is.
>>> I also tried dd, but without success.
>>> `gpt` had a recover functionality if I remember corretcly.
>> Recovery is not yet implemented in gpart. That would be
>> the correct way to recover. And yes, gpt(8) has recovery.
>> Thus, gpt(8) is the right way to recover on -STABLE.
>
> Hello, I'd need some help.
> I tried to recover the secondary GPT after overwriting on the same  
> disk.
> I used 'dd if=/dev/ada0 iseek=1 count=1 oseek=1953525167 of=/dev/ada0'
> I thought this must work since the location of the secondary, stored  
> in the GPT header, is correct. But it doesn't.

The table is also duplicated. Thus, a few LBAs are different.
This means the checksum is different. Consequently, you can't
simply dd(8) to recover.
FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6416A11-1D78-41A9-B535-76F4FD512B87>