Re: [CFC/CFT] large changes in the loader(8) code

On 27.06.2012 21:55, Marcel Moolenaar wrote:
> You can't just re-interpret standards to match a context you know very well
> isn't applicable and consequently redefine what the word "device" means.
> You're on a slippery slope and while you may not see it as a problem, you
> do make it a problem for FreeBSD users. It's our users we should be keeping
> in mind when we solve problems.
> 
>> If a user wants modify GPT in the disk editor from the another OS,
>> he can do it, and it should work. The result depends only from the partition editor,
>> it might overwrite the last sector and might don't.
> 
> Right. Another happy user that sees his/her FreeBSD installation destroyed
> or degraded (no mirroring, warning messages about corrupted GPT, etc) for
> no apparent reason and without any kind of warning that what he/she is doing
> is potentially harmful... That's the spirit!

Ok. Let's return back to my patches. They don't add any new methods to
shoot in the foot. We are talking about the *FreeBSD loader*.
This is the program that starts FreeBSD kernel. It doesn't start other
OS. We already have many users who uses FreeBSD as a single system on
the machine. Many of them use GPT inside of some GEOM provider.
You can just read the lists, articles about installing FreeBSD, forums,
etc. We already have these users and i hope they will use FreeBSD as
before. So, why can't add a simple quirk to make theirs system a bit
more reliable?

As i understand there two parts where we haven't a consensus:

1. You are against from:
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. It is valid, because it's CRC is valid, it's
self_LBA is valid. For the *FreeBSD* users it is better to don't use
this GPT and just complain "i'm sorry, can't boot". The other OSes
can't, and we shouldn't.

2. You are against from having one fake PMBR entry by default in the
/boot/pmbr image. Ok, I can propose several ways to resolve this:
 * remove from the loader's GPT probing code restriction to necessarily
have PMBR partition record in the MBR;
 * teach the boot0cfg command properly write the PMBR;
 * add new condition to mark GPT as corrupt when it has invalid PMBR.
Thus, when you write PMBR with empty partition table with dd(1), the
kernel will complain and you will be forced to run `gpart recover`.

-- 
WBR, Andrey V. Elsukov