d0b8716702
1. Bring floppies.sgml section in-line into install.sgml, where it makes more sense. 2. Slightly reorganize some sections of Installation section and do some wordsmithing. 3. Update distribution layout to reflect RELNOTESng and new compat distributions. 4. Update upgrade file list from 4-STABLE. 5. It's been a long time since 2.2.X; get rid of instructions dealing with "new" handling of compatability slices and fix up other references in the text. 6. Hunt down and kill emoticons with extreme prejudice. Try to tone down the use of exclamation points. 7. Cross-reference new and improved Installation chapter in Handbook. 8. Add a proper abstract for this document.
203 lines
7.2 KiB
Plaintext
203 lines
7.2 KiB
Plaintext
<!--
|
|
$FreeBSD$
|
|
|
|
This section contains the contents of the old UPGRADE.TXT
|
|
file.
|
|
-->
|
|
<sect1 id="upgrading">
|
|
<title>Upgrading &os;</title>
|
|
|
|
<para>These instructions describe a procedure for doing a binary
|
|
upgrade from an older version of &os;.</para>
|
|
|
|
<warning>
|
|
<para>While the &os; upgrade procedure does its best to
|
|
safeguard against accidental loss of data, it is still more than
|
|
possible to <emphasis>wipe out your entire disk</emphasis> with
|
|
this installation! Please do not accept the final confirmation
|
|
request unless you have adequately backed up any important data
|
|
files.</para>
|
|
</warning>
|
|
|
|
<important>
|
|
<para>These notes assume that you are using the version of
|
|
&man.sysinstall.8; supplied with the version of &os; to which you
|
|
intend to upgrade. Using a mismatched version of &man.sysinstall.8; is
|
|
almost guaranteed to cause problems and has been known to leave
|
|
systems in an unusable state. The most commonly made mistake in
|
|
this regard is the use of an old copy of &man.sysinstall.8; from
|
|
an existing installation to upgrade to a newer version of
|
|
&os;. This is <emphasis>not</emphasis> recommended.</para>
|
|
</important>
|
|
|
|
<sect2>
|
|
<title>Introduction</title>
|
|
|
|
<para>The upgrade procedure replaces distributions selected by the
|
|
user with those corresponding to the new &os; release. It
|
|
preserves standard system configuration data, as well as user
|
|
data, installed packages and other software.</para>
|
|
|
|
<para>Administrators contemplating an upgrade are encouraged to
|
|
study this section in its entirety before commencing an upgrade.
|
|
Failure to do so may result in a failed upgrade or loss of data.</para>
|
|
|
|
<sect3>
|
|
<title>Upgrade Overview</title>
|
|
|
|
<para>Upgrading of a distribution is performed by extracting the
|
|
new version of the component over the top of the previous
|
|
version. Files belonging to the old distribution are not
|
|
deleted.</para>
|
|
|
|
<para>System configuration is preserved by retaining and
|
|
restoring the previous version of the following files:</para>
|
|
|
|
<para><filename>Xaccel.ini</filename>,
|
|
<filename>XF86Config</filename>,
|
|
<filename>adduser.conf</filename>,
|
|
<filename>aliases</filename>,
|
|
<filename>aliases.db</filename>,
|
|
<filename>amd.map</filename>,
|
|
<filename>crontab</filename>,
|
|
<filename>csh.cshrc</filename>,
|
|
<filename>csh.login</filename>,
|
|
<filename>csh.logout</filename>,
|
|
<filename>cvsupfile</filename>,
|
|
<filename>disktab</filename>,
|
|
<filename>dm.conf</filename>,
|
|
<filename>dumpdates</filename>,
|
|
<filename>exports</filename>,
|
|
<filename>fbtab</filename>,
|
|
<filename>fstab</filename>,
|
|
<filename>ftpusers</filename>,
|
|
<filename>gettytab</filename>,
|
|
<filename>gnats</filename>,
|
|
<filename>group</filename>,
|
|
<filename>hosts</filename>,
|
|
<filename>host.conf</filename>,
|
|
<filename>hosts.equiv</filename>,
|
|
<filename>hosts.lpd</filename>,
|
|
<filename>inetd.conf</filename>,
|
|
<filename>kerberosIV</filename>,
|
|
<filename>localtime</filename>,
|
|
<filename>login.access</filename>,
|
|
<filename>login.conf</filename>,
|
|
<filename>mail</filename>,
|
|
<filename>mail.rc</filename>,
|
|
<filename>make.conf</filename>,
|
|
<filename>manpath.config</filename>,
|
|
<filename>master.passwd</filename>,
|
|
<filename>modems</filename>,
|
|
<filename>motd</filename>,
|
|
<filename>namedb</filename>,
|
|
<filename>networks</filename>,
|
|
<filename>newsyslog.conf</filename>,
|
|
<filename>nsswitch.conf</filename>,
|
|
<filename>pam.conf</filename>,
|
|
<filename>passwd</filename>,
|
|
<filename>periodic</filename>,
|
|
<filename>ppp</filename>,
|
|
<filename>printcap</filename>,
|
|
<filename>profile</filename>,
|
|
<filename>pwd.db</filename>,
|
|
<filename>rc.conf</filename>,
|
|
<filename>rc.conf.local</filename>,
|
|
<filename>rc.firewall</filename>,
|
|
<filename>rc.local</filename>,
|
|
<filename>remote</filename>,
|
|
<filename>resolv.conf</filename>,
|
|
<filename>rmt</filename>,
|
|
<filename>sendmail.cf</filename>,
|
|
<filename>sendmail.cw</filename>,
|
|
<filename>services</filename>,
|
|
<filename>shells</filename>,
|
|
<filename>skeykeys</filename>,
|
|
<filename>spwd.db</filename>,
|
|
<filename>ssh</filename>,
|
|
<filename>syslog.conf</filename>,
|
|
<filename>ttys</filename>,
|
|
<filename>uucp</filename>
|
|
</para>
|
|
|
|
<para>The versions of these files which correspond to the new
|
|
version are moved to <filename>/etc/upgrade/</filename>. The
|
|
system administrator may peruse these new versions and merge
|
|
components as desired. Note that many of these files are
|
|
interdependent, and the best merge procedure is to copy all
|
|
site-specific data from the current files into the new.</para>
|
|
|
|
<para>During the upgrade procedure, the administrator is
|
|
prompted for a location into which all files from
|
|
<filename>/etc/</filename> are saved. In the event that local
|
|
modifications have been made to other files, they may be
|
|
subsequently retrieved from this location.</para>
|
|
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Procedure</title>
|
|
|
|
<para>This section details the upgrade procedure. Particular
|
|
attention is given to items which substantially differ from a
|
|
normal installation.</para>
|
|
|
|
<sect3>
|
|
<title>Backup</title>
|
|
|
|
<para>User data and system configuration should be backed up
|
|
before upgrading. While the upgrade procedure does its best
|
|
to prevent accidental mistakes, it is possible to partially or
|
|
completely destroy data and configuration information.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Mount Filesystems</title>
|
|
|
|
<para>The disklabel editor is entered with the nominated disk's
|
|
filesystem devices listed. Prior to commencing the upgrade, the
|
|
administrator should make a note of the device names and
|
|
corresponding mountpoints. These mountpoints should be entered
|
|
here. <emphasis>Do not</emphasis>set the <quote>newfs
|
|
flag</quote> for any filesystems, as this will cause data
|
|
loss.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Select Distributions</title>
|
|
|
|
<para>When selecting distributions, there are no constraints
|
|
on which must be selected. As a general rule, the <literal>bin</literal>
|
|
distribution should be selected for an update, and the <literal>man</literal>
|
|
distribution if manpages are already installed. Other
|
|
distributions may be selected beyond those originally
|
|
installed if the administrator wishes to add additional
|
|
functionality.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="fstab">
|
|
<title>After Installation</title>
|
|
|
|
<para>Once the installation procedure has completed, the
|
|
administrator is prompted to examine the new configuration
|
|
files. At this point, checks should be made to ensure that the
|
|
system configuration is valid. In particular, the
|
|
<filename>/etc/rc.conf</filename> and
|
|
<filename>/etc/fstab</filename> files should be checked.</para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Alternative Upgrade Techniques</title>
|
|
|
|
<para>Those interested in an upgrade method that allows more
|
|
flexibility and sophistication should take a look at the
|
|
<quote>Upgrading FreeBSD from source</quote> tutorial found at
|
|
http://www.FreeBSD.org/docs.html. This method requires reliable
|
|
network connectivity, extra disk space and spare time, but has
|
|
advantages for networks and other more complex
|
|
installations.</para>
|
|
</sect2>
|
|
</sect1>
|