From owner-FreeBSD-users-jp@jp.freebsd.org  Fri Mar 13 10:38:45 1998
Received: by jaz.jp.freebsd.org (8.8.8+3.0Wbeta7/8.7.3) id KAA25219
	Fri, 13 Mar 1998 10:38:45 +0900 (JST)
Received: by jaz.jp.freebsd.org (8.8.8+3.0Wbeta7/8.7.3) with ESMTP id KAA25214
	for <FreeBSD-users-jp@jp.freebsd.org>; Fri, 13 Mar 1998 10:38:44 +0900 (JST)
From: yamagata@nwgpc.kek.jp
Received: from nwgpc.kek.jp (localhost [127.0.0.1])
	by nwgpc.kek.jp (8.8.8/nwgpc-98.3.9) with ESMTP id KAA04082;
	Fri, 13 Mar 1998 10:38:42 +0900 (JST)
To: FreeBSD-users-jp@jp.freebsd.org
In-Reply-To: Your message of "Fri, 13 Mar 1998 00:32:41 +0900"
	<199803121532.AAA15702@ccs02.sfc.keio.ac.jp>
References: <199803121532.AAA15702@ccs02.sfc.keio.ac.jp>
X-Mailer: Mew version 1.93b12 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-Id: <19980313103842B.yamagata@nwgpc.kek.jp>
Date: Fri, 13 Mar 1998 10:38:42 +0900
X-Dispatcher: imput version 980210
Lines: 128
Reply-To: FreeBSD-users-jp@jp.freebsd.org
Precedence: bulk
X-Distribute: distribute [version 2.1 (Alpha) patchlevel=24]
X-Sequence: FreeBSD-users-jp 25866
Subject: [FreeBSD-users-jp 25866] Re: 2.2.6-980311-BETA
Errors-To: owner-FreeBSD-users-jp@jp.freebsd.org
Sender: owner-FreeBSD-users-jp@jp.freebsd.org

$B$3$s$K$A$O!";37A$G$9!#(B

