From owner-freebsd-current Mon Mar 9 14:13:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12707 for freebsd-current-outgoing; Mon, 9 Mar 1998 14:13:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12688; Mon, 9 Mar 1998 14:12:50 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA16255; Mon, 9 Mar 1998 14:10:25 -0800 (PST) Message-Id: <199803092210.OAA16255@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: mike@smith.net.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: *HEADS UP* Correction to previous postings. In-reply-to: Your message of "Mon, 09 Mar 1998 21:20:15 +1100." <199803091020.VAA22972@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Mar 1998 14:10:24 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Please note that in the recent postings regarding the changes to the > >fashion in which the root filesystem is located and mounted there has > >been a fundamental factual error on my part. > > > >This error *will* cause users with dedicated disks serious problems, > >unless they adopt the same procedure require by non-dedicated disk > >users. > > > >The error in this case was the assumption that partitions on a dedicated > >disk were handled as though they were truly equivalent to the > >compatability slice entries. > > A correct assumption. This doesn't appear to be borne out in any consistent fashion. > >This is not correct; rather they appear > >as though they were in the first slice on the disk. > > Not with normal slice naming. The first slice (s1) doesn't exist on > dangerously dedicated disks. Rev.1.88 of autoconf.c just breaks > support for dangerously dedicated disks. Rev.1.87 was correct in > this areas, except it spells COMPATIBILITY_SLICE as 0. That's odd then; libdisk calls them 'xdNs1', and you appear to be able to mount them like that. More significantly, the bootstrap passes the invalid slice number 1 in; using this is guaranteed to result in failure, as there aren't any devices with a '1' in the slice field. I believed that I had, actually, tested on a dedicated-disk system, however it appears otherwise. 8( > disks are not as easy to create as they used to be. Mine have > an all-zero DOS partition table. The update procedure for > dangerously-dedicated disks is to back out rev.1.88 of autoconf.c. *sigh* I thought that I had established this correctly twice now, based on code study and our earlier discussions. Can I please confirm, so that this isn't screwed for good? - If the slice number from the bootstrap is in the range BASE_SLICE to MAX_SLICES, it is OK to insert this as-is into the root device minor number. - If the slice number is < BASE_SLICE, the correct minor for the root device will have a 0 in the slice field. ie. I should be using COMPATABILITY_SLICE not BASE_SLICE in the test in setroot()? Thanks. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message