From owner-freebsd-stable Mon Mar 9 18:59:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15708 for freebsd-stable-outgoing; Mon, 9 Mar 1998 18:59:07 -0800 (PST) (envelope-from owner-freebsd-stable@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 SAA15602; Mon, 9 Mar 1998 18:58:01 -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 SAA17092; Mon, 9 Mar 1998 18:55:55 -0800 (PST) Message-Id: <199803100255.SAA17092@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: mike@smith.net.au, current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: *HEADS UP* Correction to previous postings. In-reply-to: Your message of "Tue, 10 Mar 1998 13:01:54 +1100." <199803100201.NAA26202@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Mar 1998 18:55:53 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > >I believed that I had, actually, tested on a dedicated-disk system, > >however it appears otherwise. 8( > > It broke immediately here. I lied about having a DOS partition table > with all-zeros. I actually have one with the historical invalid > partition table. This breaks in a different way. There are _three_ > signifantly different configurations that give the whole disk to > FreeBSD. See below. This is the problem; I had the understanding that there was only one. > >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. > > No. This breaks in my configuration with a historical invalid partition > table (see biosboot/boot2.S). The boot blocks search this table and > find slice 4 in it. They don't notice that it is invalid, so they pass > slice 4 to the kernel. The kernel notices that it is invalid and gives > only the compatibility slice, so the boot fails. Slice 4 must be mapped > to slice COMPATIBILITY_SLICE (= 0) in this case. This is the case where the disk has been initialised with 'disklabel auto', it seems. > > - If the slice number is < BASE_SLICE, the correct minor for the root > > device will have a 0 in the slice field. > > Correct, but it is better to write this rule as: > > - If the slice number is == WHOLE_DISK_SLICE, the correct minor for the > root device will have COMPATIBILITY_SLICE in the slice field. OK. > >ie. I should be using COMPATABILITY_SLICE not BASE_SLICE in the test in > >setroot()? > > Yes. > > Summary of the 3 cases where the whole disk is used for FreeBSD: > > Partition table config Slice# passed by bootblocks Slice# to use for "/" > ---------------------- --------------------------- ------------------------- > Signature != 0xAA55 WHOLE_DISK_SLICE (= 1) COMPATIBILITY_SLICE (= 0) > Historical invalid BASE_SLICE + 3 (= 5) COMPATIBILITY_SLICE (= 0) > "Valid" (1 big part.) BASE_SLICE + N (0 <= N < 4) BASE_SLICE + N There appears to be no means for differentiating the "historical invalid" case from the "valid" case where the first FreeBSD slice has N == 3, given the constraints under which setroot() is operating. (Note that "valid" above is a subset of any FreeBSD slice being anywhere on the disk. It is this subset that the sysinstall "all disk/no" option generates.) Do you have any suggestions for making this differentiation? Altering the bootstrap is not practical at this point in time, as it hamstrings upgraders. > User actions in the 3 cases: > 1. Hope this doesn't happen. It is very unlikely to happen for boot disks. > 2. Wait for fixes. > 3. Same as for cases where the whole disk is not used for FreeBSD - edit > /etc/fstab. I would like to find a fix for 2. that doesn't involve going backwards to the 'bad old days', but this seems difficult just now. -- \\ 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-stable" in the body of the message