From owner-freebsd-geom@FreeBSD.ORG Sun Mar 7 11:11:02 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5CB6106564A for ; Sun, 7 Mar 2010 11:11:02 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 088B08FC25 for ; Sun, 7 Mar 2010 11:11:01 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18013; Sun, 07 Mar 2010 13:10:58 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NoENu-000MaD-EU; Sun, 07 Mar 2010 13:10:58 +0200 Message-ID: <4B9389C1.9000102@icyb.net.ua> Date: Sun, 07 Mar 2010 13:10:57 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, Marcel Moolenaar X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: another gpt vs mbr (sanity) check 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, 07 Mar 2010 11:11:02 -0000 Please consider the following scenario: - GPT scheme is used on a disk - the disk changes hands - the disk is repartitioned with MBR without explicitly wiping out any of old data and thus GPT - GPT data survives undamaged So now we have the valid GPT but it points to wrong offsets and we have the valid and correct MBR. Currently FreeBSD would pick GPT scheme over MBR scheme when presented which such a disk. I think that this is incorrect. I believe that our code should check if MBR is indeed a protective MBR when deciding whether to use GPT. Below is a simplistic patch that adds such a check. Ideally it should probably check the whole MBR partition table instead of just a type of the first entry. What do you think? --- a/sys/geom/part/g_part_gpt.c +++ b/sys/geom/part/g_part_gpt.c @@ -568,7 +568,7 @@ g_part_gpt_probe { struct g_provider *pp; char *buf; - int error, res; + int error, res, typ; /* We don't nest, which means that our depth should be 0. */ if (table->gpt_depth != 0) @@ -598,10 +598,12 @@ g_part_gpt_probe if (buf == NULL) return (error); res = le16dec(buf + DOSMAGICOFFSET); + typ = *(unsigned char*)(buf + DOSPARTOFF + 0 * DOSPARTSIZE + 4); g_free(buf); if (res != DOSMAGIC) return (ENXIO); - + if (typ != DOSPTYP_PMBR) + return (ENXIO); /* Check that there's a primary header. */ buf = g_read_data(cp, pp->sectorsize, pp->sectorsize, &error); if (buf == NULL) -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sun Mar 7 19:13:23 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 294C4106566B for ; Sun, 7 Mar 2010 19:13:23 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1427D8FC08 for ; Sun, 7 Mar 2010 19:13:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYX00MZREQ3EP30@asmtp030.mac.com> for freebsd-geom@freebsd.org; Sun, 07 Mar 2010 11:13:16 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003070165 From: Marcel Moolenaar In-reply-to: <4B9389C1.9000102@icyb.net.ua> Date: Sun, 07 Mar 2010 11:13:14 -0800 Message-id: References: <4B9389C1.9000102@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 07 Mar 2010 19:13:23 -0000 On Mar 7, 2010, at 3:10 AM, Andriy Gapon wrote: > > Please consider the following scenario: > - GPT scheme is used on a disk > - the disk changes hands > - the disk is repartitioned with MBR without explicitly wiping out any of old > data and thus GPT > - GPT data survives undamaged > > So now we have the valid GPT but it points to wrong offsets and we have the > valid and correct MBR. > Currently FreeBSD would pick GPT scheme over MBR scheme when presented which > such a disk. I think that this is incorrect. Sorry. That ship has sailed. Originally GEOM_GPT at the time checked for the protective MBR before accepting the GPT. This was changed to support Apple setups. There's no turning back now. People just need to learn to wipe out old partitioning information before writing select sectors in order to create a new one. This, BTW, is exactly why gpart was designed the way it was. It makes sure that you properly clean all the meta-data of the old scheme before new meta-data is written. Legacy tools like fdisk and bsdlabel only write their meta-data without any consideration of the possible existence of meta-data corresponding to other schemes. Now that I think of it, it wouldn't necessarily be a bad feature to extend gpart with a verb, like "wipe", that calls G_PART_DESTROY() for all the schemes it knows about and then erases all the sectors in the sector map, wiping out any and all meta-data that gpart could ever interpret (with the caveat that this is limited to the schemes the kernel knows about at the time). -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Sun Mar 7 19:36:01 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC880106564A for ; Sun, 7 Mar 2010 19:36:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 735938FC08 for ; Sun, 7 Mar 2010 19:35:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA22985; Sun, 07 Mar 2010 21:35:54 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NoMGX-000NOS-RG; Sun, 07 Mar 2010 21:35:53 +0200 Message-ID: <4B940018.5050809@icyb.net.ua> Date: Sun, 07 Mar 2010 21:35:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B9389C1.9000102@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 07 Mar 2010 19:36:01 -0000 on 07/03/2010 21:13 Marcel Moolenaar said the following: > On Mar 7, 2010, at 3:10 AM, Andriy Gapon wrote: > > >> Please consider the following scenario: >> - GPT scheme is used on a disk >> - the disk changes hands >> - the disk is repartitioned with MBR without explicitly wiping out any of old >> data and thus GPT >> - GPT data survives undamaged >> >> So now we have the valid GPT but it points to wrong offsets and we have the >> valid and correct MBR. >> Currently FreeBSD would pick GPT scheme over MBR scheme when presented which >> such a disk. I think that this is incorrect. > > Sorry. That ship has sailed. Originally GEOM_GPT at the time checked > for the protective MBR before accepting the GPT. This was changed to > support Apple setups. There's no turning back now. People just need > to learn to wipe out old partitioning information before writing > select sectors in order to create a new one. Hmm, I probably wasn't there when the ship was sailing out :) What is the 'Apple setup'? Is it a some sort of a hybrid scheme? Don't they still use a protective type for the first partition in MBR? Can we perhaps have the best of all words and do some smart autodetection? Or, at least, have some manual lever to control such things? When a friend gives me his SDHC card to copy some files out of it, he wouldn't want me to perform some non-readonly magic with it and he wouldn't bother to listen my explanations because the card works nice for him with Windows. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sun Mar 7 23:31:47 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D58E1106564A for ; Sun, 7 Mar 2010 23:31:47 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id BE4E28FC0C for ; Sun, 7 Mar 2010 23:31:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYX00D7PQOJ2080@asmtp026.mac.com> for freebsd-geom@freebsd.org; Sun, 07 Mar 2010 15:31:32 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003070226 From: Marcel Moolenaar In-reply-to: <4B940018.5050809@icyb.net.ua> Date: Sun, 07 Mar 2010 15:31:30 -0800 Message-id: <530847A8-D9F7-4A9F-9578-6A9282688EC1@mac.com> References: <4B9389C1.9000102@icyb.net.ua> <4B940018.5050809@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 07 Mar 2010 23:31:47 -0000 On Mar 7, 2010, at 11:35 AM, Andriy Gapon wrote: > on 07/03/2010 21:13 Marcel Moolenaar said the following: >> On Mar 7, 2010, at 3:10 AM, Andriy Gapon wrote: >> >> >>> Please consider the following scenario: >>> - GPT scheme is used on a disk >>> - the disk changes hands >>> - the disk is repartitioned with MBR without explicitly wiping out any of old >>> data and thus GPT >>> - GPT data survives undamaged >>> >>> So now we have the valid GPT but it points to wrong offsets and we have the >>> valid and correct MBR. >>> Currently FreeBSD would pick GPT scheme over MBR scheme when presented which >>> such a disk. I think that this is incorrect. >> >> Sorry. That ship has sailed. Originally GEOM_GPT at the time checked >> for the protective MBR before accepting the GPT. This was changed to >> support Apple setups. There's no turning back now. People just need >> to learn to wipe out old partitioning information before writing >> select sectors in order to create a new one. > > Hmm, I probably wasn't there when the ship was sailing out :) > What is the 'Apple setup'? Is it a some sort of a hybrid scheme? Don't they > still use a protective type for the first partition in MBR? It's a hybrid setup. I can't recall if there's a slice of type 0xEE or not in all cases, but we stopped checking for that... > Can we perhaps have the best of all words and do some smart autodetection? > Or, at least, have some manual lever to control such things? The best of all worlds doesn't exist anymore. It was how it was designed to be and not how it's used at this time. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 07:18:55 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 180301065674; Mon, 8 Mar 2010 07:18:55 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E32938FC15; Mon, 8 Mar 2010 07:18:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o287Isv5046424; Mon, 8 Mar 2010 07:18:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o287Is8B046420; Mon, 8 Mar 2010 07:18:54 GMT (envelope-from linimon) Date: Mon, 8 Mar 2010 07:18:54 GMT Message-Id: <201003080718.o287Is8B046420@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/144521: geom(1) tool parsing non-subclass command broken 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, 08 Mar 2010 07:18:55 -0000 Synopsis: geom(1) tool parsing non-subclass command broken Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 8 07:18:07 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144521 From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 08:43:18 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405AD106564A for ; Mon, 8 Mar 2010 08:43:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 81DBE8FC18 for ; Mon, 8 Mar 2010 08:43:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA29659; Mon, 08 Mar 2010 10:43:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NoYYT-00007J-37; Mon, 08 Mar 2010 10:43:13 +0200 Message-ID: <4B94B8A0.4090806@icyb.net.ua> Date: Mon, 08 Mar 2010 10:43:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B9389C1.9000102@icyb.net.ua> <4B940018.5050809@icyb.net.ua> <530847A8-D9F7-4A9F-9578-6A9282688EC1@mac.com> In-Reply-To: <530847A8-D9F7-4A9F-9578-6A9282688EC1@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 08:43:18 -0000 on 08/03/2010 01:31 Marcel Moolenaar said the following: > > The best of all worlds doesn't exist anymore. It was how it > was designed to be and not how it's used at this time. So, I guess it is carved in stone and there is no point in trying to discuss it. I'll keep the patch for myself, then. P.S. Both Windows 7 and OpenSuSE 11.2 handled the disk in question properly from my point of view, as an MBR disk, only FreeBSD considered it a GPT one. I have no access to MacOS. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 11:06:57 2010 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB3E4106567B for ; Mon, 8 Mar 2010 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B89D48FC1A for ; Mon, 8 Mar 2010 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o28B6vdE073690 for ; Mon, 8 Mar 2010 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o28B6vwC073688 for freebsd-geom@FreeBSD.org; Mon, 8 Mar 2010 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Mar 2010 11:06:57 GMT Message-Id: <201003081106.o28B6vwC073688@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 freebsd-geom@FreeBSD.org 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, 08 Mar 2010 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/144521 geom geom(1) tool parsing non-subclass command broken o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool f kern/142365 geom [geom] FreeBSD RAID1 (gmirror) is much slower than Lin o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/139847 geom [geom_mbr] [patch] load/unload causes system to hang o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used f kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 52 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 17:38:49 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C7F106564A for ; Mon, 8 Mar 2010 17:38:49 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3018FC0C for ; Mon, 8 Mar 2010 17:38:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ00EX950MFQ10@asmtp023.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 09:38:48 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080141 From: Marcel Moolenaar In-reply-to: <4B94B8A0.4090806@icyb.net.ua> Date: Mon, 08 Mar 2010 09:38:46 -0800 Message-id: <761C8533-B1DC-4DC7-8B2E-9CB1A8A5BEF8@mac.com> References: <4B9389C1.9000102@icyb.net.ua> <4B940018.5050809@icyb.net.ua> <530847A8-D9F7-4A9F-9578-6A9282688EC1@mac.com> <4B94B8A0.4090806@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 17:38:49 -0000 On Mar 8, 2010, at 12:43 AM, Andriy Gapon wrote: > on 08/03/2010 01:31 Marcel Moolenaar said the following: >> >> The best of all worlds doesn't exist anymore. It was how it >> was designed to be and not how it's used at this time. > > So, I guess it is carved in stone and there is no point in trying to discuss it. > I'll keep the patch for myself, then. I wouldn't call it carved in stone, but I am definitely slamming the door closed on first attempt. The reason for this is that to me this is a rehash of something that has gotten a bit of thought, whereas for the person suggesting the change it's most likely just an impulse. If you can find a way that does not violate the "GPT aware OSes should use the GPT" rule, you'll definitely be listened to. To clarify: the protective MBR is there only to protect the GPT disk from tools that do not understand the GPT. Any GPT-aware tool will treat the disk as a GPT disk. Consequently: the MBR is inferior to the GPT... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 17:48:39 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 376EC1065675 for ; Mon, 8 Mar 2010 17:48:39 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 012008FC08 for ; Mon, 8 Mar 2010 17:48:38 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Noh4B-0004I2-6n; Mon, 08 Mar 2010 17:48:31 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Noh4B-000JjD-5u; Mon, 08 Mar 2010 17:48:31 +0000 Date: Mon, 08 Mar 2010 17:48:31 +0000 Message-Id: To: avg@icyb.net.ua, xcllnt@mac.com In-Reply-To: <761C8533-B1DC-4DC7-8B2E-9CB1A8A5BEF8@mac.com> From: Pete French Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 17:48:39 -0000 > To clarify: the protective MBR is there only to protect the GPT > disk from tools that do not understand the GPT. Any GPT-aware > tool will treat the disk as a GPT disk. Consequently: the MBR > is inferior to the GPT... The queston is then, why isn't Windows treating it as GPT ? It's all very nice in theory, but if the practical upshot is that we get flash media which will read perfectly well in all operating systems except for BSD then thats not a good result, even if it is theoretically correct. Which is the situation the original poster appeared to have. -pete. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 17:55:42 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 386AF106566B for ; Mon, 8 Mar 2010 17:55:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 229C18FC20 for ; Mon, 8 Mar 2010 17:55:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ001V25SJCX30@asmtp027.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 09:55:35 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080146 From: Marcel Moolenaar In-reply-to: Date: Mon, 08 Mar 2010 09:55:31 -0800 Message-id: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> References: To: Pete French X-Mailer: Apple Mail (2.1077) Cc: avg@icyb.net.ua, freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 17:55:42 -0000 On Mar 8, 2010, at 9:48 AM, Pete French wrote: >> To clarify: the protective MBR is there only to protect the GPT >> disk from tools that do not understand the GPT. Any GPT-aware >> tool will treat the disk as a GPT disk. Consequently: the MBR >> is inferior to the GPT... > > The queston is then, why isn't Windows treating it as GPT ? Ask Microsoft. So far I've only seen violations to the spec. At least Apple kept to the spirit of it... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:35:26 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3F6106564A for ; Mon, 8 Mar 2010 18:35:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3B17E8FC08 for ; Mon, 8 Mar 2010 18:35:25 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA09259; Mon, 08 Mar 2010 20:35:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NohnT-0000dY-Op; Mon, 08 Mar 2010 20:35:19 +0200 Message-ID: <4B954367.3070804@icyb.net.ua> Date: Mon, 08 Mar 2010 20:35:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> In-Reply-To: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:35:27 -0000 on 08/03/2010 19:55 Marcel Moolenaar said the following: > On Mar 8, 2010, at 9:48 AM, Pete French wrote: > >>> To clarify: the protective MBR is there only to protect the GPT >>> disk from tools that do not understand the GPT. Any GPT-aware >>> tool will treat the disk as a GPT disk. Consequently: the MBR >>> is inferior to the GPT... >> The queston is then, why isn't Windows treating it as GPT ? > > Ask Microsoft. So far I've only seen violations to the spec. At > least Apple kept to the spirit of it... According to my understanding it's the opposite as much as I hate saying this. My understanding is that valid GPT scheme _must_ provide only a protective MBR, i.e. MBR where there is only partition and it is of type 0xEE. That is, any "hybrid MBR" is not a valid GPT scheme. Google turns up a lot of stuff on this topic. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:37:22 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D26106564A for ; Mon, 8 Mar 2010 18:37:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id E0BD48FC17 for ; Mon, 8 Mar 2010 18:37:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ00MU87PI8090@asmtp027.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 10:37:03 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080155 From: Marcel Moolenaar In-reply-to: <4B954367.3070804@icyb.net.ua> Date: Mon, 08 Mar 2010 10:36:54 -0800 Message-id: References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:37:22 -0000 On Mar 8, 2010, at 10:35 AM, Andriy Gapon wrote: > on 08/03/2010 19:55 Marcel Moolenaar said the following: >> On Mar 8, 2010, at 9:48 AM, Pete French wrote: >> >>>> To clarify: the protective MBR is there only to protect the GPT >>>> disk from tools that do not understand the GPT. Any GPT-aware >>>> tool will treat the disk as a GPT disk. Consequently: the MBR >>>> is inferior to the GPT... >>> The queston is then, why isn't Windows treating it as GPT ? >> >> Ask Microsoft. So far I've only seen violations to the spec. At >> least Apple kept to the spirit of it... > > According to my understanding it's the opposite as much as I hate saying this. > My understanding is that valid GPT scheme _must_ provide only a protective MBR, > i.e. MBR where there is only partition and it is of type 0xEE. > That is, any "hybrid MBR" is not a valid GPT scheme. > Google turns up a lot of stuff on this topic. Exactly. That is exactly the violation of the spec I was referring to. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:38:14 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036E8106564A for ; Mon, 8 Mar 2010 18:38:14 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by mx1.freebsd.org (Postfix) with ESMTP id BCB258FC17 for ; Mon, 8 Mar 2010 18:38:13 +0000 (UTC) Received: by iwn37 with SMTP id 37so383584iwn.27 for ; Mon, 08 Mar 2010 10:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UMI92idmDTWZSKdQMfD8rMRweOOxgr1FQQuAMXNUry0=; b=kBFu0/8yI1wTXVLD+P+uvWuHEh5w2GiFPbS1PAUI/24DFcILUbQWuAplvbCom5CB9b Fba2LeCpSnxHHbwrVzBwOAj/A67JgSDajMNDHpLfZjXwb3zBWA5CnpTMvQwdkoGDgqdF IXu4iZXJwATyT/G/G5tZ2tXKZA0gXla4tuiRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xsbvt35H9gn0CmRDHErR0AK8we5HnupqlIZW/RWwTT4noh3owRBbc5b4UssSEdzMhD e8pK22cI1IV+UnI2lMCGkc6Ueq1z6EoEz2rFa55wKSjss84MWtYPPpcMrvmr/+yWg5WX m1HaWzhdKT8EC+QAN7I1B29b6ATKMPuET+1Gw= MIME-Version: 1.0 Received: by 10.231.159.207 with SMTP id k15mr52133ibx.75.1268073492994; Mon, 08 Mar 2010 10:38:12 -0800 (PST) In-Reply-To: <790a9fff1003081016q2b6a7d93qa55055aaaa9cf74@mail.gmail.com> References: <761C8533-B1DC-4DC7-8B2E-9CB1A8A5BEF8@mac.com> <790a9fff1003081016q2b6a7d93qa55055aaaa9cf74@mail.gmail.com> Date: Mon, 8 Mar 2010 12:38:12 -0600 Message-ID: <790a9fff1003081038o317816dl9d5a274b63528df6@mail.gmail.com> From: Scot Hetzel To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xcllnt@mac.com, avg@icyb.net.ua, freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:38:14 -0000 On Mon, Mar 8, 2010 at 12:16 PM, Scot Hetzel wrote: > On Mon, Mar 8, 2010 at 11:48 AM, Pete French > wrote: >>> To clarify: the protective MBR is there only to protect the GPT >>> disk from tools that do not understand the GPT. Any GPT-aware >>> tool will treat the disk as a GPT disk. Consequently: the MBR >>> is inferior to the GPT... >> >> The queston is then, why isn't Windows treating it as GPT ? It's > > I have both MBR and GPT formated drives installed in my laptop, and > Windows 7 correctly identifies both drives. =A0The GPT drive was > formated using FreeBSD 8. > >> all very nice in theory, but if the practical upshot is that >> we get flash media which will read perfectly well in all operating >> systems except for BSD then thats not a good result, even if it >> is theoretically correct. Which is the situation the original poster >> appeared to have. >> > > The problem the original poster was having is this: > > Format drive as GPT > Re-Format drive as MBR > > FreeBSD still sees the drive as GPT instead of MBR. > > The reason is that FreeBSD is still detecting the Seconday GPT which > is located at the end of the disk, and using it due to the Primary GPT > was lost/corrupted when the drive was reformated as MBR disk. > > The real question is how was the drive reformated. =A0If it was > reformated using gpart: > > - Delete all existing partitions: > gpart delete -i X adY > - Destroy the GPT formated drive > gpart destroy adY > - Create the MBR formated drive > gpart create -s mbr adY > > And the secondary GPT header still exists, then it is a FreeBSD bug. I just had a look at the code for sys/geom/part/{g_part.c, g_part_gpt.c} and it does show that we delete the secondary GPT header when destroying a GPT formated drive. > But if it was reformated using a different tool, then it is a bug in > that tool for not reconizing that the original disk was formated as > GPT. > > Scot > From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:39:22 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C0A1065676 for ; Mon, 8 Mar 2010 18:39:22 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFC18FC1A for ; Mon, 8 Mar 2010 18:39:21 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA09314; Mon, 08 Mar 2010 20:39:16 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NohrH-0000e3-Ul; Mon, 08 Mar 2010 20:39:16 +0200 Message-ID: <4B954453.1020404@icyb.net.ua> Date: Mon, 08 Mar 2010 20:39:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Scot Hetzel References: <761C8533-B1DC-4DC7-8B2E-9CB1A8A5BEF8@mac.com> <790a9fff1003081016q2b6a7d93qa55055aaaa9cf74@mail.gmail.com> In-Reply-To: <790a9fff1003081016q2b6a7d93qa55055aaaa9cf74@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xcllnt@mac.com, Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:39:22 -0000 on 08/03/2010 20:16 Scot Hetzel said the following: > On Mon, Mar 8, 2010 at 11:48 AM, Pete French > wrote: >>> To clarify: the protective MBR is there only to protect the GPT >>> disk from tools that do not understand the GPT. Any GPT-aware >>> tool will treat the disk as a GPT disk. Consequently: the MBR >>> is inferior to the GPT... >> The queston is then, why isn't Windows treating it as GPT ? It's > > I have both MBR and GPT formated drives installed in my laptop, and > Windows 7 correctly identifies both drives. The GPT drive was > formated using FreeBSD 8. > >> all very nice in theory, but if the practical upshot is that >> we get flash media which will read perfectly well in all operating >> systems except for BSD then thats not a good result, even if it >> is theoretically correct. Which is the situation the original poster >> appeared to have. >> > > The problem the original poster was having is this: > > Format drive as GPT > Re-Format drive as MBR > > FreeBSD still sees the drive as GPT instead of MBR. > > The reason is that FreeBSD is still detecting the Seconday GPT which > is located at the end of the disk, and using it due to the Primary GPT > was lost/corrupted when the drive was reformated as MBR disk. Not exactly true - primary GPT (in sector 1) was also intact. Typical MBR formatting reserves sectors 1-62, but doesn't actually put anything there. > The real question is how was the drive reformated. If it was > reformated using gpart: > > - Delete all existing partitions: > gpart delete -i X adY > - Destroy the GPT formated drive > gpart destroy adY > - Create the MBR formated drive > gpart create -s mbr adY > > And the secondary GPT header still exists, then it is a FreeBSD bug. > But if it was reformated using a different tool, then it is a bug in > that tool for not reconizing that the original disk was formated as > GPT. It was formatted either with GPT-unaware tool, which is not a deadly sin (or a bug), or with a tool that simply ignored anything already on the disk by design. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:41:02 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85CA106566C for ; Mon, 8 Mar 2010 18:41:02 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by mx1.freebsd.org (Postfix) with ESMTP id 90B118FC17 for ; Mon, 8 Mar 2010 18:41:02 +0000 (UTC) Received: by iwn37 with SMTP id 37so386426iwn.27 for ; Mon, 08 Mar 2010 10:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AFt5isUbk6o7ziADcQ/Ohv1EUlTLxuVrTlbqx0Izqrc=; b=o34sdK0uwUU8WmSp8ZOYTUWu7rrLERoqKtvJ1CGDAZ16dLCRKTqPoLfBSo/NXNTvsH t+cG8d2XUnALXPWPV6R09i6B1fn3XBzwEwJ7Wh4G28pl5P5H5fyX5b0PZTEpnAVF6Kj1 mqbSYyCyPFsvJe78j77KMAXroN7HieIeNMZ88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=djWoq3bIahaJUV2gsezVPyMb70w/rDPMFoxG4WHCyAHhXr9dHVW8ohrfG0EBh7P8Fo XfPzjrc07LJaMy6FZLkJLiYtE4gcTq1IxVWx4lskaOsDXKSCwxq8VMfYRfyeRIuFk7Ck u8aN6aDWnCOsYDLDlHv41Zf13GA+vlDd2ABcU= MIME-Version: 1.0 Received: by 10.231.148.18 with SMTP id n18mr143867ibv.7.1268072210567; Mon, 08 Mar 2010 10:16:50 -0800 (PST) In-Reply-To: References: <761C8533-B1DC-4DC7-8B2E-9CB1A8A5BEF8@mac.com> Date: Mon, 8 Mar 2010 12:16:50 -0600 Message-ID: <790a9fff1003081016q2b6a7d93qa55055aaaa9cf74@mail.gmail.com> From: Scot Hetzel To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Cc: xcllnt@mac.com, avg@icyb.net.ua, freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:41:02 -0000 On Mon, Mar 8, 2010 at 11:48 AM, Pete French wrote: >> To clarify: the protective MBR is there only to protect the GPT >> disk from tools that do not understand the GPT. Any GPT-aware >> tool will treat the disk as a GPT disk. Consequently: the MBR >> is inferior to the GPT... > > The queston is then, why isn't Windows treating it as GPT ? It's I have both MBR and GPT formated drives installed in my laptop, and Windows 7 correctly identifies both drives. The GPT drive was formated using FreeBSD 8. > all very nice in theory, but if the practical upshot is that > we get flash media which will read perfectly well in all operating > systems except for BSD then thats not a good result, even if it > is theoretically correct. Which is the situation the original poster > appeared to have. > The problem the original poster was having is this: Format drive as GPT Re-Format drive as MBR FreeBSD still sees the drive as GPT instead of MBR. The reason is that FreeBSD is still detecting the Seconday GPT which is located at the end of the disk, and using it due to the Primary GPT was lost/corrupted when the drive was reformated as MBR disk. The real question is how was the drive reformated. If it was reformated using gpart: - Delete all existing partitions: gpart delete -i X adY - Destroy the GPT formated drive gpart destroy adY - Create the MBR formated drive gpart create -s mbr adY And the secondary GPT header still exists, then it is a FreeBSD bug. But if it was reformated using a different tool, then it is a bug in that tool for not reconizing that the original disk was formated as GPT. Scot From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:41:05 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 186B71065675 for ; Mon, 8 Mar 2010 18:41:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 57D238FC31 for ; Mon, 8 Mar 2010 18:41:03 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA09352; Mon, 08 Mar 2010 20:40:52 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Nohsp-0000eJ-TI; Mon, 08 Mar 2010 20:40:51 +0200 Message-ID: <4B9544B3.80203@icyb.net.ua> Date: Mon, 08 Mar 2010 20:40:51 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:41:05 -0000 on 08/03/2010 20:36 Marcel Moolenaar said the following: > On Mar 8, 2010, at 10:35 AM, Andriy Gapon wrote: > >> on 08/03/2010 19:55 Marcel Moolenaar said the following: >>> On Mar 8, 2010, at 9:48 AM, Pete French wrote: >>>> The queston is then, why isn't Windows treating it as GPT ? >>> Ask Microsoft. So far I've only seen violations to the spec. At >>> least Apple kept to the spirit of it... >> According to my understanding it's the opposite as much as I hate saying this. >> My understanding is that valid GPT scheme _must_ provide only a protective MBR, >> i.e. MBR where there is only partition and it is of type 0xEE. >> That is, any "hybrid MBR" is not a valid GPT scheme. >> Google turns up a lot of stuff on this topic. > > Exactly. That is exactly the violation of the spec I was referring > to. I am not which part of what I said you meant by 'that'. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 18:52:36 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936961065679 for ; Mon, 8 Mar 2010 18:52:36 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3278FC24 for ; Mon, 8 Mar 2010 18:52:36 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Noi3w-000BJv-2l; Mon, 08 Mar 2010 18:52:20 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Noi3w-0000mC-1g; Mon, 08 Mar 2010 18:52:20 +0000 Date: Mon, 08 Mar 2010 18:52:20 +0000 Message-Id: To: swhetzel@gmail.com In-Reply-To: <790a9fff1003081016q2b6a7d93qa55055aaaa9cf74@mail.gmail.com> From: Pete French Cc: xcllnt@mac.com, avg@icyb.net.ua, freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 18:52:36 -0000 > The problem the original poster was having is this: > > Format drive as GPT > Re-Format drive as MBR > > FreeBSD still sees the drive as GPT instead of MBR. Actually his *problem* is that FreeBSD sees the drive a GPT, but other things now see it as MBR. If everything saw it the same way there would be no issue, regardless of what the spec says. But if eveyone sees it one way and we see it another, thats not very useful, even if it is strictly correct and all the others are wrong. -pete. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 20:24:01 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C98106564A for ; Mon, 8 Mar 2010 20:24:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 38F0F8FC1C for ; Mon, 8 Mar 2010 20:24:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ00BUCCNUBK20@asmtp029.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 12:23:55 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080175 From: Marcel Moolenaar In-reply-to: <4B9544B3.80203@icyb.net.ua> Date: Mon, 08 Mar 2010 12:23:52 -0800 Message-id: <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 20:24:01 -0000 On Mar 8, 2010, at 10:40 AM, Andriy Gapon wrote: > on 08/03/2010 20:36 Marcel Moolenaar said the following: >> On Mar 8, 2010, at 10:35 AM, Andriy Gapon wrote: >> >>> on 08/03/2010 19:55 Marcel Moolenaar said the following: >>>> On Mar 8, 2010, at 9:48 AM, Pete French wrote: >>>>> The queston is then, why isn't Windows treating it as GPT ? >>>> Ask Microsoft. So far I've only seen violations to the spec. At >>>> least Apple kept to the spirit of it... >>> According to my understanding it's the opposite as much as I hate saying this. >>> My understanding is that valid GPT scheme _must_ provide only a protective MBR, >>> i.e. MBR where there is only partition and it is of type 0xEE. >>> That is, any "hybrid MBR" is not a valid GPT scheme. >>> Google turns up a lot of stuff on this topic. >> >> Exactly. That is exactly the violation of the spec I was referring >> to. > > I am not which part of what I said you meant by 'that'. All of it. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 20:26:52 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B5E106564A for ; Mon, 8 Mar 2010 20:26:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 4E3978FC0C for ; Mon, 8 Mar 2010 20:26:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ005HBCS3BL20@asmtp024.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 12:26:29 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080176 From: Marcel Moolenaar In-reply-to: Date: Mon, 08 Mar 2010 12:26:27 -0800 Message-id: <9556ADEF-E6B3-4235-9F17-B7CB5B249BA1@mac.com> References: To: Pete French X-Mailer: Apple Mail (2.1077) Cc: swhetzel@gmail.com, avg@icyb.net.ua, freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 20:26:52 -0000 On Mar 8, 2010, at 10:52 AM, Pete French wrote: >> The problem the original poster was having is this: >> >> Format drive as GPT >> Re-Format drive as MBR >> >> FreeBSD still sees the drive as GPT instead of MBR. > > Actually his *problem* is that FreeBSD sees the drive > a GPT, but other things now see it as MBR. If everything > saw it the same way there would be no issue, regardless > of what the spec says. But if eveyone sees it one way > and we see it another, thats not very useful, even if > it is strictly correct and all the others are wrong. We're already trying to play nice with mainstream OSes. We've simply reached the point where things ain't simple anymore and we need to be very careful not to break our own operating system. Remember that the PC world has only known about MBR and whatever people have been doing for 30 years suddenly isn't enough anymore because there's such a thing as GPT. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 20:59:39 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34AF81065673 for ; Mon, 8 Mar 2010 20:59:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1108FC12 for ; Mon, 8 Mar 2010 20:59:37 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA11005; Mon, 08 Mar 2010 22:59:33 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Nok32-0000oz-O4; Mon, 08 Mar 2010 22:59:32 +0200 Message-ID: <4B956533.2010900@icyb.net.ua> Date: Mon, 08 Mar 2010 22:59:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> In-Reply-To: <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 20:59:39 -0000 on 08/03/2010 22:23 Marcel Moolenaar said the following: > On Mar 8, 2010, at 10:40 AM, Andriy Gapon wrote: > >> on 08/03/2010 20:36 Marcel Moolenaar said the following: >>> On Mar 8, 2010, at 10:35 AM, Andriy Gapon wrote: >>> >>>> on 08/03/2010 19:55 Marcel Moolenaar said the following: >>>>> On Mar 8, 2010, at 9:48 AM, Pete French wrote: >>>>>> The queston is then, why isn't Windows treating it as GPT ? >>>>> Ask Microsoft. So far I've only seen violations to the spec. At >>>>> least Apple kept to the spirit of it... >>>> According to my understanding it's the opposite as much as I hate saying this. >>>> My understanding is that valid GPT scheme _must_ provide only a protective MBR, >>>> i.e. MBR where there is only partition and it is of type 0xEE. >>>> That is, any "hybrid MBR" is not a valid GPT scheme. >>>> Google turns up a lot of stuff on this topic. >>> Exactly. That is exactly the violation of the spec I was referring >>> to. >> I am not which part of what I said you meant by 'that'. > > All of it. This hasn't added any clarity. So I'll just post one link about what position Apple had (note the past tense) about protective MBR: http://developer.apple.com/mac/library/technotes/tn2006/tn2166.html#SECPROTECTIVEMBR -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 22:52:55 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D61D3106566C for ; Mon, 8 Mar 2010 22:52:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id BC6758FC28 for ; Mon, 8 Mar 2010 22:52:55 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ00152JK6MM40@asmtp023.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 14:52:55 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080209 From: Marcel Moolenaar In-reply-to: <4B956533.2010900@icyb.net.ua> Date: Mon, 08 Mar 2010 14:52:54 -0800 Message-id: References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> <4B956533.2010900@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 22:52:55 -0000 On Mar 8, 2010, at 12:59 PM, Andriy Gapon wrote: > on 08/03/2010 22:23 Marcel Moolenaar said the following: >> On Mar 8, 2010, at 10:40 AM, Andriy Gapon wrote: >> >>> on 08/03/2010 20:36 Marcel Moolenaar said the following: >>>> On Mar 8, 2010, at 10:35 AM, Andriy Gapon wrote: >>>> >>>>> on 08/03/2010 19:55 Marcel Moolenaar said the following: >>>>>> On Mar 8, 2010, at 9:48 AM, Pete French wrote: >>>>>>> The queston is then, why isn't Windows treating it as GPT ? >>>>>> Ask Microsoft. So far I've only seen violations to the spec. At >>>>>> least Apple kept to the spirit of it... >>>>> According to my understanding it's the opposite as much as I hate saying this. >>>>> My understanding is that valid GPT scheme _must_ provide only a protective MBR, >>>>> i.e. MBR where there is only partition and it is of type 0xEE. >>>>> That is, any "hybrid MBR" is not a valid GPT scheme. >>>>> Google turns up a lot of stuff on this topic. >>>> Exactly. That is exactly the violation of the spec I was referring >>>> to. >>> I am not which part of what I said you meant by 'that'. >> >> All of it. > This hasn't added any clarity. > > So I'll just post one link about what position Apple had (note the past tense) > about protective MBR: > http://developer.apple.com/mac/library/technotes/tn2006/tn2166.html#SECPROTECTIVEMBR The document describes theory, but does not seem to describe reality: Revision 1.39: download - view: text, markup, annotated - select for diffs Mon Jun 26 00:32:54 2006 UTC (3 years, 8 months ago) by sobomax Branches: MAIN Diff to: previous 1.38: preferred, colored Changes since revision 1.38: +24 -5 lines Improve check for protective MBR. Instead of assiming that protective MBR should have only one entry of type 0xEE, consider protective MBR to be one, that has at least one entry of type 0xEE covering the whole unit. This makes GEOM_GPT compatible with disks partitioned by the Apple's BootCamp. Approved in principle by: marcel MFC After: 1 month In short, Apple bootcamp creates an invalid PMBR according to their own technote. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 23:02:51 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27E5E106566C for ; Mon, 8 Mar 2010 23:02:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 658328FC08 for ; Mon, 8 Mar 2010 23:02:49 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA12591; Tue, 09 Mar 2010 01:02:41 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NolyC-0000zI-UF; Tue, 09 Mar 2010 01:02:41 +0200 Message-ID: <4B958210.70108@icyb.net.ua> Date: Tue, 09 Mar 2010 01:02:40 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> <4B956533.2010900@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 23:02:51 -0000 on 09/03/2010 00:52 Marcel Moolenaar said the following: > On Mar 8, 2010, at 12:59 PM, Andriy Gapon wrote: >> So I'll just post one link about what position Apple had (note the past tense) >> about protective MBR: >> http://developer.apple.com/mac/library/technotes/tn2006/tn2166.html#SECPROTECTIVEMBR > > The document describes theory, but does not seem to describe > reality: Right, that's why I emphasized the past tense. Thank you for the details. > Revision 1.39: download - view: text, markup, annotated - select for diffs > Mon Jun 26 00:32:54 2006 UTC (3 years, 8 months ago) by sobomax > Branches: MAIN > Diff to: previous 1.38: preferred, colored > Changes since revision 1.38: +24 -5 lines > Improve check for protective MBR. Instead of assiming that protective > MBR should have only one entry of type 0xEE, consider protective MBR > to be one, that has at least one entry of type 0xEE covering the whole > unit. This makes GEOM_GPT compatible with disks partitioned by the > Apple's BootCamp. > > Approved in principle by: marcel > MFC After: 1 month > > > In short, Apple bootcamp creates an invalid PMBR according to their > own technote. > > FYI, It's not only the technote, it's the GPT spec itself. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 8 23:21:27 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E531065673 for ; Mon, 8 Mar 2010 23:21:27 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 989FF8FC19 for ; Mon, 8 Mar 2010 23:21:27 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYZ00FRJKVPEH00@asmtp027.mac.com> for freebsd-geom@freebsd.org; Mon, 08 Mar 2010 15:21:27 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003080214 From: Marcel Moolenaar In-reply-to: <4B958210.70108@icyb.net.ua> Date: Mon, 08 Mar 2010 15:21:25 -0800 Message-id: <252BDE43-6021-486A-B4BD-E003F4B07B1A@mac.com> References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> <4B956533.2010900@icyb.net.ua> <4B958210.70108@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 08 Mar 2010 23:21:27 -0000 On Mar 8, 2010, at 3:02 PM, Andriy Gapon wrote: >> >> In short, Apple bootcamp creates an invalid PMBR according to their >> own technote. > > It's not only the technote, it's the GPT spec itself. Actually, no. The spec clearly states that LBA 0 contains a protective MBR for the GPT format (UEFI 2.0, paragraph 5.3.1 on page 90). Paragraph 5.2 just the background information so that there's something to refer to... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue Mar 9 08:26:28 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CD74106567C for ; Tue, 9 Mar 2010 08:26:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8B09E8FC1C for ; Tue, 9 Mar 2010 08:26:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA19672; Tue, 09 Mar 2010 10:26:22 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Noulh-0003lC-Jc; Tue, 09 Mar 2010 10:26:21 +0200 Message-ID: <4B960629.8060208@icyb.net.ua> Date: Tue, 09 Mar 2010 10:26:17 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Marcel Moolenaar References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> <4B956533.2010900@icyb.net.ua> <4B958210.70108@icyb.net.ua> <252BDE43-6021-486A-B4BD-E003F4B07B1A@mac.com> In-Reply-To: <252BDE43-6021-486A-B4BD-E003F4B07B1A@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 09 Mar 2010 08:26:28 -0000 on 09/03/2010 01:21 Marcel Moolenaar said the following: > On Mar 8, 2010, at 3:02 PM, Andriy Gapon wrote: >>> In short, Apple bootcamp creates an invalid PMBR according to their >>> own technote. >> It's not only the technote, it's the GPT spec itself. > > Actually, no. The spec clearly states that LBA 0 contains a > protective MBR for the GPT format (UEFI 2.0, paragraph 5.3.1 > on page 90). Paragraph 5.2 just the background information so > that there's something to refer to... > Isn't this what I said? And paragraph 5.2.3 clearly states what constitutes a protective MBR (as opposed to legacy MBR). I am looking at Version 2.3 Errata B. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Tue Mar 9 18:13:30 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 267FD106566C for ; Tue, 9 Mar 2010 18:13:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0ADE98FC17 for ; Tue, 9 Mar 2010 18:13:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZ1008C619WMR80@asmtp023.mac.com> for freebsd-geom@freebsd.org; Tue, 09 Mar 2010 10:13:16 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003090158 From: Marcel Moolenaar In-reply-to: <4B960629.8060208@icyb.net.ua> Date: Tue, 09 Mar 2010 10:13:08 -0800 Message-id: <30AA11FC-5E7E-4B0B-BD21-358A74DAD860@mac.com> References: <3158041B-8E00-4A87-8172-741C0AE57131@mac.com> <4B954367.3070804@icyb.net.ua> <4B9544B3.80203@icyb.net.ua> <03BFAAEC-6C59-48EF-BED9-2E68ED03E2B6@mac.com> <4B956533.2010900@icyb.net.ua> <4B958210.70108@icyb.net.ua> <252BDE43-6021-486A-B4BD-E003F4B07B1A@mac.com> <4B960629.8060208@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: Pete French , freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check 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, 09 Mar 2010 18:13:30 -0000 On Mar 9, 2010, at 12:26 AM, Andriy Gapon wrote: > on 09/03/2010 01:21 Marcel Moolenaar said the following: >> On Mar 8, 2010, at 3:02 PM, Andriy Gapon wrote: >>>> In short, Apple bootcamp creates an invalid PMBR according to their >>>> own technote. >>> It's not only the technote, it's the GPT spec itself. >> >> Actually, no. The spec clearly states that LBA 0 contains a >> protective MBR for the GPT format (UEFI 2.0, paragraph 5.3.1 >> on page 90). Paragraph 5.2 just the background information so >> that there's something to refer to... >> > > Isn't this what I said? Sorry, yes. I got confused, because I already stated that it wasn't according to the spec. In a sense, I crossed that bridge and then found myself back at it again :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue Mar 9 21:37:09 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E0BD1065675; Tue, 9 Mar 2010 21:37:09 +0000 (UTC) (envelope-from eduardo.orige@gmail.com) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by mx1.freebsd.org (Postfix) with ESMTP id 17F288FC13; Tue, 9 Mar 2010 21:37:08 +0000 (UTC) Received: by qyk14 with SMTP id 14so2580937qyk.9 for ; Tue, 09 Mar 2010 13:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer; bh=Z6wakAK9qDFdwXsaYyCb45exPGXnnUkvVAdKmCETLSA=; b=pDbZBYH0PuiR4/u9SiQY72hBOVrKOQkurWUCYB0HcM4DFMGffBbvPOtPDPcVuXCFJf FkYtuo/MyHm9wKsnnGjVr3fLVEbtpoLwf4r2MS4RNXbhcQbkUEqQvrEckoDkgw/t1T4f 1Fl2Fx8HCQrbv9djXPz5ciz2NNnGtKXdxgntA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=baxLrZsLqh6AiN+EdRXWN/VD6IaurngFOa7Oag3npDNA9TjDCYxriqC9yeaojkm42k zWd11FUFI9ElxjcTY7TcCOzhtZv9L5c/01RTr/eDPKuXht7ZTW281tMjavMW0nKo2ukt R8Oi3qJOKvFODIu3G+DXwTo0BreOX0kiXbAvs= Received: by 10.224.50.202 with SMTP id a10mr355526qag.260.1268168771368; Tue, 09 Mar 2010 13:06:11 -0800 (PST) Received: from [10.1.1.25] ([200.138.241.170]) by mx.google.com with ESMTPS id 7sm8923123qwf.37.2010.03.09.13.06.08 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 13:06:10 -0800 (PST) From: Eduardo Orige To: freebsd-geom@FreeBSD.org, freebsd-bugs@FreeBSD.org Content-Type: multipart/mixed; boundary="=-W+4MJSLfaZBX5YPKqNjS" Date: Tue, 09 Mar 2010 18:06:06 -0300 Message-ID: <1268168766.2178.31.camel@eduardo-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Cc: Subject: Problem with GEOM 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, 09 Mar 2010 21:37:09 -0000 --=-W+4MJSLfaZBX5YPKqNjS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, I have a problem with GEOM and gmirror. The error that the server showed me was: #gmirror list or gmirror status #gmirror: Cannot get GEOM tree: Unknown error: -1 I did this mirror with the follow commands: gmirror label -v gm0 ad4 gmirror load gmirror insert gm0 ad6 gmirror configure -a gm0 My /etc/fstab is attached. The version of my system is 7.2 stable/amd64. I opened a call in forum and the answer of my question was a probaly bug. The link of this qustion is: http://forums.freebsd.org/showthread.php?t=12119 I have a link of a bug and I need to know if my problem also is a bug. The bug that seems like my bug is: http://www.freebsd.org/cgi/query-pr.cgi?pr=104389&cat=kern Regards, Orige. Eduardo Orige , Brazil --=-W+4MJSLfaZBX5YPKqNjS Content-Disposition: attachment; filename="fstab" Content-Type: text/plain; name="fstab"; charset="UTF-8" Content-Transfer-Encoding: 7bit # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1e /tmp ufs rw 2 2 /dev/mirror/gm0s1f /usr ufs rw 2 2 /dev/mirror/gm0s1d /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 --=-W+4MJSLfaZBX5YPKqNjS-- From owner-freebsd-geom@FreeBSD.ORG Wed Mar 10 11:29:11 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3721065670 for ; Wed, 10 Mar 2010 11:29:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E38F18FC15 for ; Wed, 10 Mar 2010 11:29:10 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA12070; Wed, 10 Mar 2010 13:29:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NpK68-0007q9-Mw; Wed, 10 Mar 2010 13:29:08 +0200 Message-ID: <4B978284.5070202@icyb.net.ua> Date: Wed, 10 Mar 2010 13:29:08 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4B9389C1.9000102@icyb.net.ua> In-Reply-To: <4B9389C1.9000102@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar Subject: Re: another gpt vs mbr (sanity) check 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: Wed, 10 Mar 2010 11:29:11 -0000 on 07/03/2010 13:10 Andriy Gapon said the following: > > Below is a simplistic patch that adds such a check. > Ideally it should probably check the whole MBR partition table instead of just a > type of the first entry. For what it's worth, here is a new version of the patch. In this version g_part_gpt recognizes MBR as a valid protective/hybrid MBR if _any_ of the partitions in MBR partition table has type 0xEE (GPT protective partition). --- a/sys/geom/part/g_part_gpt.c +++ b/sys/geom/part/g_part_gpt.c @@ -568,7 +568,8 @@ g_part_gpt_probe { struct g_provider *pp; char *buf; - int error, res; + int error, res, typ; + int i, has_pmbr; /* We don't nest, which means that our depth should be 0. */ if (table->gpt_depth != 0) @@ -598,10 +599,18 @@ g_part_gpt_probe if (buf == NULL) return (error); res = le16dec(buf + DOSMAGICOFFSET); + for (has_pmbr = 0, i = 0; i < NDOSPART; i++) { + typ = *(unsigned char*)(buf + DOSPARTOFF + i * DOSPARTSIZE + 4); + if (typ == DOSPTYP_PMBR) { + has_pmbr = 1; + break; + } + } g_free(buf); if (res != DOSMAGIC) return (ENXIO); - + if (!has_pmbr) + return (ENXIO); /* Check that there's a primary header. */ buf = g_read_data(cp, pp->sectorsize, pp->sectorsize, &error); if (buf == NULL) -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Mar 11 15:40:03 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60025106564A for ; Thu, 11 Mar 2010 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32EED8FC1E for ; Thu, 11 Mar 2010 15:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2BFe3kq033070 for ; Thu, 11 Mar 2010 15:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2BFe35v033069; Thu, 11 Mar 2010 15:40:03 GMT (envelope-from gnats) Date: Thu, 11 Mar 2010 15:40:03 GMT Message-Id: <201003111540.o2BFe35v033069@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: kern/104389: [geom] [patch] sys/geom/geom_dump.c doesn't encode XML entities X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 15:40:03 -0000 The following reply was made to PR kern/104389; it has been noted by GNATS. From: Jaakko Heinonen To: bug-followup@FreeBSD.org Cc: dzs-pr@dzs.fx.org Subject: Re: kern/104389: [geom] [patch] sys/geom/geom_dump.c doesn't encode XML entities Date: Thu, 11 Mar 2010 17:31:50 +0200 Hi, I have updated Doug's patch to use a sbuf instead of allocating the buffer by hand. %%% Index: sys/geom/geom_dump.c =================================================================== --- sys/geom/geom_dump.c (revision 204950) +++ sys/geom/geom_dump.c (working copy) @@ -154,6 +154,29 @@ g_conftxt(void *p, int flag) static void +g_conf_print_encoded(struct sbuf *sb, const char *fmt, const char *str) +{ + struct sbuf *s; + const u_char *c; + + s = sbuf_new_auto(); + + for (c = str; *c != '\0'; c++) { + if (*c == '&' || *c == '<' || *c == '>' || + *c == '\'' || *c == '"' || *c > 0x7e) + sbuf_printf(s, "&#x%X;", *c); + else if (*c == '\t' || *c == '\n' || *c == '\r' || *c > 0x1f) + sbuf_putc(s, *c); + else + sbuf_putc(s, '?'); + } + + sbuf_finish(s); + sbuf_printf(sb, fmt, sbuf_data(s)); + sbuf_delete(s); +} + +static void g_conf_consumer(struct sbuf *sb, struct g_consumer *cp) { @@ -181,7 +204,7 @@ g_conf_provider(struct sbuf *sb, struct sbuf_printf(sb, "\t \n", pp->geom); sbuf_printf(sb, "\t r%dw%de%d\n", pp->acr, pp->acw, pp->ace); - sbuf_printf(sb, "\t %s\n", pp->name); + g_conf_print_encoded(sb, "\t %s\n", pp->name); sbuf_printf(sb, "\t %jd\n", (intmax_t)pp->mediasize); sbuf_printf(sb, "\t %u\n", pp->sectorsize); @@ -208,7 +231,7 @@ g_conf_geom(struct sbuf *sb, struct g_ge sbuf_printf(sb, " \n", gp); sbuf_printf(sb, " \n", gp->class); - sbuf_printf(sb, " %s\n", gp->name); + g_conf_print_encoded(sb, " %s\n", gp->name); sbuf_printf(sb, " %d\n", gp->rank); if (gp->flags & G_GEOM_WITHER) sbuf_printf(sb, " \n"); @@ -237,7 +260,7 @@ g_conf_class(struct sbuf *sb, struct g_c struct g_geom *gp2; sbuf_printf(sb, " \n", mp); - sbuf_printf(sb, " %s\n", mp->name); + g_conf_print_encoded(sb, " %s\n", mp->name); LIST_FOREACH(gp2, &mp->geom, geom) { if (gp != NULL && gp != gp2) continue; %%% From owner-freebsd-geom@FreeBSD.ORG Fri Mar 12 07:41:23 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210731065670; Fri, 12 Mar 2010 07:41:23 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ECCDD8FC08; Fri, 12 Mar 2010 07:41:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2C7fM77091303; Fri, 12 Mar 2010 07:41:22 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2C7fMgG091299; Fri, 12 Mar 2010 07:41:22 GMT (envelope-from jh) Date: Fri, 12 Mar 2010 07:41:22 GMT Message-Id: <201003120741.o2C7fMgG091299@freefall.freebsd.org> To: ayochum@pair.com, jh@FreeBSD.org, freebsd-geom@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/113957: [gmirror] gmirror is intermittently reporting a degraded mirror array upon reboot. 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: Fri, 12 Mar 2010 07:41:23 -0000 Synopsis: [gmirror] gmirror is intermittently reporting a degraded mirror array upon reboot. State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Mar 12 07:41:22 UTC 2010 State-Changed-Why: Note that submitter has been asked for feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=113957 From owner-freebsd-geom@FreeBSD.ORG Fri Mar 12 08:49:44 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31C641065673 for ; Fri, 12 Mar 2010 08:49:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id 665978FC14 for ; Fri, 12 Mar 2010 08:49:43 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward13.mail.yandex.net (Yandex) with ESMTP id BD488A79A3E; Fri, 12 Mar 2010 11:35:13 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1268382913; bh=MAnbGZBqFUz9PPgoYXDS7MZWoMfyWvDsBd9JIJ1o/qk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=SSyC4NqzqhuMldNRVWuNJu/+2elcHj7PxCgf6KLv32AOhcKdlnqAXDLWeKz+xTuPT yKeErdlwDBDfPAcNXzDR+pCSNk73YZEjVnCDHxSdw9pun+kPqtk4KZKleb4XRTjMTL fWvP8hIrGkIpKYXTFMZ/xHea1h+Ic6ASnNbcdZPE= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 00FE3D30161; Fri, 12 Mar 2010 11:35:11 +0300 (MSK) Message-ID: <4B99FCBF.3000503@yandex.ru> Date: Fri, 12 Mar 2010 11:35:11 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: multipart/mixed; boundary="------------010509070000000904090908" X-Yandex-TimeMark: 1268382912 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: Marcel Moolenaar Subject: [RFC][PATCH] resizing support for GPART 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: Fri, 12 Mar 2010 08:49:44 -0000 This is a multi-part message in MIME format. --------------010509070000000904090908 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi All. I implemented resizing support for GPART class. My patch is attached. It add new action argument "resize" to gpart utility: gpart resize -i index [-s size] [-f flags] geom If size option is omitted then new partition size is automatically calculated to maximum available. Size can be specified in human readable form, for example "-s 100m" means 100 MBytes. gpart *only* changes *metadata* on geom, but *doesn't* any *filesystem* changes. It can be used for growing partitions with filesystems that supports autoresizing, for example for ZFS. Also it can be used for resizing partitions which don't have any filesystems. I added resizing support for GPT, MBR, BSD, APM, PC98 and VTOC8 schemas. Resizing allowed only for not used providers. But you can set kern.geom.debugflags=16 and busy-check will be skipped. Usage example: ===================================================== # gpart create -s gpt md0 md0 created # gpart show md0 => 34 819133 md0 GPT (400M) 34 819133 - free - (400M) # gpart add -s 128k -t freebsd-boot md0 md0p1 added # gpart add -s 250m -t freebsd-zfs md0 md0p2 added # zpool create -m /mnt tank md0p2 # gpart show md0 => 34 819133 md0 GPT (400M) 34 256 1 freebsd-boot (128K) 290 512000 2 freebsd-zfs (250M) 512290 306877 - free - (150M) # zpool status tank pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 md0p2 ONLINE 0 0 0 errors: No known data errors # gpart resize -i 2 md0 gpart: Device busy # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 # gpart resize -i 2 md0 md0p2 resized # gpart show md0 => 34 819133 md0 GPT (400M) 34 256 1 freebsd-boot (128K) 290 818877 2 freebsd-zfs (400M) # zpool list tank NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 244M 82,5K 244M 0% ONLINE - # zpool export tank # zpool import tank # zpool list tank NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 394M 87K 394M 0% ONLINE - ===================================================== Any comments and suggestions are welcome! -- WBR, Andrey V. Elsukov --------------010509070000000904090908 Content-Type: text/plain; name="gpart_resize.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gpart_resize.diff.txt" Index: sbin/geom/class/part/gpart.8 =================================================================== --- sbin/geom/class/part/gpart.8 (revision 204945) +++ sbin/geom/class/part/gpart.8 (working copy) @@ -120,6 +120,13 @@ utility: .Op Fl t Ar type .Op Fl f Ar flags .Ar geom +.\" ==== RESIZE ==== +.Nm +.Cm resize +.Fl i Ar index +.Op Fl s Ar size +.Op Fl f Ar flags +.Ar geom .\" ==== SET ==== .Nm .Cm set @@ -325,6 +332,30 @@ See the section entitled below for a discussion about its use. .El +.\" ==== RESIZE ==== +.It Cm resize +Resize a partition from geom +.Ar geom +and further identified by the +.Fl i Ar index +option. New partition size is expressed in logical block +numbers and can be given by the +.Fl s Ar size +option. If +.Fl s +option is ommited then new size is automatically calculated +to maximum available from given geom +.Ar geom . +.Pp +Additional options include: +.Bl -tag -width 10n +.It Fl f Ar flags +Additional operational flags. +See the section entitled +.Sx "OPERATIONAL FLAGS" +below for a discussion +about its use. +.El .\" ==== SET ==== .It Cm set Set the named attribute on the partition entry. Index: sbin/geom/class/part/geom_part.c =================================================================== --- sbin/geom/class/part/geom_part.c (revision 204945) +++ sbin/geom/class/part/geom_part.c (working copy) @@ -133,6 +133,13 @@ struct g_command PUBSYM(class_commands)[] = { G_OPT_SENTINEL }, "geom", NULL }, + { "resize", 0, gpart_issue, { + { 's', "size", autofill, G_TYPE_ASCLBA }, + { 'i', index_param, NULL, G_TYPE_ASCNUM }, + { 'f', "flags", flags, G_TYPE_STRING }, + G_OPT_SENTINEL }, + "geom", NULL + }, G_CMD_SENTINEL }; @@ -243,6 +250,99 @@ fmtattrib(struct gprovider *pp) } static int +gpart_autofill_resize(struct gctl_req *req) +{ + struct gmesh mesh; + struct gclass *cp; + struct ggeom *gp; + struct gprovider *pp; + unsigned long long last, size, start, new_size; + unsigned long long lba, new_lba; + const char *s; + char *val; + int error, idx; + + s = gctl_get_ascii(req, "size"); + if (*s == '*') + new_size = (unsigned long long)atoll(s); + else + return (0); + + s = gctl_get_ascii(req, index_param); + idx = strtol(s, &val, 10); + if (idx < 1 || *s == '\0' || *val != '\0') + errx(EXIT_FAILURE, "invalid partition index"); + + error = geom_gettree(&mesh); + if (error) + return (error); + s = gctl_get_ascii(req, "class"); + if (s == NULL) + abort(); + cp = find_class(&mesh, s); + if (cp == NULL) + errx(EXIT_FAILURE, "Class %s not found.", s); + s = gctl_get_ascii(req, "geom"); + if (s == NULL) + abort(); + gp = find_geom(cp, s); + if (gp == NULL) + errx(EXIT_FAILURE, "No such geom: %s.", s); + last = atoll(find_geomcfg(gp, "last")); + + LIST_FOREACH(pp, &gp->lg_provider, lg_provider) { + s = find_provcfg(pp, "index"); + if (s == NULL) + continue; + if (atoi(s) == idx) + break; + } + if (pp == NULL) + errx(EXIT_FAILURE, "invalid partition index"); + + s = find_provcfg(pp, "start"); + if (s == NULL) { + s = find_provcfg(pp, "offset"); + start = atoll(s) / pp->lg_sectorsize; + } else + start = atoll(s); + s = find_provcfg(pp, "end"); + if (s == NULL) { + s = find_provcfg(pp, "length"); + lba = start + atoll(s) / pp->lg_sectorsize; + } else + lba = atoll(s) + 1; + + if (lba > last) + return (ENOSPC); + size = lba - start; + pp = find_provider(gp, lba); + if (pp == NULL) + new_size = last - start + 1; + else { + s = find_provcfg(pp, "start"); + if (s == NULL) { + s = find_provcfg(pp, "offset"); + new_lba = atoll(s) / pp->lg_sectorsize; + } else + new_lba = atoll(s); + /* Is there any free space between current and + * next providers? + */ + if (new_lba > lba) + new_size = new_lba - start; + else + return (ENOSPC); + } + asprintf(&val, "%llu", new_size); + if (val == NULL) + return (ENOMEM); + gctl_change_param(req, "size", -1, val); + + return (0); +} + +static int gpart_autofill(struct gctl_req *req) { struct gmesh mesh; @@ -257,6 +357,8 @@ gpart_autofill(struct gctl_req *req) int error, has_size, has_start; s = gctl_get_ascii(req, "verb"); + if (strcmp(s, "resize") == 0) + return gpart_autofill_resize(req); if (strcmp(s, "add") != 0) return (0); Index: sys/geom/part/g_part_pc98.c =================================================================== --- sys/geom/part/g_part_pc98.c (revision 204945) +++ sys/geom/part/g_part_pc98.c (working copy) @@ -77,6 +77,8 @@ static int g_part_pc98_setunset(struct g_part_tabl static const char *g_part_pc98_type(struct g_part_table *, struct g_part_entry *, char *, size_t); static int g_part_pc98_write(struct g_part_table *, struct g_consumer *); +static int g_part_pc98_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); static kobj_method_t g_part_pc98_methods[] = { KOBJMETHOD(g_part_add, g_part_pc98_add), @@ -86,6 +88,7 @@ static kobj_method_t g_part_pc98_methods[] = { KOBJMETHOD(g_part_dumpconf, g_part_pc98_dumpconf), KOBJMETHOD(g_part_dumpto, g_part_pc98_dumpto), KOBJMETHOD(g_part_modify, g_part_pc98_modify), + KOBJMETHOD(g_part_resize, g_part_pc98_resize), KOBJMETHOD(g_part_name, g_part_pc98_name), KOBJMETHOD(g_part_probe, g_part_pc98_probe), KOBJMETHOD(g_part_read, g_part_pc98_read), @@ -308,6 +311,31 @@ g_part_pc98_modify(struct g_part_table *basetable, return (0); } +static int +g_part_pc98_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_pc98_entry *entry; + uint32_t size, cyl; + + cyl = basetable->gpt_heads * basetable->gpt_sectors; + size = gpp->gpp_size; + + if (size < cyl) + return (EINVAL); + if (size % cyl) + size = size - (size % cyl); + if (size < cyl) + return (EINVAL); + + entry = (struct g_part_pc98_entry *)baseentry; + baseentry->gpe_end = baseentry->gpe_start + size - 1; + pc98_set_chs(basetable, baseentry->gpe_end, &entry->ent.dp_ecyl, + &entry->ent.dp_ehd, &entry->ent.dp_esect); + + return (0); +} + static const char * g_part_pc98_name(struct g_part_table *table, struct g_part_entry *baseentry, char *buf, size_t bufsz) Index: sys/geom/part/g_part_vtoc8.c =================================================================== --- sys/geom/part/g_part_vtoc8.c (revision 204945) +++ sys/geom/part/g_part_vtoc8.c (working copy) @@ -67,6 +67,8 @@ static int g_part_vtoc8_read(struct g_part_table * static const char *g_part_vtoc8_type(struct g_part_table *, struct g_part_entry *, char *, size_t); static int g_part_vtoc8_write(struct g_part_table *, struct g_consumer *); +static int g_part_vtoc8_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); static kobj_method_t g_part_vtoc8_methods[] = { KOBJMETHOD(g_part_add, g_part_vtoc8_add), @@ -75,6 +77,7 @@ static kobj_method_t g_part_vtoc8_methods[] = { KOBJMETHOD(g_part_dumpconf, g_part_vtoc8_dumpconf), KOBJMETHOD(g_part_dumpto, g_part_vtoc8_dumpto), KOBJMETHOD(g_part_modify, g_part_vtoc8_modify), + KOBJMETHOD(g_part_resize, g_part_vtoc8_resize), KOBJMETHOD(g_part_name, g_part_vtoc8_name), KOBJMETHOD(g_part_probe, g_part_vtoc8_probe), KOBJMETHOD(g_part_read, g_part_vtoc8_read), @@ -294,6 +297,26 @@ g_part_vtoc8_modify(struct g_part_table *basetable return (0); } +static int +g_part_vtoc8_resize(struct g_part_table *basetable, + struct g_part_entry *entry, struct g_part_parms *gpp) +{ + struct g_part_vtoc8_table *table; + uint64_t size; + + table = (struct g_part_vtoc8_table *)basetable; + size = gpp->gpp_size; + if (size % table->secpercyl) + size = size - (size % table->secpercyl); + if (size < table->secpercyl) + return (EINVAL); + + entry->gpe_end = entry->gpe_start + size - 1; + be32enc(&table->vtoc.map[entry->gpe_index - 1].nblks, size); + + return (0); +} + static const char * g_part_vtoc8_name(struct g_part_table *table, struct g_part_entry *baseentry, char *buf, size_t bufsz) Index: sys/geom/part/g_part_bsd.c =================================================================== --- sys/geom/part/g_part_bsd.c (revision 204945) +++ sys/geom/part/g_part_bsd.c (working copy) @@ -73,6 +73,8 @@ static int g_part_bsd_read(struct g_part_table *, static const char *g_part_bsd_type(struct g_part_table *, struct g_part_entry *, char *, size_t); static int g_part_bsd_write(struct g_part_table *, struct g_consumer *); +static int g_part_bsd_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); static kobj_method_t g_part_bsd_methods[] = { KOBJMETHOD(g_part_add, g_part_bsd_add), @@ -82,6 +84,7 @@ static kobj_method_t g_part_bsd_methods[] = { KOBJMETHOD(g_part_dumpconf, g_part_bsd_dumpconf), KOBJMETHOD(g_part_dumpto, g_part_bsd_dumpto), KOBJMETHOD(g_part_modify, g_part_bsd_modify), + KOBJMETHOD(g_part_resize, g_part_bsd_resize), KOBJMETHOD(g_part_name, g_part_bsd_name), KOBJMETHOD(g_part_probe, g_part_bsd_probe), KOBJMETHOD(g_part_read, g_part_bsd_read), @@ -288,6 +291,19 @@ g_part_bsd_modify(struct g_part_table *basetable, return (0); } +static int +g_part_bsd_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_bsd_entry *entry; + + entry = (struct g_part_bsd_entry *)baseentry; + baseentry->gpe_end = baseentry->gpe_start + gpp->gpp_size - 1; + entry->part.p_size = gpp->gpp_size; + + return (0); +} + static const char * g_part_bsd_name(struct g_part_table *table, struct g_part_entry *baseentry, char *buf, size_t bufsz) Index: sys/geom/part/g_part_if.m =================================================================== --- sys/geom/part/g_part_if.m (revision 204945) +++ sys/geom/part/g_part_if.m (working copy) @@ -58,6 +58,13 @@ CODE { { return (0); } + + static int + default_resize(struct g_part_table *t __unused, + struct g_part_entry *e __unused, struct g_part_parms *p __unused) + { + return (ENOSYS); + } }; # add() - scheme specific processing for the add verb. @@ -114,6 +121,13 @@ METHOD int modify { struct g_part_parms *gpp; }; +# resize() - scheme specific processing for the resize verb. +METHOD int resize { + struct g_part_table *table; + struct g_part_entry *entry; + struct g_part_parms *gpp; +} DEFAULT default_resize; + # name() - return the name of the given partition entry. # Typical names are "p1", "s0" or "c". METHOD const char * name { Index: sys/geom/part/g_part_gpt.c =================================================================== --- sys/geom/part/g_part_gpt.c (revision 204945) +++ sys/geom/part/g_part_gpt.c (working copy) @@ -103,6 +103,8 @@ static int g_part_gpt_read(struct g_part_table *, static const char *g_part_gpt_type(struct g_part_table *, struct g_part_entry *, char *, size_t); static int g_part_gpt_write(struct g_part_table *, struct g_consumer *); +static int g_part_gpt_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); static kobj_method_t g_part_gpt_methods[] = { KOBJMETHOD(g_part_add, g_part_gpt_add), @@ -112,6 +114,7 @@ static kobj_method_t g_part_gpt_methods[] = { KOBJMETHOD(g_part_dumpconf, g_part_gpt_dumpconf), KOBJMETHOD(g_part_dumpto, g_part_gpt_dumpto), KOBJMETHOD(g_part_modify, g_part_gpt_modify), + KOBJMETHOD(g_part_resize, g_part_gpt_resize), KOBJMETHOD(g_part_name, g_part_gpt_name), KOBJMETHOD(g_part_probe, g_part_gpt_probe), KOBJMETHOD(g_part_read, g_part_gpt_read), @@ -550,6 +553,19 @@ g_part_gpt_modify(struct g_part_table *basetable, return (0); } +static int +g_part_gpt_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_gpt_entry *entry; + entry = (struct g_part_gpt_entry *)baseentry; + + baseentry->gpe_end = baseentry->gpe_start + gpp->gpp_size - 1; + entry->ent.ent_lba_end = baseentry->gpe_end; + + return (0); +} + static const char * g_part_gpt_name(struct g_part_table *table, struct g_part_entry *baseentry, char *buf, size_t bufsz) Index: sys/geom/part/g_part_apm.c =================================================================== --- sys/geom/part/g_part_apm.c (revision 204945) +++ sys/geom/part/g_part_apm.c (working copy) @@ -74,6 +74,8 @@ static int g_part_apm_read(struct g_part_table *, static const char *g_part_apm_type(struct g_part_table *, struct g_part_entry *, char *, size_t); static int g_part_apm_write(struct g_part_table *, struct g_consumer *); +static int g_part_apm_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); static kobj_method_t g_part_apm_methods[] = { KOBJMETHOD(g_part_add, g_part_apm_add), @@ -82,6 +84,7 @@ static kobj_method_t g_part_apm_methods[] = { KOBJMETHOD(g_part_dumpconf, g_part_apm_dumpconf), KOBJMETHOD(g_part_dumpto, g_part_apm_dumpto), KOBJMETHOD(g_part_modify, g_part_apm_modify), + KOBJMETHOD(g_part_resize, g_part_apm_resize), KOBJMETHOD(g_part_name, g_part_apm_name), KOBJMETHOD(g_part_probe, g_part_apm_probe), KOBJMETHOD(g_part_read, g_part_apm_read), @@ -318,6 +321,19 @@ g_part_apm_modify(struct g_part_table *basetable, return (0); } +static int +g_part_apm_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_apm_entry *entry; + + entry = (struct g_part_apm_entry *)baseentry; + baseentry->gpe_end = baseentry->gpe_start + gpp->gpp_size - 1; + entry->ent.ent_size = gpp->gpp_size; + + return (0); +} + static const char * g_part_apm_name(struct g_part_table *table, struct g_part_entry *baseentry, char *buf, size_t bufsz) Index: sys/geom/part/g_part.c =================================================================== --- sys/geom/part/g_part.c (revision 204945) +++ sys/geom/part/g_part.c (working copy) @@ -971,10 +971,91 @@ g_part_ctl_recover(struct gctl_req *req, struct g_ static int g_part_ctl_resize(struct gctl_req *req, struct g_part_parms *gpp) { - gctl_error(req, "%d verb 'resize'", ENOSYS); - return (ENOSYS); -} + struct g_geom *gp; + struct g_provider *pp; + struct g_part_entry *pe, *entry; + struct g_part_table *table; + struct sbuf *sb; + quad_t end; + int error; + gp = gpp->gpp_geom; + G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__, gp->name)); + g_topology_assert(); + table = gp->softc; + + /* check gpp_index */ + LIST_FOREACH(entry, &table->gpt_entry, gpe_entry) { + if (entry->gpe_deleted || entry->gpe_internal) + continue; + if (entry->gpe_index == gpp->gpp_index) + break; + } + if (entry == NULL) { + gctl_error(req, "%d index '%d'", ENOENT, gpp->gpp_index); + return (ENOENT); + } + + end = entry->gpe_start + gpp->gpp_size - 1; + + /* resizing isn't needed, return success */ + if (end == entry->gpe_end) + goto done; + + if (gpp->gpp_size < 1 || end > table->gpt_last) { + gctl_error(req, "%d size '%jd'", EINVAL, + (intmax_t)gpp->gpp_size); + return (EINVAL); + } + + LIST_FOREACH(pe, &table->gpt_entry, gpe_entry) { + if (pe->gpe_deleted || pe->gpe_internal || pe == entry) + continue; + if (end >= pe->gpe_start && end <= pe->gpe_end) { + gctl_error(req, "%d end '%jd'", ENOSPC, + (intmax_t)end); + return (ENOSPC); + } + if (entry->gpe_start < pe->gpe_start && end > pe->gpe_end) { + gctl_error(req, "%d size '%jd'", ENOSPC, + (intmax_t)gpp->gpp_size); + return (ENOSPC); + } + } + + pp = entry->gpe_pp; + if ((g_debugflags & 16) == 0 && + (pp->acr > 0 || pp->acw > 0 || pp->ace > 0)) { + gctl_error(req, "%d", EBUSY); + return (EBUSY); + } + + error = G_PART_RESIZE(table, entry, gpp); + if (error) { + gctl_error(req, "%d", error); + return (error); + } + + if (!entry->gpe_created) + entry->gpe_modified = 1; + + /* update mediasize of changed provider */ + pp->mediasize = (entry->gpe_end - entry->gpe_start + 1) * + pp->sectorsize; + +done: + /* Provide feedback if so requested. */ + if (gpp->gpp_parms & G_PART_PARM_OUTPUT) { + sb = sbuf_new_auto(); + G_PART_FULLNAME(table, entry, sb, gp->name); + sbuf_cat(sb, " resized\n"); + sbuf_finish(sb); + gctl_set_param(req, "output", sbuf_data(sb), sbuf_len(sb) + 1); + sbuf_delete(sb); + } + return (0); +} + static int g_part_ctl_setunset(struct gctl_req *req, struct g_part_parms *gpp, unsigned int set) @@ -1194,7 +1275,8 @@ g_part_ctlreq(struct gctl_req *req, struct g_class mparms |= G_PART_PARM_GEOM; } else if (!strcmp(verb, "resize")) { ctlreq = G_PART_CTL_RESIZE; - mparms |= G_PART_PARM_GEOM | G_PART_PARM_INDEX; + mparms |= G_PART_PARM_GEOM | G_PART_PARM_INDEX | + G_PART_PARM_SIZE; } break; case 's': Index: sys/geom/part/g_part_mbr.c =================================================================== --- sys/geom/part/g_part_mbr.c (revision 204945) +++ sys/geom/part/g_part_mbr.c (working copy) @@ -76,6 +76,8 @@ static int g_part_mbr_setunset(struct g_part_table static const char *g_part_mbr_type(struct g_part_table *, struct g_part_entry *, char *, size_t); static int g_part_mbr_write(struct g_part_table *, struct g_consumer *); +static int g_part_mbr_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); static kobj_method_t g_part_mbr_methods[] = { KOBJMETHOD(g_part_add, g_part_mbr_add), @@ -85,6 +87,7 @@ static kobj_method_t g_part_mbr_methods[] = { KOBJMETHOD(g_part_dumpconf, g_part_mbr_dumpconf), KOBJMETHOD(g_part_dumpto, g_part_mbr_dumpto), KOBJMETHOD(g_part_modify, g_part_mbr_modify), + KOBJMETHOD(g_part_resize, g_part_mbr_resize), KOBJMETHOD(g_part_name, g_part_mbr_name), KOBJMETHOD(g_part_probe, g_part_mbr_probe), KOBJMETHOD(g_part_read, g_part_mbr_read), @@ -302,6 +305,31 @@ g_part_mbr_modify(struct g_part_table *basetable, return (0); } +static int +g_part_mbr_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_mbr_entry *entry; + uint32_t size, sectors; + + sectors = basetable->gpt_sectors; + size = gpp->gpp_size; + + if (size < sectors) + return (EINVAL); + if (size % sectors) + size = size - (size % sectors); + if (size < sectors) + return (EINVAL); + + entry = (struct g_part_mbr_entry *)baseentry; + baseentry->gpe_end = baseentry->gpe_start + size - 1; + entry->ent.dp_size = size; + mbr_set_chs(basetable, baseentry->gpe_end, &entry->ent.dp_ecyl, + &entry->ent.dp_ehd, &entry->ent.dp_esect); + return (0); +} + static const char * g_part_mbr_name(struct g_part_table *table, struct g_part_entry *baseentry, char *buf, size_t bufsz) --------------010509070000000904090908-- From owner-freebsd-geom@FreeBSD.ORG Sat Mar 13 08:35:57 2010 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38BA2106566C; Sat, 13 Mar 2010 08:35:57 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id BF8818FC15; Sat, 13 Mar 2010 08:35:56 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 3E46615146B; Sat, 13 Mar 2010 10:35:52 +0200 (EET) Date: Sat, 13 Mar 2010 10:35:52 +0200 From: Jaakko Heinonen To: freebsd-geom@FreeBSD.org Message-ID: <20100313083551.GB966@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pjd@FreeBSD.org, phk@FreeBSD.org Subject: Escape unsafe characters for kern.geom.confxml XML dump 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, 13 Mar 2010 08:35:57 -0000 Hi, I intend to commit following patch unless there are objections. I have seen the problem commonly reported by FreeBSD users. --- Escape characters unsafe for XML output in GEOM class, instance and provider names. - Characters in range 0x01-0x1f except '\t', '\n', and '\r' are replaced with '?'. Those characters are disallowed in XML. - '&', '<', '>', '\'', '"' and characters in range 0x7f-0xff are replaced with XML numeric character reference. If the kern.geom.confxml sysctl provides invalid XML, libgeom geom_xml2tree() fails and utilities using it do not work. Unsafe characters are common in msdosfs and cd9660 labels. PR: kern/104389 Submitter by: Doug Steinwand (original version) %%% Index: sys/geom/geom_dump.c =================================================================== --- sys/geom/geom_dump.c (revision 205081) +++ sys/geom/geom_dump.c (working copy) @@ -154,6 +154,28 @@ g_conftxt(void *p, int flag) static void +g_conf_print_escaped(struct sbuf *sb, const char *fmt, const char *str) +{ + struct sbuf *s; + const u_char *c; + + s = sbuf_new_auto(); + + for (c = str; *c != '\0'; c++) { + if (*c == '&' || *c == '<' || *c == '>' || + *c == '\'' || *c == '"' || *c > 0x7e) + sbuf_printf(s, "&#x%X;", *c); + else if (*c == '\t' || *c == '\n' || *c == '\r' || *c > 0x1f) + sbuf_putc(s, *c); + else + sbuf_putc(s, '?'); + } + sbuf_finish(s); + sbuf_printf(sb, fmt, sbuf_data(s)); + sbuf_delete(s); +} + +static void g_conf_consumer(struct sbuf *sb, struct g_consumer *cp) { @@ -181,7 +203,7 @@ g_conf_provider(struct sbuf *sb, struct sbuf_printf(sb, "\t \n", pp->geom); sbuf_printf(sb, "\t r%dw%de%d\n", pp->acr, pp->acw, pp->ace); - sbuf_printf(sb, "\t %s\n", pp->name); + g_conf_print_escaped(sb, "\t %s\n", pp->name); sbuf_printf(sb, "\t %jd\n", (intmax_t)pp->mediasize); sbuf_printf(sb, "\t %u\n", pp->sectorsize); @@ -208,7 +230,7 @@ g_conf_geom(struct sbuf *sb, struct g_ge sbuf_printf(sb, " \n", gp); sbuf_printf(sb, " \n", gp->class); - sbuf_printf(sb, " %s\n", gp->name); + g_conf_print_escaped(sb, " %s\n", gp->name); sbuf_printf(sb, " %d\n", gp->rank); if (gp->flags & G_GEOM_WITHER) sbuf_printf(sb, " \n"); @@ -237,7 +259,7 @@ g_conf_class(struct sbuf *sb, struct g_c struct g_geom *gp2; sbuf_printf(sb, " \n", mp); - sbuf_printf(sb, " %s\n", mp->name); + g_conf_print_escaped(sb, " %s\n", mp->name); LIST_FOREACH(gp2, &mp->geom, geom) { if (gp != NULL && gp != gp2) continue; %%% -- Jaakko From owner-freebsd-geom@FreeBSD.ORG Sat Mar 13 11:54:24 2010 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03F8106564A; Sat, 13 Mar 2010 11:54:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C15A18FC08; Sat, 13 Mar 2010 11:54:23 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA04291; Sat, 13 Mar 2010 13:54:21 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NqPvB-0005BB-7C; Sat, 13 Mar 2010 13:54:21 +0200 Message-ID: <4B9B7CEC.4050809@icyb.net.ua> Date: Sat, 13 Mar 2010 13:54:20 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Jaakko Heinonen References: <20100313083551.GB966@a91-153-117-195.elisa-laajakaista.fi> In-Reply-To: <20100313083551.GB966@a91-153-117-195.elisa-laajakaista.fi> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: Re: Escape unsafe characters for kern.geom.confxml XML dump 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, 13 Mar 2010 11:54:24 -0000 on 13/03/2010 10:35 Jaakko Heinonen said the following: > Hi, > > I intend to commit following patch unless there are objections. I have > seen the problem commonly reported by FreeBSD users. > > --- > > Escape characters unsafe for XML output in GEOM class, instance and provider > names. > > - Characters in range 0x01-0x1f except '\t', '\n', and '\r' are replaced > with '?'. Those characters are disallowed in XML. > - '&', '<', '>', '\'', '"' and characters in range 0x7f-0xff are replaced > with XML numeric character reference. > > If the kern.geom.confxml sysctl provides invalid XML, libgeom > geom_xml2tree() fails and utilities using it do not work. Unsafe > characters are common in msdosfs and cd9660 labels. > > PR: kern/104389 > Submitter by: Doug Steinwand (original version) Thank you for taking care of this one. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sat Mar 13 22:07:42 2010 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED8811065670; Sat, 13 Mar 2010 22:07:42 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 673328FC12; Sat, 13 Mar 2010 22:07:41 +0000 (UTC) Received: by fxm1 with SMTP id 1so1651737fxm.13 for ; Sat, 13 Mar 2010 14:07:41 -0800 (PST) Received: by 10.223.17.23 with SMTP id q23mr1671472faa.65.1268518058101; Sat, 13 Mar 2010 14:07:38 -0800 (PST) Received: from localhost (153-123-133-95.pool.ukrtel.net [95.133.123.153]) by mx.google.com with ESMTPS id 13sm2014153fxm.10.2010.03.13.14.07.36 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 14:07:37 -0800 (PST) Date: Sun, 14 Mar 2010 00:06:27 +0200 From: Alex RAY To: geom@freebsd.org, embedded@freebsd.org Message-Id: <20100314000627.5a63f4f9.ray@ddteam.net> Organization: DDTeam.net X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: GEOM_ULZMA 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, 13 Mar 2010 22:07:43 -0000 Hi, If anyone is interested. http://my.ddteam.net/files/GEOM_ULZMA.tar.gz -- Alex RAY