From owner-freebsd-geom@FreeBSD.ORG Sun Jun 10 17:52:43 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25DBE16A46C; Sun, 10 Jun 2007 17:52:43 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id D0FFF13C469; Sun, 10 Jun 2007 17:52:42 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5AHqdT6035955; Sun, 10 Jun 2007 10:52:39 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5AHqdE0035954; Sun, 10 Jun 2007 10:52:39 -0700 (PDT) Date: Sun, 10 Jun 2007 10:52:39 -0700 (PDT) From: Matthew Dillon Message-Id: <200706101752.l5AHqdE0035954@apollo.backplane.com> To: Marcel Moolenaar References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 17:52:43 -0000 :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I like the mirroring approach, because I can make the label manager just treat the special MBR slice (s2) as being part of the integrated GPT spec (which it is). From the end-user's point of view he would just do something like 'gptlabel -e ad0' and one of the GPT partitions listed would be the 'boot' partition. gptlabel would recognize the special nature of the partition and automatically and silently adjust the special MBR slice (s2) to match it. I don't like the out-of-band approach... I definitely want the partitions to be within GPTs managed area, at least for newly minted disks. With the in-band approach the gpt labeling program can take care of any special compatibility cases in a fairly straightforward and controlled manner. -Matt Matthew Dillon From owner-freebsd-geom@FreeBSD.ORG Sun Jun 10 18:09:05 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C91916A469; Sun, 10 Jun 2007 18:09:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.176]) by mx1.freebsd.org (Postfix) with ESMTP id 5586F13C44B; Sun, 10 Jun 2007 18:09:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout06/MantshX 4.0) with ESMTP id l5AI92Cl023282; Sun, 10 Jun 2007 11:09:02 -0700 (PDT) Received: from [172.16.1.3] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5AI8wtZ006346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Jun 2007 11:09:00 -0700 (PDT) In-Reply-To: <200706101752.l5AHqdE0035954@apollo.backplane.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 10 Jun 2007 11:08:47 -0700 To: Matthew Dillon X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 18:09:05 -0000 On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: > :Technically speaking, the MBR can only have a single partition of > :type 0xEE that covers the whole disk. This is to protect the GPT > :from MBR-specific tools that do not know about the GPT. This is > :not a bootable slice by definition. > : > :Practice is different. To support bootcamp on Intel-based Macs, > :the MBR will have real partitions that mirror GPT partitions or > :otherwise describe partitions outside the GPT controlled area. > :These can be bootable partitions and the protective partition > :(the one with type 0xEE) will not cover the whole disk anymore. > : > :The nasty part is keeping MBR and GPT partitions in sync, so it > :may be better to have the MBR partition fall outside the GPT > :controlled area. This can be done because the GPT header contains > :the LBA of the first and last sectors on the disk that can be > :assigned to a partition. You can free up space for MBR partitions > :after the primary GPT table by adjusting the first LBA. In the > :MBR partition you can put a GPT aware boot loader that uses the > :GPT to find the real partitions... > : > :-- > :Marcel Moolenaar > > In the bootcamp approach, is the GPT (0xEE) slice the first slice, > and the bootcamp slice the second slice? I'm assuming it is. Do > they mirror a GPT partition or do they use the uncontrolled area > approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Sun Jun 10 20:57:04 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE18216A41F; Sun, 10 Jun 2007 20:57:04 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 59A0D13C46E; Sun, 10 Jun 2007 20:57:04 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 26A43690A7A; Sun, 10 Jun 2007 21:33:08 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id DBA80690B56; Sun, 10 Jun 2007 21:33:07 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-125-90.net.novis.pt [87.196.125.90]) by core.fnop.net (Postfix) with ESMTP id 0B934690A7A; Sun, 10 Jun 2007 21:33:07 +0100 (WEST) Date: Sun, 10 Jun 2007 21:35:47 +0100 Message-ID: <861wgjwnrw.wl%rpaulo@fnop.net> From: Rui Paulo To: Marcel Moolenaar In-Reply-To: <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org, Matthew Dillon , freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 20:57:04 -0000 At Sun, 10 Jun 2007 11:08:47 -0700, Marcel Moolenaar wrote: > > > On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: > > > :Technically speaking, the MBR can only have a single partition of > > :type 0xEE that covers the whole disk. This is to protect the GPT > > :from MBR-specific tools that do not know about the GPT. This is > > :not a bootable slice by definition. > > : > > :Practice is different. To support bootcamp on Intel-based Macs, > > :the MBR will have real partitions that mirror GPT partitions or > > :otherwise describe partitions outside the GPT controlled area. > > :These can be bootable partitions and the protective partition > > :(the one with type 0xEE) will not cover the whole disk anymore. > > : > > :The nasty part is keeping MBR and GPT partitions in sync, so it > > :may be better to have the MBR partition fall outside the GPT > > :controlled area. This can be done because the GPT header contains > > :the LBA of the first and last sectors on the disk that can be > > :assigned to a partition. You can free up space for MBR partitions > > :after the primary GPT table by adjusting the first LBA. In the > > :MBR partition you can put a GPT aware boot loader that uses the > > :GPT to find the real partitions... > > : > > :-- > > :Marcel Moolenaar > > > > In the bootcamp approach, is the GPT (0xEE) slice the first slice, > > and the bootcamp slice the second slice? I'm assuming it is. Do > > they mirror a GPT partition or do they use the uncontrolled area > > approach? > > I seem to recall that the 0xEE partition is not the first, but rather > the second or third. It would make sense, because it has no function > other than to have the disk appear used. Bootcamp uses the mirroring > approach. No. The first partition is the EFI GPT (0xee): % fdisk -1 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 40, size 409600 (200 Meg), flag 0 beg: cyl 0/ head 0/ sector 41; end: cyl 406/ head 6/ sector 14 % gpt -r show ad0 gpt show: ad0: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - EFI System 409640 41943040 2 GPT part - Apple HFS 42352680 74857527 3 GPT part - FreeBSD UFS/UFS2 117210207 32 Sec GPT table 117210239 1 Sec GPT header -- Rui Paulo From owner-freebsd-geom@FreeBSD.ORG Sun Jun 10 21:43:34 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C08A16A400; Sun, 10 Jun 2007 21:43:34 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id DDC7B13C480; Sun, 10 Jun 2007 21:43:33 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5ALhQ7L038341; Sun, 10 Jun 2007 14:43:29 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5ALhQut038340; Sun, 10 Jun 2007 14:43:26 -0700 (PDT) Date: Sun, 10 Jun 2007 14:43:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200706102143.l5ALhQut038340@apollo.backplane.com> To: Rui Paulo References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar , Ivan Voras , freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 21:43:34 -0000 :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :******* Working on device /dev/ad0 ******* :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) : start 40, size 409600 (200 Meg), flag 0 : beg: cyl 0/ head 0/ sector 41; : end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). -Matt From owner-freebsd-geom@FreeBSD.ORG Sun Jun 10 22:14:03 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1526A16A41F; Sun, 10 Jun 2007 22:14:03 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 7A41813C4BD; Sun, 10 Jun 2007 22:14:02 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id C8CF3690A7A; Sun, 10 Jun 2007 23:11:19 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 949BD690AE9; Sun, 10 Jun 2007 23:11:19 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-125-90.net.novis.pt [87.196.125.90]) by core.fnop.net (Postfix) with ESMTP id EFEC2690A7A; Sun, 10 Jun 2007 23:11:18 +0100 (WEST) Date: Sun, 10 Jun 2007 23:13:59 +0100 Message-ID: <86zm37v4ns.wl%rpaulo@fnop.net> From: Rui Paulo To: Matthew Dillon In-Reply-To: <200706102143.l5ALhQut038340@apollo.backplane.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 22:14:03 -0000 At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: > > > :No. > :The first partition is the EFI GPT (0xee): > : > :% fdisk -1 > :******* Working on device /dev/ad0 ******* > :... > :parameters to be used for BIOS calculations are: > :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) > : > :Media sector size is 512 > :Warning: BIOS sector numbering starts with sector 1 > :Information from DOS bootblock is: > :The data for partition 1 is: > :sysid 238 (0xee),(EFI GPT) > : start 40, size 409600 (200 Meg), flag 0 > : beg: cyl 0/ head 0/ sector 41; > : end: cyl 406/ head 6/ sector 14 > > I think I have it mostly figured out, but the 'start 40' in your > output can't be right. The intel documentation says that the > starting LBA in a PMBR record must be set to 1 by definition > (table 11-7 in the 1.10 documentation). I don't know why Apple does that. -- Rui Paulo From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 03:01:26 2007 Return-Path: X-Original-To: freebsd-geom@hub.freebsd.org Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D540E16A400; Mon, 11 Jun 2007 03:01:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id A85B013C484; Mon, 11 Jun 2007 03:01:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5B31QQ7076364; Mon, 11 Jun 2007 03:01:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5B31QvV076360; Mon, 11 Jun 2007 03:01:26 GMT (envelope-from linimon) Date: Mon, 11 Jun 2007 03:01:26 GMT From: Mark Linimon Message-Id: <200706110301.l5B31QvV076360@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org Cc: Subject: Re: misc/113543: [geom] [patch] geom(8) utilities don't work inside the Fixit livefs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 03:01:26 -0000 Old Synopsis: geom(8) utilities don't work inside the Fixit livefs New Synopsis: [geom] [patch] geom(8) utilities don't work inside the Fixit livefs Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 11 03:00:34 UTC 2007 Responsible-Changed-Why: patch for src/release/fixit.profile. http://www.freebsd.org/cgi/query-pr.cgi?pr=113543 From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 11:08:38 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF42A16A46B for ; Mon, 11 Jun 2007 11:08:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id CE6E913C4C5 for ; Mon, 11 Jun 2007 11:08:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5BB8cYt026599 for ; Mon, 11 Jun 2007 11:08:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5BB8bS3026595 for freebsd-geom@FreeBSD.org; Mon, 11 Jun 2007 11:08:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jun 2007 11:08:37 GMT Message-Id: <200706111108.l5BB8bS3026595@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 11:08:39 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/89102 geom [geom_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o misc/113543 geom [geom] [patch] geom(8) utilities don't work inside the 12 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for f kern/105390 geom [geli] filesystem on a md backed by sparse file with s o kern/107707 geom [geom] [patch] add new class geom_xbox360 to slice up p bin/110705 geom gmirror control utility does not exit with correct exi 6 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 19:53:01 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64CDB16A46F; Mon, 11 Jun 2007 19:53:01 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id E125E13C45D; Mon, 11 Jun 2007 19:53:00 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 05515690A7A; Mon, 11 Jun 2007 20:50:13 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id C56FF690AC5; Mon, 11 Jun 2007 20:50:12 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-57-209.net.novis.pt [87.196.57.209]) by core.fnop.net (Postfix) with ESMTP id 14DFC690A7A; Mon, 11 Jun 2007 20:50:11 +0100 (WEST) Date: Mon, 11 Jun 2007 20:52:54 +0100 Message-ID: <86lkeqxo89.wl%rpaulo@fnop.net> From: Rui Paulo To: Chuck Swiger In-Reply-To: References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org, Matthew Dillon , Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:53:01 -0000 At Mon, 11 Jun 2007 12:41:18 -0700, Chuck Swiger wrote: > > Hi, all-- > > On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: > >> :Media sector size is 512 > >> :Warning: BIOS sector numbering starts with sector 1 > >> :Information from DOS bootblock is: > >> :The data for partition 1 is: > >> :sysid 238 (0xee),(EFI GPT) > >> : start 40, size 409600 (200 Meg), flag 0 > >> : beg: cyl 0/ head 0/ sector 41; > >> : end: cyl 406/ head 6/ sector 14 > >> > >> I think I have it mostly figured out, but the 'start 40' in your > >> output can't be right. The intel documentation says that the > >> starting LBA in a PMBR record must be set to 1 by definition > >> (table 11-7 in the 1.10 documentation). > > > > I don't know why Apple does that. > > The offset of 40 sectors sounds like it is pointing to the first > partition listed within the GPT? > > A typical Intel Mac system using GPT ought to look something like this: > > # fdisk /dev/rdisk0 > Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] > Signature: 0xAA55 > Starting Ending > #: id cyl hd sec - cyl hd sec [ start - size] > ------------------------------------------------------------------------ > 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] > 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused > 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused > 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused > > # gpt -r show /dev/rdisk0 > start size index contents > 0 1 PMBR > 1 1 Pri GPT header > 2 32 Pri GPT table > 34 6 > 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- > xxxxxxxxxxxx > 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- > xxxxxxxxxxxx > 159824344 262151 > 160086495 32 Sec GPT table > 160086527 1 Sec GPT header Well, what's happening is that Boot Camp syncs the BIOS partition table with the GPT table, so the first partition should start at 40, just like the GPT. Why does it start at 40 ? Because you need room for the PMBR, the Primary GPT header and the Primary GPT table. Now, you don't seem to have used Boot Camp on your Mac, right? If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. > The first, small partition is almost certainly a "boothfs" boot > partition, as described in the man page for Apple's version of > fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. -- Rui Paulo From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 19:53:44 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54B9016A41F; Mon, 11 Jun 2007 19:53:44 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id D121213C447; Mon, 11 Jun 2007 19:53:43 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id A34E3690A7A; Mon, 11 Jun 2007 20:50:56 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 710B4690AC5; Mon, 11 Jun 2007 20:50:56 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-57-209.net.novis.pt [87.196.57.209]) by core.fnop.net (Postfix) with ESMTP id EFABD690A7A; Mon, 11 Jun 2007 20:50:55 +0100 (WEST) Date: Mon, 11 Jun 2007 20:53:41 +0100 Message-ID: <86k5uaxo6y.wl%rpaulo@fnop.net> From: Rui Paulo To: Matthew Dillon In-Reply-To: <86zm37v4ns.wl%rpaulo@fnop.net> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:53:44 -0000 At Sun, 10 Jun 2007 23:13:59 +0100, Rui Paulo wrote: > > At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), > Matthew Dillon wrote: > > > > > > :No. > > :The first partition is the EFI GPT (0xee): > > : > > :% fdisk -1 > > :******* Working on device /dev/ad0 ******* > > :... > > :parameters to be used for BIOS calculations are: > > :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) > > : > > :Media sector size is 512 > > :Warning: BIOS sector numbering starts with sector 1 > > :Information from DOS bootblock is: > > :The data for partition 1 is: > > :sysid 238 (0xee),(EFI GPT) > > : start 40, size 409600 (200 Meg), flag 0 > > : beg: cyl 0/ head 0/ sector 41; > > : end: cyl 406/ head 6/ sector 14 > > > > I think I have it mostly figured out, but the 'start 40' in your > > output can't be right. The intel documentation says that the > > starting LBA in a PMBR record must be set to 1 by definition > > (table 11-7 in the 1.10 documentation). > > I don't know why Apple does that. Actually, I think I do. See my other email. Regards. -- Rui Paulo From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 19:58:04 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3718B16A47E; Mon, 11 Jun 2007 19:58:04 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 4B31813C4C7; Mon, 11 Jun 2007 19:58:02 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id B4B08888FC5; Mon, 11 Jun 2007 12:40:14 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 259E2300AC; Mon, 11 Jun 2007 12:41:19 -0700 (PDT) X-AuditID: 11807125-9ef62bb000000801-12-466da55eb1af Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id E1EAD30063; Mon, 11 Jun 2007 12:41:18 -0700 (PDT) In-Reply-To: <86zm37v4ns.wl%rpaulo@fnop.net> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Mon, 11 Jun 2007 12:41:18 -0700 To: Rui Paulo X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org, Matthew Dillon , Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:58:04 -0000 Hi, all-- On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: >> :Media sector size is 512 >> :Warning: BIOS sector numbering starts with sector 1 >> :Information from DOS bootblock is: >> :The data for partition 1 is: >> :sysid 238 (0xee),(EFI GPT) >> : start 40, size 409600 (200 Meg), flag 0 >> : beg: cyl 0/ head 0/ sector 41; >> : end: cyl 406/ head 6/ sector 14 >> >> I think I have it mostly figured out, but the 'start 40' in your >> output can't be right. The intel documentation says that the >> starting LBA in a PMBR record must be set to 1 by definition >> (table 11-7 in the 1.10 documentation). > > I don't know why Apple does that. The offset of 40 sectors sounds like it is pointing to the first partition listed within the GPT? A typical Intel Mac system using GPT ought to look something like this: # fdisk /dev/rdisk0 Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] ------------------------------------------------------------------------ 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused # gpt -r show /dev/rdisk0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- xxxxxxxxxxxx 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- xxxxxxxxxxxx 159824344 262151 160086495 32 Sec GPT table 160086527 1 Sec GPT header The first, small partition is almost certainly a "boothfs" boot partition, as described in the man page for Apple's version of fdisk: " In the default template, partition number 1 will be configured as a Dar- win boot partition spanning from cylinder 0, head 1, sector 1, and extending for 8 megabytes. Partition number 2 will be configured as a Darwin HFS partition spanning the rest of the disk. This mode is designed to initialize an MBR the very first time, or when it has been corrupted beyond repair. You can specify other default partition styles with the -a flag. The available styles are: boothfs Creates an 8Mb boot partition (type AB hex) and makes the rest of the disk a Darwin HFS partition (type AF hex). bootufs Creates an 8Mb boot partition (type AB hex) and makes the rest of the disk a Darwin UFS partition (type A8 hex). hfs Makes the entire disk one Darwin UFS partition (type A8 hex). ufs Makes the entire disk one HFS+ partition (type AF hex). dos Makes the entire disk one DOS partition (type 0C hex). raid Makes the entire disk one type AC hex partition. The -u flag is used to update the MBR code on a given drive. The MBR code extends from offset 0x000 to the start of the partition table at offset 0x1BE. It is similar to the -i flag, except the existing parti- tion table is preserved. This is useful for writing new MBR code onto an existing drive, and is equivalent to the DOS command ``FDISK / MBR''. Note that this option will overwrite the NT disk signature, if present. The -u and -i flags may not be specified together." Also cf: http://en.wikipedia.org/wiki/GUID_Partition_Table -- -Chuck From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 20:12:06 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7485216A400; Mon, 11 Jun 2007 20:12:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 531DF13C45E; Mon, 11 Jun 2007 20:12:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id B6863889BA9; Mon, 11 Jun 2007 13:11:01 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 2DFDB40080; Mon, 11 Jun 2007 13:12:06 -0700 (PDT) X-AuditID: 11807126-9e882bb00000081c-dc-466dac95833b Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id E89C240024; Mon, 11 Jun 2007 13:12:05 -0700 (PDT) In-Reply-To: <86lkeqxo89.wl%rpaulo@fnop.net> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Mon, 11 Jun 2007 13:12:04 -0700 To: Rui Paulo X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org, Matthew Dillon , Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 20:12:06 -0000 On Jun 11, 2007, at 12:52 PM, Rui Paulo wrote: >> A typical Intel Mac system using GPT ought to look something like >> this: >> >> # fdisk /dev/rdisk0 >> Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] >> Signature: 0xAA55 >> Starting Ending >> #: id cyl hd sec - cyl hd sec [ start - size] >> --------------------------------------------------------------------- >> --- >> 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] >> >> 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused >> 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused >> 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused >> >> # gpt -r show /dev/rdisk0 >> start size index contents >> 0 1 PMBR >> 1 1 Pri GPT header >> 2 32 Pri GPT table >> 34 6 >> 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- >> xxxxxxxxxxxx >> 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- >> xxxxxxxxxxxx >> 159824344 262151 >> 160086495 32 Sec GPT table >> 160086527 1 Sec GPT header > > Well, what's happening is that Boot Camp syncs the BIOS partition > table with the GPT table, so the first partition should start at 40, > just like the GPT. > > Why does it start at 40 ? Because you need room for the PMBR, the > Primary GPT header and the Primary GPT table. Agreed, you need about 32 sectors for the GPT header+table. > Now, you don't seem to have used Boot Camp on your Mac, right? It's true that the machine in question has never used BootCamp, correct. > If you ever use it, fdisk /dev/rdisk0 will show things differently. > The first partition with id 0xEE will should start at LBA 40 and end > at LBA 409640. OK: although that surprises me a bit, perhaps trying to get Windows XP (which may not understand the ~32 sector GPT header+table) means that claiming the first partition in the MBR starts at 40 works better...? >> The first, small partition is almost certainly a "boothfs" boot >> partition, as described in the man page for Apple's version of >> fdisk: > > I don't think so. > The boothfs partition doesn't seem to be used on Intel Macs no > longer. The EFI boot loader that comes with Intel Macs can read HFS+ > without any help (actually it's an EFI module), so bootufs/boothfs > partitions are no longer required. It looks like you're right-- the OS-X formatting utilities still reserve space for the boot partition, but they just scribble enough to this space to indicate that the partition isn't actually bootable: # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C 00000000 eb 58 90 42 53 44 20 20 34 2e 34 00 02 01 20 00 |.X.BSD 4.4... .| 00000010 02 00 00 00 00 f0 00 00 00 00 00 00 28 00 00 00 |............(...| 00000020 00 40 06 00 67 0c 00 00 00 00 00 00 02 00 00 00 |.@..g...........| 00000030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 29 f4 11 60 28 45 46 49 20 20 20 20 20 20 |..)..` (EFI | 00000050 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1....| 00000060 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|......^.......| 00000070 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t.......0....| 00000080 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non- system di| 00000090 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 | sk..Press any ke| 000000a0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.....| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 | RRaA............| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000003e0 00 00 00 00 72 72 41 61 ff ff ff ff ff ff ff ff |....rrAa........| 000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000c00 eb 58 90 42 53 44 20 20 34 2e 34 00 02 01 20 00 |.X.BSD 4.4... .| 00000c10 02 00 00 00 00 f0 00 00 00 00 00 00 28 00 00 00 |............(...| 00000c20 00 40 06 00 67 0c 00 00 00 00 00 00 02 00 00 00 |.@..g...........| 00000c30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000c40 00 00 29 f4 11 60 28 45 46 49 20 20 20 20 20 20 |..)..` (EFI | 00000c50 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1....| 00000c60 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|......^.......| 00000c70 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t.......0....| 00000c80 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non- system di| 00000c90 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 | sk..Press any ke| 00000ca0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.....| 00000cb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000e00 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 | RRaA............| 00000e10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000fe0 00 00 00 00 72 72 41 61 ff ff ff ff ff ff ff ff |....rrAa........| 00000ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004000 f0 ff ff 0f ff ff ff 0f ff ff ff 0f 00 00 00 00 |................| 00004010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00190e00 f0 ff ff 0f ff ff ff 0f ff ff ff 0f 00 00 00 00 |................| 00190e10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 0031dc00 45 46 49 20 20 20 20 20 20 20 20 08 00 00 00 00 | EFI .....| 0031dc10 00 00 00 00 00 00 1b a7 85 35 00 00 00 00 00 00 |......... 5......| 0031dc20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 409600+0 records in 409600+0 records out -- -Chuck From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 20:33:48 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1684516A4A7; Mon, 11 Jun 2007 20:33:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id C538A13C4C4; Mon, 11 Jun 2007 20:33:47 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5BKXgiJ052684; Mon, 11 Jun 2007 13:33:42 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5BKXgNf052683; Mon, 11 Jun 2007 13:33:42 -0700 (PDT) Date: Mon, 11 Jun 2007 13:33:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200706112033.l5BKXgNf052683@apollo.backplane.com> To: Chuck Swiger References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> Cc: Rui Paulo , freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 20:33:48 -0000 :>> # gpt -r show /dev/rdisk0 :>> start size index contents :>> 0 1 PMBR :>> 1 1 Pri GPT header :>> 2 32 Pri GPT table :>> 34 6 :>> 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- :>> xxxxxxxxxxxx :>> 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- :>> xxxxxxxxxxxx :... :> Well, what's happening is that Boot Camp syncs the BIOS partition :> table with the GPT table, so the first partition should start at 40, :> just like the GPT. :> :> Why does it start at 40 ? Because you need room for the PMBR, the :> Primary GPT header and the Primary GPT table. : :Agreed, you need about 32 sectors for the GPT header+table. It makes sense for them to point the first MBR slice at the first partition in the GPT, even though the standard says something else. It really sounds like they are making an accomodation for BIOS booting or older Windows booting... or *something* of that sort. The fact that the bootability bit is not set in the MBR (I'm not sure about that, is it set or not?)... that seems to imply a compatibility issue with other OS's like Windows in a multi-boot environment. They are just doing it all with a single slice instead of having two slices. I'll bet they found that the two-slice method doesn't work in some cases and the one-slice method does. The standard document doesn't allow either method but it does seem to be a bit less insistent on the starting sector for slice 1 then it does on there only being one slice in the MBR, period. I can also see some OS's / disk managers barfing on having two slices which overlap each other. So it really does make sense for them to point the MBR at sector 40. The more I think about it, the more sense it makes. -Matt Matthew Dillon From owner-freebsd-geom@FreeBSD.ORG Tue Jun 12 10:57:59 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4A6B16A468; Tue, 12 Jun 2007 10:57:59 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 6A61A13C489; Tue, 12 Jun 2007 10:57:59 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id F0ABE690A85; Tue, 12 Jun 2007 11:55:07 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id BD626690AC5; Tue, 12 Jun 2007 11:55:07 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-89-95.net.novis.pt [87.196.89.95]) by core.fnop.net (Postfix) with ESMTP id 31ACE690A85; Tue, 12 Jun 2007 11:55:07 +0100 (WEST) Date: Tue, 12 Jun 2007 11:57:55 +0100 Message-ID: <86ir9txwwc.wl%rpaulo@fnop.net> From: Rui Paulo To: Chuck Swiger In-Reply-To: References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org, Matthew Dillon , Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 10:58:00 -0000 At Mon, 11 Jun 2007 13:12:04 -0700, Chuck Swiger wrote: > > If you ever use it, fdisk /dev/rdisk0 will show things differently. > > The first partition with id 0xEE will should start at LBA 40 and end > > at LBA 409640. > > OK: although that surprises me a bit, perhaps trying to get Windows > XP (which may not understand the ~32 sector GPT header+table) means > that claiming the first partition in the MBR starts at 40 works > better...? Well, yes. I think it's like a safe keeping issue so that the user doesn't overwrite the GPT info. > > >> The first, small partition is almost certainly a "boothfs" boot > >> partition, as described in the man page for Apple's version of > >> fdisk: > > > > I don't think so. > > The boothfs partition doesn't seem to be used on Intel Macs no > > longer. The EFI boot loader that comes with Intel Macs can read HFS+ > > without any help (actually it's an EFI module), so bootufs/boothfs > > partitions are no longer required. > > It looks like you're right-- the OS-X formatting utilities still > reserve space for the boot partition, but they just scribble enough > to this space to indicate that the partition isn't actually bootable: > > # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C Yes, this partition is just FAT32 without anything in it. -- Rui Paulo From owner-freebsd-geom@FreeBSD.ORG Tue Jun 12 11:20:57 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB7E116A469 for ; Tue, 12 Jun 2007 11:20:57 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6CF13C45D for ; Tue, 12 Jun 2007 11:20:57 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hy4Qd-0003nJ-80 for freebsd-geom@freebsd.org; Tue, 12 Jun 2007 13:20:51 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jun 2007 13:20:51 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jun 2007 13:20:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 12 Jun 2007 13:20:32 +0200 Lines: 49 Message-ID: <466E8180.6090600@fer.hr> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> <200706112033.l5BKXgNf052683@apollo.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig289831A78775945CD87CD84A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <200706112033.l5BKXgNf052683@apollo.backplane.com> X-Enigmail-Version: 0.94.2.0 Sender: news Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 11:20:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig289831A78775945CD87CD84A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Matthew Dillon wrote: > It really sounds like they are making an accomodation for BIOS > booting or older Windows booting... or *something* of that sort. T= he > fact that the bootability bit is not set in the MBR (I'm not sure a= bout > that, is it set or not?)... that seems to imply a compatibility iss= ue The spec forbids bootable flag in the "protective MBR" > with other OS's like Windows in a multi-boot environment. >=20 > They are just doing it all with a single slice instead of having > two slices. This is "more" conformant to the spec, which says the protective MBR=20 should have only one partition which covers the whole disk. I think that we can get away with > 1 fdisk slices which mirror the=20 first four GPT partitions on non-EFI machines. This would probably mean modifying the gpt utility and module to mirror=20 the EFI partitions in the PMBR, controlled by a flag so that real EFI=20 machines don't get choked. --------------enig289831A78775945CD87CD84A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGboGKldnAQVacBcgRAlVrAJ0bZTsfRe+3Ydmbi4dsJMt4man6twCeP6OD wC1nzizf5G95YgR8pkwj7wY= =9nnm -----END PGP SIGNATURE----- --------------enig289831A78775945CD87CD84A-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 12 12:43:43 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12B5416A400; Tue, 12 Jun 2007 12:43:43 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF9F13C483; Tue, 12 Jun 2007 12:43:42 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 7182B690A85; Tue, 12 Jun 2007 13:40:51 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 26084690AE0; Tue, 12 Jun 2007 13:40:51 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-89-95.net.novis.pt [87.196.89.95]) by core.fnop.net (Postfix) with ESMTP id 2388A690A85; Tue, 12 Jun 2007 13:40:50 +0100 (WEST) Date: Tue, 12 Jun 2007 13:43:37 +0100 Message-ID: <86ejkhcphi.wl%rpaulo@fnop.net> From: Rui Paulo To: Matthew Dillon In-Reply-To: <200706112033.l5BKXgNf052683@apollo.backplane.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> <200706112033.l5BKXgNf052683@apollo.backplane.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Chuck Swiger , Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 12:43:43 -0000 At Mon, 11 Jun 2007 13:33:42 -0700 (PDT), Matthew Dillon wrote: > > > :>> # gpt -r show /dev/rdisk0 > :>> start size index contents > :>> 0 1 PMBR > :>> 1 1 Pri GPT header > :>> 2 32 Pri GPT table > :>> 34 6 > :>> 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- > :>> xxxxxxxxxxxx > :>> 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- > :>> xxxxxxxxxxxx > :... > :> Well, what's happening is that Boot Camp syncs the BIOS partition > :> table with the GPT table, so the first partition should start at 40, > :> just like the GPT. > :> > :> Why does it start at 40 ? Because you need room for the PMBR, the > :> Primary GPT header and the Primary GPT table. > : > :Agreed, you need about 32 sectors for the GPT header+table. > > It makes sense for them to point the first MBR slice at the first > partition in the GPT, even though the standard says something else. > > It really sounds like they are making an accomodation for BIOS > booting or older Windows booting... or *something* of that sort. The > fact that the bootability bit is not set in the MBR (I'm not sure about > that, is it set or not?)... that seems to imply a compatibility issue > with other OS's like Windows in a multi-boot environment. > > They are just doing it all with a single slice instead of having > two slices. > > I'll bet they found that the two-slice method doesn't work in some > cases and the one-slice method does. The standard document doesn't > allow either method but it does seem to be a bit less insistent on > the starting sector for slice 1 then it does on there only being > one slice in the MBR, period. I can also see some OS's / disk managers > barfing on having two slices which overlap each other. > > So it really does make sense for them to point the MBR at sector 40. > The more I think about it, the more sense it makes. And also, if they used two partitions that would mean you would only have one partition left for installing Windows. -- Rui Paulo From owner-freebsd-geom@FreeBSD.ORG Sat Jun 16 20:08:50 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56CAF16A468 for ; Sat, 16 Jun 2007 20:08:50 +0000 (UTC) (envelope-from gianrubio@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 1967D13C46A for ; Sat, 16 Jun 2007 20:08:50 +0000 (UTC) (envelope-from gianrubio@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so1016217nzn for ; Sat, 16 Jun 2007 13:08:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rvKzfQJ9/CzgID5MP3NJorxLAyl1HMH9j3nlEr2tCYIqlLsP8+da0dqf9KZHj0XOITIQGurZhGk0+bI8a+bLaIoPn36wz0ZU1ymTBBTK+AAoRc9aBxal0o+vPSMw+0Qn/4CykqV6seNOae23VVdG4H+adaartv0/5kKRhpuelLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Z8d8Aif+1hVXIbpbaLYJK5IZdFbZvRRnZTG3uUdaFuiojwpNEvOdNbkrgSkILIhorCSqPMTpi/ZfbYf71dDvWQ+ZkXasRDnGbPHbnnw9c4FACW1xCUmpDjNTrWPEGANsUkNUfNaxXKjjelwybTf6jLPq1HOeaWNmvdKa9WkT7vA= Received: by 10.142.106.18 with SMTP id e18mr222044wfc.1182024529303; Sat, 16 Jun 2007 13:08:49 -0700 (PDT) Received: by 10.143.16.12 with HTTP; Sat, 16 Jun 2007 13:08:49 -0700 (PDT) Message-ID: Date: Sat, 16 Jun 2007 17:08:49 -0300 From: "Giancarlo Rubio" To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Gvinum X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 20:08:50 -0000 Hi all I'm using raid 5 with 3 400gb disks, via gvinum. Disks ad4: 381553MB at ata2-master SATA150 ad6: 381554MB at ata3-master SATA150 ad7: 381554MB at ata3-slave SATA150 When i listing the raid via gvinum show servidor# gvinum gvinum -> list 3 drives: D raid53 State: up /dev/ad7s1a A: 0/381553 MB (0%) D raid52 State: up /dev/ad6s1a A: 0/381553 MB (0%) D raid51 State: up /dev/ad4s1a A: 0/381552 MB (0%) 1 volume: V data State: up Plexes: 1 Size: 745 GB 1 plex: P data.p0 R5 State: up Subdisks: 3 Size: 745 GB 3 subdisks: S data.p0.s2 State: up D: raid53 Size: 372 GB S data.p0.s1 State: up D: raid52 Size: 372 GB S data.p0.s0 State: up D: raid51 Size: 372 GB gvinum -> But when i list via df show this servidor# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 496M 55M 401M 12% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1e 496M 14K 456M 0% /tmp /dev/ad0s1f 69G 2.0G 61G 3% /usr /dev/ad0s1d 1.4G 79M 1.2G 6% /var /dev/gvinum/data 722G 722G -58G 109% /home Why this difference are showing?? And why the avail is negative number?? -- Giancarlo Rubio "Linux is for people who hate Windows, BSD is for people who love UNIX" 100% Rwindow$-Free Freebsd-BR User #88