Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jun 2012 14:11:46 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>
Cc:        Doug Rabson <dfr@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, Andriy Gapon <avg@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: [CFC/CFT] large changes in the loader(8) code
Message-ID:  <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net>
In-Reply-To: <4FEB7181.9000508@yandex.ru>
References:  <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> <AFD7FE25-F536-4594-81E4-5E6F54207C11@xcllnt.net> <4FEB7181.9000508@yandex.ru>

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

On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote:

> On 28.06.2012 00:14, Marcel Moolenaar wrote:
>>> Our loader detects that primary GPT header is damaged. It tries to read
>>> backup GPT header from the last LBA and it detects that there is
>>> "GEOM::" signature. It tries to read one previous sector and there is
>>> *valid* GPT header.
>> 
>> How do you know it's valid? It's in a location that is not valid
>> to begin with. Validity is based on rules and you're violating the
>> the rules without defining exactly what we call valid given the
>> new rules. This may seem nitpicking, but having went through the
>> hassle of dealing with the broken way we created the dangerously
>> dedicated disk, I appreciate the importance of being anal when it
>> comes to something that lives on non-volatile storage and gets to
>> be exposed to a world much larger than FreeBSD.
> 
> So why do you not prevent to attach GEOM_PART_GPT to any providers that
> are not the disk drive? This will be the right solution to all our
> problems. Just don't create invalid GPT.

It's not even the right solution, as it prevents legit nesting
of gpart GEOMs *and* is fundamentally based on a flawed assumption
that any non-disk GEOM underneath gpart yields an invalid GPT.
Think gnop.

-- 
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?658E457B-3107-4BE8-A8EE-4F97D021843E>