Date: Sun, 24 Aug 2014 13:11:44 +0400 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Craig Rodrigues <rodrigc@FreeBSD.org>, Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <53F9AC50.1000000@yandex.ru> In-Reply-To: <CAG=rPVe8Lh=P2MUdycM7%2B2mpSBPhe%2BkTvxR_bjnZfB1EkvK92Q@mail.gmail.com> References: <CAG=rPVeucq%2BsMxe_NPe3Og939o=Sg4WGfYL7PjA1uXGU8uL=8g@mail.gmail.com> <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <CAG=rPVes3Eq87hOE6W135yGvzRiAzHTbCGSxiyd0JBAs2ufqmA@mail.gmail.com> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <CAG=rPVfe6pP08WWaYQ6enk7A6AkT3dBXVxNfK0JgJPaN_rJ_Uw@mail.gmail.com> <CAG=rPVe8Lh=P2MUdycM7%2B2mpSBPhe%2BkTvxR_bjnZfB1EkvK92Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 24.08.2014 06:14, Craig Rodrigues wrote:
> Hi,
>
> I did some more experiments, and found that after /boot/loader runs,
> if I break into the loader prompt and type "lsdev", I would get this:
>
> (1) GPT Disk image which boots under QEMU, made by bsdinstall
> ==================================================
> View from loader
> ============
> OK lsdev
> cd devices:
> disk devices:
> disk0: BIOS drive A:
> disk1: BIOS drive C:
> disk1p1: FreeBSD boot
> disk1p2: FreeBSD UFS
> disk1p3: FreeBSD swap
> pxe devices:
>
>
> View from gpart, after we mdconfig the disk image
> ====================================
> => 34 10485693 md0 GPT (5.0G)
> 34 128 1 freebsd-boot (64K)
> 162 9959296 2 freebsd-ufs (4.7G)
> 9959458 524288 3 freebsd-swap (256M)
> 10483746 1981 - free - (991K)
>
>
> (2) GPT Disk image which fails to boot under QEMU, made by mkimg
> ===================================================
> View from loader
> ============
> OK lsdev
> cd devices:
> disk devices:
> disk0: BIOS drive A:
> disk1: BIOS drive C:
> pxe devices:
>
> View from gpart, after we mdconfig the disk image
> ====================================
>
> => 3 1784944 md1 GPT (872M)
> 3 32 1 freebsd-boot (16K)
> 35 1784912 2 freebsd-ufs (872M)
>
>
>
> This leads me to believe that there is logic in /boot/loader,
> which is not in GEOM, that fails to parse the GPT produced by mkimg.
>
>
> I did some further debugging inside the loader by doing the following.
> -> I added "CFLAGS += -DPART_DEBUG" to sys/boot/common/Makefile.inc
> -> I added DEBUG() statements all over sys/boot/common/part.c
>
> I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
> that in this section:
>
> 305 ent = (struct gpt_ent *)tbl;
> 306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
> 307 MAXTBLSZ * table->sectorsize);
> 308 for (i = 0; i < size / hdr.hdr_entsz; i++, ent++) {
> 309 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused, NULL))
> 310 continue;
>
> ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails
> out of the loop and never adds the gpt partitions to the list of partitions
> that the loader can access.
>
> I'm not familiar with the GPT format, nor am I familiar with the
> gpt code inside the loader, and how it differs from GEOM.
>
> Do you have any further ideas of where to hunt for the root cause of
> the problem?
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
--
WBR, Andrey V. Elsukov
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJT+axWAAoJEAHF6gQQyKF6n7YH/A2govCmT58wOKPHY41fWLSQ
H+QG+CwrPZjYk+kSHwvtER3I6LMjID59XBc6NsKRQ3fYwmtRgZHiRSs0lelFpv60
5/7WZURmLvLIAdihc8v1TjIm5xdxNZSYVC5AkZwzjbHmp0KoU5MfN8up98OqsnoY
TkuXGCVaGtqqT2ybCyggUyBEyyua6Wi58/sLF2ArzTMU8bwQIqSwjD+P/P61FurV
ZzHxnYHjD8vkhhj8EFfzkt4mxAssyEihaARsjaLQ+F1GuTLWEW4XGf2oonfcJ4XS
XsHWbCFGmi4aEgF1BEo3zoiRIzJpTgQZyTSIT6kVEPo+vPHXL2n+gSu2P5Hjl14=
=+zgW
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F9AC50.1000000>