From owner-freebsd-bugs@FreeBSD.ORG Fri May 28 17:07:04 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B73B106567F; Fri, 28 May 2010 17:07:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD2328FC15; Fri, 28 May 2010 17:07:03 +0000 (UTC) Received: by vws12 with SMTP id 12so1505408vws.13 for ; Fri, 28 May 2010 10:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fbaAf4XLgTjLIycBS1Y2UxD0GLBJMra3asYddwsVgZ4=; b=snbL8yvHwifGnhTjT6SBWcrSEsUEwIv57tj/jtaef71ImzhAI9uxQOkJn66cn5yWBg dL4Lhd85+K8pIY+Y83wW531ofCcL3uPqPzF69L6hGO31HuX99+ON3TF8Sa83ael0lwSp nazDXSY2zyLXtr+hcwQB4EY1g7gpU6uAhsz4U= 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=ljbqbxRc0Ba9OoV7DSZp6a8W1SJxKAtopMZtAfcvRlkMpC/KdDLhi5SGfZLklOi54B XrqkO593MUFMAwoy909hdklex7XqZdSn1p+L0HE846F4AEGTX+dBCiF2Gjo8YGly3nnQ d76oYPiMwhvig8pKbTqI+iMvnDfiRxdPGeVDw= MIME-Version: 1.0 Received: by 10.224.19.9 with SMTP id y9mr359749qaa.353.1275066422711; Fri, 28 May 2010 10:07:02 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Fri, 28 May 2010 10:07:01 -0700 (PDT) In-Reply-To: <8CCCC95194601E5-7FC-C04B@web-mmc-d09.sysops.aol.com> References: <8CCCC95194601E5-7FC-C04B@web-mmc-d09.sysops.aol.com> Date: Fri, 28 May 2010 10:07:01 -0700 Message-ID: From: Garrett Cooper To: dieterbsd@engineer.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jh@freebsd.org, freebsd@sopwith.solgatos.com, freebsd-bugs@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression] X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 17:07:04 -0000 On Fri, May 28, 2010 at 8:53 AM, wrote: >> You should remove GEOM_PART_* entries. I think that the duplicates you >> saw are because you had geom_part still enabled. > > I thought about that. =A0Having both GEOM_PART_MBR and GEOM_MBR > seemed suspicious, but GEOM_PART_MBR isn't from the config file: > > grep -i geom GENERIC > options =A0 =A0 =A0 =A0 GEOM_PART_GPT =A0 =A0 =A0 =A0 =A0 # GUID Partitio= n Tables. > options =A0 =A0 =A0 =A0 GEOM_LABEL =A0 =A0 =A0 =A0 =A0 =A0 =A0# Provides = labelization > > and then I added GEOM_MBR and GEOM_BSD as suggested. =A0So I don't > know where GEOM_PART_MBR comes from or how to get rid of it. > I am assuming that "make buildkernel" calls config(8) and config > builds opt_geom.h based on the config file, but it must have some > other input that I haven't found. > > It isn't clear to me what the difference between GEOM_PART_MBR and > GEOM_MBR is supposed to be (same for GEOM_PART_BSD and GEOM_BSD). > conf/NOTES doesn't list a GEOM_GPT, only GEOM_PART_GPT. =A0I assume > that removing GEOM_PART_GPT would break disks using GUID partition > tables. GEOM_MBR is the legacy way to specify GEOM_PART_MBR IIRC (from .../UPDATING= ): 20090320: GEOM_PART has become the default partition slicer for storage devic= es, replacing GEOM_MBR, GEOM_BSD, GEOM_PC98 and GEOM_GPT slicers. It introduces some changes: MSDOS/EBR: the devices created from MSDOS extended partition entrie= s (EBR) can be named differently than with GEOM_MBR and are now symli= nks to devices with offset-based names. fstabs may need to be modified. BSD: the "geometry does not match label" warning is harmless in mos= t cases but it points to problems in file system misalignment with disk geometry. The "c" partition is now implicit, covers the whole top-level drive and cannot be (mis)used by users. General: Kernel dumps are now not allowed to be written to devices whose partition types indicate they are meant to be used for file systems (or, in case of MSDOS partitions, as something else than the "386BSD" type). Most of these changes date approximately from 200812. Thanks, -Garrett