Date: Wed, 27 Jun 2012 08:07:23 -0400 From: John Baldwin <jhb@freebsd.org> 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: <201206270807.23347.jhb@freebsd.org> In-Reply-To: <4FEA910C.4090305@yandex.ru> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru>
index | next in thread | previous in thread | raw e-mail
On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote: > 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." Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. > 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. I would not assume it would work at all. If it can't trust the primary GPT, it has to assume the alternate is at the last LBA. > >> 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. We can't write bootcode with gpart? What do you think the 'bootcode' command does? Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even though there isn't a GPT object yet. -- John Baldwinhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206270807.23347.jhb>