In message <199803121532.AAA15702@ccs02.sfc.keio.ac.jp>,
Takaaki Nomura ($BLnB<9bL@(B) wrote

>   releng22.freebsd.org $B$K(B 2.2.6-980311-BETA $B$,CV$$$F$"$C$?$N$G!"$5$C$=$/(B
> 2.2-980204-SNAP $B$N(B upgrade $B$r;n$_$?$N$G$9$,!"(BDisklabel Editor $B$G!"(BDisk
> $B$O!"(Bwd1, sd1, sd2($B3F!9!"(BNetBSD 1.3, FreeBSD 3.0-971225-SNAP, FreeBSD 2.2-
> 980204-SNAP $B$,F~$C$F$$$k(B)$B$OG'<1$5$l$F$$$k$K$b$+$+$o$i$:!"(Bmount $B$G$-$k%Q!<(B
> $B%F%#%7%g%s$O2?8N$+(B wd0s2(PC-DOS)$B$N$_$G$9!#$*$+$7$$$J!"$H;W$C$F(B 2.2-980204-
> SNAP $B$N(B boot.flp $B$GN)$A>e$2$F$_$^$7$?$,!"$d$O$jF1$8$G$9!#$=$l$G$O$H!"IaCJ(B
> $B7R$$$G$$$J$$(B 2.2.5-RELEASE $B$N%G%#%9%/$r!":#2s(B upgrade $B$r;n$_$?%G%#%9%/$N(B
> $BBe$o$j$K7R$$$G!"(Bwd1, sd1 $B$N(B disklabel $B$r8+$k$H!"2?$H(B c partition $B$7$+L5$/(B
> $B$J$C$F$$$^$9!#$3$l$OBg%7%g%C%/$G$9!#(B(+_+) (;_;)
> 
>   2.2.6-980311-BETA $B$rL5;v$K%$%s%9%H!<%k$G$-$?J}$O$$$i$C$7$c$$$^$9$+!)(B

$B$R$g$C$H$7$F$3$l$8$c$J$$$G$7$g$&$+!#(B

From: Mike Smith <mike@smith.net.au>
Subject: *HEADS UP*  Important change warning. (long version)
To: stable@FreeBSD.ORG
Date: Sun, 08 Mar 1998 18:49:34 -0800
Message-Id: <199803090249.SAA12529@dingo.cdrom.com>
X-Mailer: exmh version 2.0zeta 7/24/97
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-stable@FreeBSD.ORG
X-Filter: mailagent [version 3.0 PL58] for yamagata@nwgpc.kek.jp


There is a subtle but significant change coming to the 2.2.5-STABLE 
branch which may cause problems under some circumstances.  Please read 
the following carefully, to ensure that the transition does not cause
you any problems.

This change only affects systems which are booted from a sliced disk, 
that is, a disk where the FreeBSD partitions are contained within a 
DOS-style partition (and possibly share the disk with other operating 
systems).  It has no impact for systems which boot from dedicated
disks.

Explanation:  (You can skip this if you're not interested in 'why')
------------
When FreeBSD boots from a partition within a BSD slice, it makes use of
a feature known as the "compatability slice".  Slices are typically
identified with the nomenclature xdNsM, where N and M are numbers
representing the disk and slice number respectively.  The "compatability
slice" provides a shorthand naming scheme where the first BSD slice, ie.
the lowest M for a given N also appears as xdN.

For example, consider an IDE disk with a DOS slice first, and with
FreeBSD occupying the remainter of the disk.  The slice 'wd0s1' is the
DOS slice, and 'wd0s2' is the FreeBSD slice, with 'wd0s2a' being the 'a'
partition in the FreeBSD slice.  The "compatability slice" feature means
that you can refer to this 'a' partition as 'wd0a'.

The "compatability slice" feature is a historic leftover, and it will be
phased out in the next major release of FreeBSD.  Currently, the only
use of the compatability slice is when booting, where the root
filesystem is mounted from the 'a' partition via the compatability slice
rather than the correct slice.

This leads to an entry in /etc/fstab which is inconsistent with the 
remainder of the filesystems listed there.  Eg., persisiting with our
example from above, one might have an /etc/fstab reading:

/dev/wd0a	/	ufs...
/dev/wd0s2e	/usr	ufs...
/dev/wd0s2f	/var	ufs...

You cannot correct the root filesystem entry to read /dev/wd0s2a,
because the system believes that wd0a and wd0s2a are different, and it
has mounted wd0a on / already (in order to boot from it).

Nature of the Change:
---------------------
The kernel will correctly mount the appropriate slice device on / when 
booting.  This means that when the filesystems are remounted later in 
the boot process, the entry for / in /etc/fstab must be correct.

This results in a backwards-compatability issue, where a system which
has just been updated has an /etc/fstab with the old compatability slice
entry cannot be booted.

In order to address this change, the mount utility has been updated to 
locate and use the correct slice entry if asked to mount the root 
filesystem from what appears to be a compatability slice device.

This allows the system administrator to leave the old, compatability
slice syntax in /etc/fstab until such time as it is no longer required.
The mount utility will emit a warning diagnostic to provide a reminder 
that the change has not been made.

Potential for Problems:
-----------------------
If an updated kernel is used without also updating the mount utility, 
a system booting from a sliced disk will fail to boot correctly.

Following the standard upgrade procedure:

 - Update sources (eg. CVSup, CTM)
 - 'make world'
 - build new kernel
 - reboot

will result in the mount utility being correctly updated.

The mount utility may also be manually updated, in the case where 'make 
world' is too time-consuming.

Recovering from Boot Failure:
-----------------------------
In the case where the kernel has been updated inadvertently and the 
boot process has failed due to a mismatch when attepting to mount the 
root filesystem, the recommended recovery procedure is to boot from the 
backup kernel 'kernel.old' and rebuild the mount utility.

-- 
\\  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
