Date: Sun, 24 Aug 2014 08:23:29 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: Craig Rodrigues <rodrigc@FreeBSD.org>, freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> In-Reply-To: <53F9AC50.1000000@yandex.ru> 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> <53F9AC50.1000000@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov <bu7cher@yandex.ru> =
wrote:
> On 24.08.2014 06:14, Craig Rodrigues wrote:
>> I did some further debugging inside the loader by doing the =
following.
>> -> I added "CFLAGS +=3D -DPART_DEBUG" to =
sys/boot/common/Makefile.inc
>> -> I added DEBUG() statements all over sys/boot/common/part.c
>>=20
>> I observed that in sys/boot/common/part.c in the ptbl_gptread() =
function,
>> that in this section:
>>=20
>> 305 ent =3D (struct gpt_ent *)tbl;
>> 306 size =3D MIN(hdr.hdr_entries * hdr.hdr_entsz,
>> 307 MAXTBLSZ * table->sectorsize);
>> 308 for (i =3D 0; i < size / hdr.hdr_entsz; i++, ent++) {
>> 309 if (uuid_equal(&ent->ent_type, =
&gpt_uuid_unused, NULL))
>> 310 continue;
>>=20
>> 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.
>=20
> Yes, the problem is in the ptable_gptread() function. I'll commit the =
fix.
>=20
Actually, no. There is *a* problem in that function:
The function does not respect hdr.hdr_entsz when it
needs the next entry. It simply uses "ent++", which
is fixed our definition of struct gpt_ent and may
not match the definition of the writer.
I don't see how the loader is responsible for *the*
problem. All I see in qemu is that the loader, when
it reads a sector, isn't getting the actual sector
data that's in the image.
Just do a ktrace on qemu and you'll see what I mean.
YMMV of course,
--=20
Marcel Moolenaar
marcel@xcllnt.net
--Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlP6A3EACgkQpgWlLWHuifYgfwCeIvzM+vFk32RyHMamcWFwZXJ0
qrgAn2pnmotXNp6y41y3lZ/RaJnyLWTt
=kYWo
-----END PGP SIGNATURE-----
--Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5003BFAC-D472-47CE-803B-F1AF8BF961B0>