Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 09 Mar 1998 18:55:53 -0800
From:      Mike Smith <mike@smith.net.au>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        mike@smith.net.au, current@FreeBSD.ORG, stable@FreeBSD.ORG
Subject:   Re: *HEADS UP* Correction to previous postings. 
Message-ID:  <199803100255.SAA17092@dingo.cdrom.com>
In-Reply-To: Your message of "Tue, 10 Mar 1998 13:01:54 %2B1100." <199803100201.NAA26202@godzilla.zeta.org.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> >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-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803100255.SAA17092>