on 17/02/2012 16:28 Hiroki Sato said the following: > Andriy Gapon <a...@freebsd.org> wrote > in <4f3e3000.9000...@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.
Sorry, I haven't really given a thought to what you wrote below. You said that "this is not mandatory in the UEFI specification" and I gave the quotes which say that it is. Also keep in mind that BIOS and other OSs know nothing about FreeBSD GEOM. > 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 -- Andriy Gapon _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
