Commit 44a000d9 authored by David Prévot's avatar David Prévot

[RN] Make it kFreeBSD-* ready (Closes: #690706) [ Baptiste ]

parent 4e9fca19
......@@ -14,10 +14,8 @@ endif
manual := release-notes
# TODO: This regexp does not match kfreebsd-i386 or kfreebsd-amd64 add '\-'
# to the arch= regex when they need to be enabled
arches := $(shell grep '<phrase arch=' $(CURDIR)/$(manual).ent \
| sed 's/.* arch=.\([a-z0-9]*\).*/\1/' | sort -u)
| sed 's/.* arch=.\([a-z0-9-]*\).*/\1/' | sort -u)
ifeq "$(OFFICIALWEBBUILD)" "true"
install_file := install -m 2664 -p
......
......@@ -16,7 +16,7 @@ bugs somewhere else. This section documents issues we are aware of. Please also
read the errata, the relevant packages' documentation, bug reports and other
information mentioned in <xref linkend="morereading"/>.
</para>
<section id="udev" condition="fixme">
<section id="udev" condition="fixme" arch="linux">
<title>Problems with devices related to udev</title>
<para>
Although <systemitem role="package">udev</systemitem> has been tested
......
......@@ -105,7 +105,9 @@ from the network if the lease time is lower than the time it takes for the
upgrade process to complete.</para></footnote>, you can reduce the downtime if
you do a minimal system upgrade, as described in <xref
linkend="minimal-upgrade"/>, followed by a kernel upgrade and reboot (see <xref
linkend="upgrading-udev"/>), and then upgrade the packages associated with your
arch="linux" linkend="upgrading-udev"/>
<xref arch="not-linux" linkend="upgrading-kernel"/>),
and then upgrade the packages associated with your
critical services. Upgrade these packages prior to doing the full upgrade
described in <xref linkend="upgrading-full"/>. This way you can ensure that
these critical services are running and available through the full upgrade
......@@ -132,7 +134,7 @@ bring up networking.
<!-- FIXME: Is there a risk in Lenny for this to happen? -->
<!-- Another option would be an automatic reboot to a previous kernel using
Davor Ocelic's testnet script or similar -->
<para>
<para arch="linux">
If you are upgrading remotely via an <command>ssh</command> link it is highly
recommended that you take the necessary precautions to be able to access the
server through a remote serial terminal. There is a chance that, after
......@@ -142,6 +144,16 @@ configuration through a local console. Also, if the system is rebooted
accidentally in the middle of an upgrade there is a chance you will need to
recover using a local console.
</para>
<para arch="not-linux">
If you are upgrading remotely via an <command>ssh</command> link it is highly
recommended that you take the necessary precautions to be able to access the
server through a remote serial terminal. There is a chance that, after
upgrading the kernel and rebooting, you will have to fix the system
configuration through a local console. Also, if the system is rebooted
accidentally in the middle of an upgrade there is a chance you will need to
recover using a local console.
</para>
<!-- FIXME: The next paragraph might not be true for Lenn? -->
<para>
The most obvious thing to try first is to reboot with your old kernel.
......@@ -879,7 +891,7 @@ and a full upgrade cannot be run due to space constrains.
that this is not absolutely required, users could do a dist-upgrade
and then reboot. This is, however, the recommended path to be on the
safe side -->
<section id="upgrading-udev">
<section id="upgrading-udev" arch="linux">
<title>Upgrading the kernel and udev</title>
<para>
The <systemitem role="package">udev</systemitem> version in &releasename;
......@@ -966,6 +978,19 @@ once you have upgraded both the kernel and <systemitem role="package">udev</sys
</section>
<!--Maybe this little section for kfreebsd-* is useless ...-->
<section id="upgrading-kernel" arch="not-linux">
<title>Upgrading the kernel</title>
<para>
You should reboot the system
<footnote><para>If you are logging the upgrade as described in
<xref linkend="upgradingpackages"/>, please, use <command>script</command> again
to log the next steps of the upgrade after the reboot in order to log the
result of the actions described in <xref linkend="upgrading-full"/>.
</para></footnote>
once you have upgraded the kernel.
</para>
</section>
<section id="upgrading-full">
<title>Upgrading the system</title>
......@@ -1044,7 +1069,7 @@ execute the following commands:
</para>
</section>
<section id="cryptoloop">
<section id="cryptoloop" arch="linux">
<title>cryptoloop support not included in the &releasename; Linux kernel</title>
<para>
Support for cryptoloop has been dropped from the Linux kernel packages
......@@ -1263,7 +1288,7 @@ entries. You should use <command>visudo</command> for this:
</section>
<!-- TODO: need to be reviewed with information from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571255 -->
<section id="newkernel">
<section id="newkernel" arch="linux">
<title>Upgrading your kernel and related packages</title>
<para>
This section explains how to upgrade your kernel and identifies potential
......@@ -1363,7 +1388,7 @@ need to delete the associated entry from
<!-- FIXME: REVIEW for Squeeze this was written for Lenny - drop? (jfs) -->
<section id="boot-timing">
<title>Boot timing issues</title>
<para>
<para arch="linux">
If an initrd created with <systemitem
role="package">initramfs-tools</systemitem> is used to boot the system, in some
cases the creation of device files by <systemitem
......@@ -1508,7 +1533,7 @@ please consult it in case of problems.
upgrading, read ahead.
</para>
<section id="avoid-problems-before-upgrading">
<section id="avoid-problems-before-upgrading" arch="linux">
<title>How to avoid the problem before upgrading</title>
<para>
......@@ -1658,7 +1683,7 @@ please consult it in case of problems.
<!-- FIXME: This section might not be relevant anymore for Squeeze
but could be turned into a generic section on how to recover from
issues -->
<section id="how-to-recover">
<section id="how-to-recover" arch="linux">
<title>How to recover from the problem after the upgrade</title>
<section id="solution1">
......
......@@ -80,7 +80,9 @@ Remember, this is XML; the *first* definition of an ENTITY wins.
--><phrase arch='powerpc'>powerpc</phrase><!--
--><phrase arch='sparc'>sparc</phrase><!--
--><phrase arch='s390'>s390</phrase><!--
--><phrase arch='s390x'>s390x</phrase>">
--><phrase arch='s390x'>s390x</phrase><!--
--><phrase arch='kfreebsd-i386'>kfreebsd-i386</phrase><!--
--><phrase arch='kfreebsd-amd64'>kfreebsd-amd64</phrase>">
<!-- proper nouns for architectures -->
<!ENTITY arch-title "<phrase arch='alpha'>Alpha</phrase><!--
......@@ -94,7 +96,9 @@ Remember, this is XML; the *first* definition of an ENTITY wins.
--><phrase arch='powerpc'>PowerPC</phrase><!--
--><phrase arch='sparc'>SPARC</phrase><!--
--><phrase arch='s390'>S/390</phrase><!--
--><phrase arch='s390x'>IBM System z</phrase>">
--><phrase arch='s390x'>IBM System z</phrase><!--
--><phrase arch='kfreebsd-i386'>kFreeBSD 32-bits PC</phrase><!--
--><phrase arch='kfreebsd-amd64'>kFreeBSD 64-bits PC</phrase>">
<!-- default kernel version, taken from d-i... -->
<!ENTITY kernelversion "<phrase arch='amd64'>3.2</phrase><!--
......@@ -107,4 +111,6 @@ Remember, this is XML; the *first* definition of an ENTITY wins.
--><phrase arch='powerpc'>3.2</phrase><!--
--><phrase arch='sparc'>3.2</phrase><!--
--><phrase arch='s390'>3.2</phrase><!--
--><phrase arch='s390x'>3.2</phrase>">
--><phrase arch='s390x'>3.2</phrase><!--
--><phrase arch='kfreebsd-i386'>9.0</phrase><!--
--><phrase arch='kfreebsd-amd64'>9.0</phrase>">
......@@ -40,7 +40,7 @@ if [ ! -e "Makefile" ] ; then
fi
# Extract the information
arches=`grep '<phrase arch=' $name.ent | sed 's/.* arch=.\([a-z0-9]*\).*/\1/' | sort -u`
arches=`grep '<phrase arch=' $name.ent | sed 's/.* arch=.\([a-z0-9-]*\).*/\1/' | sort -u`
langs=`grep "^LANGUAGES " Makefile | sed 's/.*=//'`
# Check if the information we have is OK to proceeded
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment