Date: Tue, 10 Mar 1998 13:01:54 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, mike@smith.net.au Cc: current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: *HEADS UP* Correction to previous postings. Message-ID: <199803100201.NAA26202@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >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. It is nevertheless correct. >> >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. Slice s1 has slice number 2. It is easy to confuse this with slice number 2. setroot() now suffers from this confusion. >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. Correct. >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. >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. > - 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. >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 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. There isn't really an all-zeros case. If the MBR signature is 0xAA55, then all-zeros in the partition table gives 4 slices of size 0. All-zeros in the MBR gives a signature of 0 so it reduces to the signature != 0xAA55 case. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803100201.NAA26202>