From root@skaro.lonestar.org  Fri Oct 24 20:29:24 1997
Received: from skaro.lonestar.org ([204.178.74.204])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA08958
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 24 Oct 1997 20:29:22 -0700 (PDT)
          (envelope-from root@skaro.lonestar.org)
Received: (from root@localhost)
	by skaro.lonestar.org (8.8.7/8.8.7) id WAA00369;
	Fri, 24 Oct 1997 22:30:05 -0500 (CDT)
	(envelope-from root)
Message-Id: <199710250330.WAA00369@skaro.lonestar.org>
Date: Fri, 24 Oct 1997 22:30:05 -0500 (CDT)
From: uhclem@nemesis.lonestar.org
Reply-To: uhclem@nemesis.lonestar.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: Boot complains about disk slices in FAT partitions - FDIV075
X-Send-Pr-Version: 3.2

>Number:         4845
>Category:       kern
>Synopsis:       Boot complains about disk slices in FAT partitions - FDIV075
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    qa
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Oct 24 20:30:00 PDT 1997
>Closed-Date:    Tue Nov 12 13:30:13 PST 2002
>Last-Modified:  Tue Nov 12 13:30:13 PST 2002
>Originator:     Frank Durda IV
>Release:        FreeBSD 2.2.5-RELEASE i386
>Organization:
None
>Environment:

Pentium 120MHz system with Adaptec 1542 controller with one 2GB SCSI
drive.  32MB of RAM

>Description:

On a drive that had previously contained only a single FreeBSD partition
(created under 2.2.5 101897 BETA), a new install of the release 2.2.5
was done.  This time, during the FreeBSD install, a different drive
division was specified.   First, a 50Meg Type 6 (FAT) partition was
defined (using the FreeBSD install disk), and the rest of the disk was
assigned to a FreeBSD (165) partition.  In the FreeBSD partition, a 150Meg
root, 240Meg swap, 400Meg /usr, 800Meg /usr/src and a ~470Meg /a were
defined.  The install proceeded normally.

Here is what fdisk says:

