From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 07:01:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D263EA; Mon, 25 Aug 2014 07:01:29 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 946B2377D; Mon, 25 Aug 2014 07:01:28 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward8l.mail.yandex.net (Yandex) with ESMTP id D161F1A41160; Mon, 25 Aug 2014 11:01:17 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 2237E1B44CC4; Mon, 25 Aug 2014 11:01:16 +0400 (MSK) Received: from 5.255.232.27-red.dhcp.yndx.net (5.255.232.27-red.dhcp.yndx.net [5.255.232.27]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id f28ypVFTyW-1GU8xL7o; Mon, 25 Aug 2014 11:01:16 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 71018a18-88e2-4d3d-a846-7356904fd634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408950076; bh=7sPW1zZVuRLYifKzcBF85kgckJ2Ju00U2R5H8KKkhtY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=qq5Q2GLL1h14qxDTS+ytDBgBxQ7MrFwTSAB8QgpFh7fpLWmrEgi3y0mXA+bjjhaRb ZsbqHweKXX0qFdTwWbKzKjVZRFNMCljICpZF/oGKrdiZL4jrS2qzUxcaOShhIcqqUd Aq5c0WiVepSNKefIk4/nywRR1312dMt29vyf7Vyo= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53FADF14.80904@yandex.ru> Date: Mon, 25 Aug 2014 11:00:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marcel Moolenaar Subject: Re: mkimg used to create gpt image, problem booting References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> In-Reply-To: <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:01:29 -0000 On 24.08.2014 19:23, Marcel Moolenaar wrote: > > On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov 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 += -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. >> >> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. >> > > 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. Yes, you are right. I'll fix this. Thanks. > 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, Also there is bootparttest utility in the tools/tools/bootparttest. I think it can be useful for debugging. -- WBR, Andrey V. Elsukov