From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 02:14:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57F41199 for ; Sun, 24 Aug 2014 02:14:21 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D30AF37B3 for ; Sun, 24 Aug 2014 02:14:20 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id u10so10829450lbd.32 for ; Sat, 23 Aug 2014 19:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4UnFHoJg7+6c/8AyljyzqJu0nYKK3DYNVpDFFoxbrUo=; b=cSBFHPTrYXTE7PpNbBaQxOoBsOTEU0DlzzSalP2+4esIOlkNG16ajlyz9BIZTcPkTa q2IoBT9l4Yn5vFmZksLoWuEaFcON1+FyGCRuMaRHfYgpBsoMsC45EId/hP2KQyLnh3Ui hLmvCFmBvwq+8hHYfD27p2LqRsioyk92vIpCFpxMIeSGkEE80ACQ/staRw9tnKS7iQPZ mtUV8gsPM4BEV2fR2r5TB2xs0cdau2+JithQEMCz8o3FLAcleSsj+S6Xe5nCy4hPxYpJ D+hDptIfkP5q3yBddbcBJTWMWxQMajqrCGFcDFeR5qDHLVVrVvvOEIrZCGXZ3MeSJfkt yFxw== MIME-Version: 1.0 X-Received: by 10.112.76.230 with SMTP id n6mr8372916lbw.8.1408846457641; Sat, 23 Aug 2014 19:14:17 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sat, 23 Aug 2014 19:14:17 -0700 (PDT) In-Reply-To: References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> Date: Sat, 23 Aug 2014 19:14:17 -0700 X-Google-Sender-Auth: Ffo2XSaCYGkx2RRl92M7JR3ECEE Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: 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: Sun, 24 Aug 2014 02:14:21 -0000 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