Date: Fri, 17 Feb 2012 23:28:43 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: avg@FreeBSD.org Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer Message-ID: <20120217.232843.2212672671663755444.hrs@allbsd.org> In-Reply-To: <4F3E3000.9000206@FreeBSD.org> References: <CAOjFWZ5EhGFr_Vp0%2BTRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ@mail.gmail.com> <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)--
Content-Type: Multipart/Mixed;
boundary="--Next_Part(Fri_Feb_17_23_28_43_2012_801)--"
Content-Transfer-Encoding: 7bit
----Next_Part(Fri_Feb_17_23_28_43_2012_801)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Andriy Gapon <avg@FreeBSD.org> wrote
in <4F3E3000.9000206@FreeBSD.org>:
av> -----BEGIN PGP SIGNED MESSAGE-----
av> Hash: SHA1
av>
av> on 17/02/2012 09:04 Hiroki Sato said the following:
av> > No, the issue is our gptloader assumes the backup header is always located
av> > at the (physical) last sector while this is not mandatory in the UEFI
av> > specification.
av>
av> Are you sure?
Yes, sure. In the gm0->md0+md1 case, the last LBA of the "device" is
changed (growed in size) but they can still have a valid backup
header at "the last LBA - 1" before an attempt to grow the size of
the volume as the last paragraph of your excerpts says. If we
*choose* to grow the device size permanently, the backup header must
be relocated at the new last LBA. However, before the relocation
happens, the specification says both the primary and secondary header
must be valid in the previous device size. This is my understanding.
This means software should assume the device size can grow and should
not assume the backup header is always located at the last possible
LBA on the device. If AlternateLBA does not match "the device size -
1", the software should recognize the location of the backup header
based on the information in the primary header first. The gptboot
does not do so currently. I didn't give it a try actually but the
attached patch is what I want to say.
-- Hiroki
----Next_Part(Fri_Feb_17_23_28_43_2012_801)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="gptboot-20120217-1.diff"
Index: sys/boot/common/gpt.c
===================================================================
--- sys/boot/common/gpt.c (revision 230616)
+++ sys/boot/common/gpt.c (working copy)
@@ -333,24 +333,26 @@
gptread_table("primary", uuid, dskp, &hdr_primary,
table_primary) == 0) {
hdr_primary_lba = hdr_primary.hdr_lba_self;
+ /* Use AlternateLBA if valid. If not, use LastUsableLBA+34. */
+ if (hdr_primary_lba < hdr_primary.hdr_lba_alt)
+ altlba = hdr_primary.hdr_lba_alt;
+ else if (hdr_primary.hdr_lba_end != 0)
+ altlba = hdr_primary.hdr_lba_end + 34;
gpthdr = &hdr_primary;
gpttable = table_primary;
}
- altlba = drvsize(dskp);
- if (altlba > 0)
- altlba--;
- else if (hdr_primary_lba > 0) {
- /*
- * If we cannot obtain disk size, but primary header
- * is valid, we can get backup header location from
- * there.
- */
- altlba = hdr_primary.hdr_lba_alt;
+ /*
+ * Try to locate the backup header from the media size if no primary
+ * header found.
+ */
+ if (hdr_primary_lba == 0) {
+ altlba = drvsize(dskp);
+ if (altlba > 0)
+ altlba--;
}
- if (altlba == 0)
- printf("%s: unable to locate backup GPT header\n", BOOTPROG);
- else if (gptread_hdr("backup", dskp, &hdr_backup, altlba) == 0 &&
+ if (altlba != 0 &&
+ gptread_hdr("backup", dskp, &hdr_backup, altlba) == 0 &&
gptread_table("backup", uuid, dskp, &hdr_backup,
table_backup) == 0) {
hdr_backup_lba = hdr_backup.hdr_lba_self;
@@ -359,7 +361,8 @@
gpttable = table_backup;
printf("%s: using backup GPT\n", BOOTPROG);
}
- }
+ } else
+ printf("%s: unable to locate backup GPT header\n", BOOTPROG);
/*
* Convert all BOOTONCE without BOOTME flags into BOOTFAILED.
----Next_Part(Fri_Feb_17_23_28_43_2012_801)----
----Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEABECAAYFAk8+ZBsACgkQTyzT2CeTzy0M3ACg05dETV4WjnlHeiZwEJP/ujqC
JC0AoL9uL7LTO2jp47qsVQFoavNaA51A
=uxfH
-----END PGP SIGNATURE-----
----Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120217.232843.2212672671663755444.hrs>