From owner-freebsd-geom@FreeBSD.ORG Wed Oct 22 23:39:51 2008 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 0A436106566B; Wed, 22 Oct 2008 23:39:51 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id E6F798FC16; Wed, 22 Oct 2008 23:39:50 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K950050ZZ237T10@asmtp017.mac.com>; Wed, 22 Oct 2008 16:39:47 -0700 (PDT) Message-id: <3AE9F43A-C0CF-4030-9E2A-1B5EE8CFA21A@mac.com> From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <48FFB025.2060100@icyb.net.ua> Date: Wed, 22 Oct 2008 16:39:16 -0700 References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua> <48FF913A.9070700@icyb.net.ua> <7334715F-FAE1-40EE-92EB-468041587410@mac.com> <48FFA1F8.40709@icyb.net.ua> <48FFB025.2060100@icyb.net.ua> X-Mailer: Apple Mail (2.929.2) Cc: Marcel Moolenaar , freebsd-geom@freebsd.org Subject: Re: gpart oddity 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, 22 Oct 2008 23:39:51 -0000 On Oct 22, 2008, at 3:58 PM, Andriy Gapon wrote: >> It's possible that I haven't merged all the changes from >> HEAD to 7-stable. Try the following patch: >> Index: g_part_bsd.c >> =================================================================== >> --- g_part_bsd.c (revision 183454) >> +++ g_part_bsd.c (revision 183455) >> @@ -293,7 +293,7 @@ >> magic2 = le32dec(buf + 132); >> g_free(buf); >> return ((magic1 == DISKMAGIC && magic2 == DISKMAGIC) >> - ? G_PART_PROBE_PRI_NORM : ENXIO); >> + ? G_PART_PROBE_PRI_HIGH : ENXIO); >> } >> static int > > Yes, that was it, thank you again! Cool... I'll make sure to sync 7-stable with HEAD soon... > One hopefully last question: is disklabel supposed to keep working > in this new world or should I switch to gpart command exclusively? disklabel(8) (and fdisk(8) for that matter) will not work when you have partitions/slices mounted. So, in that repsect, gpart will be only command that'll work in all cases. If you don't have partitions mounted, then disklabel(8) (and fdisk(8)) can be used to put a label on the disk or modify a label that's already there. > $ disklabel ad4s1 > # /dev/ad4s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 2097152 2097215 4.2BSD 0 0 0 > b: 2097152 63 swap > c: 587191752 63 unused 0 0 # "raw" > part, don't edit > d: 52428800 4194367 4.2BSD 0 0 0 > e: 530568648 56623167 4.2BSD 0 0 0 > partition c: partition extends past end of unit > disklabel: partition c doesn't start at 0! > disklabel: An incorrect partition c may cause problems for standard > system utilities > partition e: partition extends past end of unit > > It seems like offsets in disklabel output are now absolute (from > start of ad4), but previously they were relative to ad4s1 start: Nah... This is one of the many kluges and quirks added over time to patch up certain behaviour. disklabel(8) uses a magic gctl request to ask the kernel at what location (relative the the MBR) the label is on the disk. This gctl is not supported by gpart because it doesn't make sense and is broken. The disklabel(8) utility should do exactly the same thing as the kernel and use the offset of the 'c' partition to turn the absolute offsets into relative offsets and not complain about it. In short: your label is absolute (and there's nothing wrong with it) and disklabel(8) is broken :-) -- Marcel Moolenaar xcllnt@mac.com