Date: Sat, 23 Aug 2014 19:14:17 -0700 From: Craig Rodrigues <rodrigc@FreeBSD.org> To: 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: <CAG=rPVe8Lh=P2MUdycM7%2B2mpSBPhe%2BkTvxR_bjnZfB1EkvK92Q@mail.gmail.com> In-Reply-To: <CAG=rPVfe6pP08WWaYQ6enk7A6AkT3dBXVxNfK0JgJPaN_rJ_Uw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Thanks.
--
Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG=rPVe8Lh=P2MUdycM7%2B2mpSBPhe%2BkTvxR_bjnZfB1EkvK92Q>