Date: Wed, 27 Jun 2012 16:45:45 +0400 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: John Baldwin <jhb@freebsd.org> 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: <4FEB0079.7050008@yandex.ru> In-Reply-To: <201206270807.23347.jhb@freebsd.org> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <201206270807.23347.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27.06.2012 16:07, John Baldwin wrote: >> • 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. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) >>> 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? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. > 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. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FEB0079.7050008>