******* Working on device /dev/rsd0 *******
parameters extracted from in-core disklabel are:
cylinders=2069 heads=64 sectors/track=32 (2048 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=2069 heads=64 sectors/track=32 (2048 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 6,(Primary 'big' DOS (> 32MB))
    start 32, size 102368 (49 Meg), flag 0
	beg: cyl 0/ sector 1/ head 1;
	end: cyl 49/ sector 32/ head 63
The data for partition 2 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
    start 102400, size 4134912 (2019 Meg), flag 80
	beg: cyl 50/ sector 1/ head 0;
	end: cyl 1023/ sector 32/ head 63
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

The fstab says:
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/sd0s2b		none		swap	sw		0	0
/dev/sd0a		/		ufs	rw		1	1
/dev/sd0s2g		/a		ufs	rw		2	2
/dev/sd0s2e		/usr		ufs	rw		2	2
/dev/sd0s2f		/usr/src	ufs	rw		2	2
proc			/proc		procfs	rw		0	0

Note that theye are no references to partition 1, not even a mount as
type MS-DOS.   Note also that we have not yet booted MS-DOS, so residue
from the old FreeBSD filesystem and slice data remain in the MS-DOS
portion of the disk.


On reboot, the kernel for some reason looked into the type 6 partition,
and saw the traces of the old slice data from the previous installation
of FreeBSD which still linger in the partition now reserved for MS-DOS,
and these messages came out:

Oct 24 21:30:48 skaro /kernel: changing root device to sd0a
Oct 24 21:30:48 skaro /kernel: sd0s1: raw partition size != slice size
Oct 24 21:30:48 skaro /kernel: sd0s1: start 32, end 102399, size 102368
Oct 24 21:30:48 skaro /kernel: sd0s1c: start 32, end 4237311, size 4237280
Oct 24 21:30:48 skaro /kernel: sd0s1: truncating raw partition
Oct 24 21:30:48 skaro /kernel: sd0s1: rejecting partition in BSD label: it isn't entirely within the slice
Oct 24 21:30:48 skaro /kernel: sd0s1: start 32, end 102399, size 102368
Oct 24 21:30:48 skaro /kernel: sd0s1a: start 32, end 307231, size 307200
Oct 24 21:30:48 skaro /kernel: sd0s1: rejecting partition in BSD label: it isn't entirely within the slice
Oct 24 21:30:48 skaro /kernel: sd0s1b: start 307232, end 512031, size 204800
Oct 24 21:30:48 skaro /kernel: sd0s1: rejecting partition in BSD label: it isn't entirely within the slice
Oct 24 21:30:48 skaro /kernel: sd0s1e: start 512032, end 2187295, size 1675264
Oct 24 21:30:48 skaro /kernel: sd0s1: rejecting partition in BSD label: it isn't entirely within the slice
Oct 24 21:30:49 skaro /kernel: sd0s1f: start 2187296, end 3211295, size 1024000
Oct 24 21:30:49 skaro /kernel: sd0s1: rejecting partition in BSD label: it isn't entirely within the slice
Oct 24 21:30:49 skaro /kernel: sd0s1g: start 3211296, end 4237311, size 1026016


Despite the alarming look of these messages, the slices that were supposed
to be found on partition 2 were found, and mounted sucessfully.

But to get the kernel to stop sticking its nose into the MS-DOS type 6
partition and putting these messages out on each boot, I had to install
MS-DOS in partition 1 and wipe out the remaining bits of the old FreeBSD
install.  I suspect the kernel is still looking in there, but isn't
finding anything it recognizes at all.


In my opinion, the slice code should not be investigating non-165-type
partitions for slices.   

>How-To-Repeat:

Install FreeBSD on entire disk.  Re-install, but define small MS-DOS
partition in first part of the disk, do not format or install MS-DOS yet,
then install FreeBSD in remainder of disk, and finally, reboot FreeBSD
and look at the boot messages.

>Fix:
	
I suggest testing the partition type for known-slicable partition values
before hunting for possible slice data in that partition.

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, uhclem@nemesis.lonestar.org
Cc:  Subject: Re: kern/4845: Boot complains about disk slices in FAT partitions - FDIV075
Date: Sat, 25 Oct 1997 16:18:49 +1000

 >On reboot, the kernel for some reason looked into the type 6 partition,
                                                               ^^^^^^^^^ slice
 >and saw the traces of the old slice data from the previous installation
              ^^^^^^^^^ all of  ^^^^^ partition
 >of FreeBSD which still linger in the partition now reserved for MS-DOS,
                                       ^^^^^^^^^ slice
 
 The reason is that there is nothing special about slice type 6.
 Slices of all types can be labeled.  Only slice type 165 is special.
 Its specialness is limited to 3 things:
 - the boot loader only looks at the first slice of type 165.
 - partitions on the first slice slice of type 165 are aliased to the
   historical BSD partitions.
 - a warning is printed for slices of type 165 that don't have a label.
 
 Versions before 2.2.0-Release did not search for labels until
 necessary, so labels inside an MS-DOS slice would not have been
 noticed until the slice is mounted or otherwise opened.
 
 >and these messages came out:
 >
 >Oct 24 21:30:48 skaro /kernel: changing root device to sd0a
 >Oct 24 21:30:48 skaro /kernel: sd0s1: raw partition size != slice size
 >Oct 24 21:30:48 skaro /kernel: sd0s1: start 32, end 102399, size 102368
 >Oct 24 21:30:48 skaro /kernel: sd0s1c: start 32, end 4237311, size 4237280
 >Oct 24 21:30:48 skaro /kernel: sd0s1: truncating raw partition
 >...
 
 >Despite the alarming look of these messages, the slices that were supposed
                                                   ^^^^^^ partitions
 >to be found on partition 2 were found, and mounted sucessfully.
                 ^^^^^^^^^ slice
 
 There is no problem unless the partitions on slice 1 are used.
 
 >But to get the kernel to stop sticking its nose into the MS-DOS type 6
 >partition and putting these messages out on each boot, I had to install
 >MS-DOS in partition 1 and wipe out the remaining bits of the old FreeBSD
 >install.  I suspect the kernel is still looking in there, but isn't
 >finding anything it recognizes at all.
 
 The label can be removed using dd or a disk editor on the whole
 disk slice (the whole disk slice must be used, since the label is
 excessively write protected for accesses via the slice containing
 the label).  This is fairly easy if the label is near the front of
 the disk.  Otherwise, limitations in utilities get in the way (dd
 doesn't understand that disks are seekable so it seeks by reading,
 and it doesn't support offsets >= 2G).
 
 Another reason to remove the label is to prevent it reappearing if
 you change the slice type back to 165.
 
 It may also important to remove metadata in MS-DOS slices.  Normally Use
 MS-DOS fdisk to give it a chance to clear the old BIOS Parameter Block.
 Don't use FreeBSD fdisk to change the slice type to a non-MSDOS type
 unless you clear the BPB in some way (installing FreeBSD boot blocks
 is sufficient to clear it).
 
 >In my opinion, the slice code should not be investigating non-165-type
 >partitions for slices.   
 
 Sorry, this is a feature (device independence).
 
 >>Fix:
 >	
 >I suggest testing the partition type for known-slicable partition values
 >before hunting for possible slice data in that partition.
 
 The bug is apparently really in sysinstall.  It should optionally clear
 old labels when changing slice tables significantly.
 
 Bruce
Responsible-Changed-From-To: freebsd-bugs->freebsd-qa 
Responsible-Changed-By: johan 
Responsible-Changed-When: Mon Aug 19 09:00:10 PDT 2002 
Responsible-Changed-Why:  
Bruce indicated that this is/was a sysinstall issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4845 
Responsible-Changed-From-To: freebsd-qa->qa 
Responsible-Changed-By: johan 
Responsible-Changed-When: Sat Aug 24 18:58:58 PDT 2002 
Responsible-Changed-Why:  
Use short names for mailing list to make searches 
using the web query form work with the shown responsible. 

This also makes open PR show up in the summery mail. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4845 
State-Changed-From-To: open->closed 
State-Changed-By: jhb 
State-Changed-When: Tue Nov 12 13:29:14 PST 2002 
State-Changed-Why:  
1) With GEOM this doesn't happen anymore (more along the lines of what the 
submitter suggested). 
2) Having sysinstall go and write zero's over the disk behind one's back is 
probably a Really Bad Idea (tm). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4845 
>Unformatted:
