Date: Wed, 27 Jun 2012 10:28:54 -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: <201206271028.54477.jhb@freebsd.org> In-Reply-To: <4FEB0079.7050008@yandex.ru> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: > On 27.06.2012 16:07, John Baldwin wrote: > >> =E2=80=A2 Check the Signature > >> =E2=80=A2 Check the Header CRC > >> =E2=80=A2 Check that the MyLBA entry points to the LBA that contains t= he GUID Partition Table > >> =E2=80=A2 Check the CRC of the GUID Partition Entry Array > >> If the GPT is the primary table, stored at LBA 1: > >> =E2=80=A2 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." > >=20 > > 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. >=20 > 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 :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) > > We can't write bootcode with gpart? What do you think the 'bootcode' c= ommand > > does? >=20 > `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 d= ata > and writes it to the provider. > `gpart bootcode -p` works like dd(1) and writes bootcode to the given par= tition. > gpart(8) haven't any knowledge about specific partitioning scheme. Correct, but in both cases it writes "bootcode". > > Also, there is no reason we can't have a 'recover' command that attempt= s to > > recover a corrupted table including repairing the PMBR. gpart(8) alrea= dy > > generates a full PMBR when you use 'gpart create' to create a GPT even = though > > there isn't a GPT object yet. >=20 > `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. You can't add a new ioctl? =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206271028.54477.jhb>