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

On 26.06.2012 21:37, John Baldwin wrote:
>> 4. The gptboot now searches the backup GPT header in the previous sectors,
>> when it finds the "GEOM::" signature in the last sector. PMBR code also
>> tries to do the same:
>>         common/gpt.c
>>         i386/pmbr/pmbr.s
> 
> GPT really wants the backup header at the last LBA.  I know you can set it, 
> but I've interpreted that as a way to see if the primary header is correct or 
> not.  It seems to me that GPT tables created in this fashion (inside a GEOM 
> provider) will not work properly with partition editors for other OS's.  I'm 
> hesitant to encourage the use of this as I do think putting GPT inside of a 
> gmirror violates the GPT spec.

The standard says:
"The following test must be performed to determine if a GPT is valid:
• Check the Signature
• Check the Header CRC
• Check that the MyLBA entry points to the LBA that contains the GUID Partition Table
• Check the CRC of the GUID Partition Entry Array
If the GPT is the primary table, stored at LBA 1:
• Check the AlternateLBA to see if it is a valid GPT
If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a
valid GPT Header and point to a valid GPT Partition Entry Array."

For the FreeBSD an each GEOM provider can be treated as disk device.
So, i don't see anything criminal if we will add some quirks in the our loader
for the better supporting of our technologies.

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.

>> 5. Also the pmbr image now contains one fake partition record.
>> When several first sectors are damaged the kernel can't detect GPT
>> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1)
>> command, but the old pmbr image has an empty partition table and
>> loader doesn't able to boot from GPT, when there is no partition record
>> in the PMBR. Now it will be able. When pmbr is installed via 'gpart 
> bootcode'
>> command, the kernel correctly modifies this partition record. So, this is 
> only
>> for the first rescue step.
> 
> As I said earlier, I do not think this is appropriate and that instead
> gpart should have an appropriate 'recover' command to install just the pmbr on 
> a disk and also create a correct entry in the MBR if needed while doing so.

gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class.
It only sends control requests to the kernel. If GPT is not detected,
there is no geom objects to manage. And we can't write bootcode with gpart(8).
I think that adding such functions to the gpart(8) is not good. Maybe,
the boot0cfg is the better tool for that. Also we still haven't any tool to
install zfsboot.

-- 
WBR, Andrey V. Elsukov