From owner-freebsd-stable@FreeBSD.ORG Thu May 19 09:20:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A645416A4CE for ; Thu, 19 May 2005 09:20:02 +0000 (GMT) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA39943D53 for ; Thu, 19 May 2005 09:20:01 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4J9JxZQ002200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 19:20:00 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4J9JxRx003931; Thu, 19 May 2005 19:19:59 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4J9Jx43003930; Thu, 19 May 2005 19:19:59 +1000 (EST) (envelope-from pjeremy) Date: Thu, 19 May 2005 19:19:59 +1000 From: Peter Jeremy To: Bob Bishop Message-ID: <20050519091959.GD2129@cirb503493.alcatel.com.au> References: <20050518162535.B87264@carver.gumbysoft.com> <200505190156.aa13658@nowhere.iedowse.com> <6.2.0.14.2.20050519092733.044eac00@gid.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.2.20050519092733.044eac00@gid.co.uk> User-Agent: Mutt/1.4.2i cc: stable@freebsd.org Subject: Re: Boot loader cant identify ntfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 09:20:02 -0000 On Thu, 2005-May-19 09:29:25 +0100, Bob Bishop wrote: >At 01:56 19/05/2005, Ian Dowse wrote: >>[...] >>BTW, one potential improvement to the current boot0 situation would >>be to have boot0cfg dynamically generate the OS table based on what >>partition types actually exist on the disk. [etc] > >That would be just plain unhelpful in the case where a partition gets >retyped subsequently. As I read Ian's proposal, it still dynamically detects the partition types at boot time. It's just that the table of known partition types is built by boot0cfg based on the partition types when boot0cfg is run. If you change a partition partition type then the new partition type may not be recognized but that is no worse than the current situation. It would probably be possible to pad the available space with other "common" partition types. -- Peter Jeremy