[l10n-russian CVS] release-notes/sgml release-notes.en.sgml, 1.20,
1.21
Yuri Kozlov
yuray-guest at alioth.debian.org
Fri Apr 6 17:47:57 UTC 2007
Update of /cvsroot/l10n-russian/release-notes/sgml
In directory alioth:/tmp/cvs-serv14235/sgml
Modified Files:
release-notes.en.sgml
Log Message:
neushpelo
Index: release-notes.en.sgml
===================================================================
RCS file: /cvsroot/l10n-russian/release-notes/sgml/release-notes.en.sgml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- release-notes.en.sgml 4 Apr 2007 17:58:30 -0000 1.20
+++ release-notes.en.sgml 6 Apr 2007 17:47:55 -0000 1.21
@@ -74,7 +74,7 @@
<!-- TODO: any more things to add here? -->
<item><p>The status of your package database before and after the
upgrade: <prgn/dpkg/'s status database available at
- <file>/var/lib/dpkg/status</file> and <prgn/aptitudes/'s package
+ <file>/var/lib/dpkg/status</file> and <prgn/aptitude/'s package
state information, available at
<file>/var/lib/aptitude/pkgstates</file>. You should have made a
backup before the upgrade as described at <ref id="data-backup">,
@@ -288,7 +288,7 @@
<p><list>
<item>e-mail servers: Exim 4.63 (default email server
- for new installations), Postfix 2.3, Courier 0.53, Cyrus 2.2.</item>
+ for new installations), Postfix 2.3, Courier 0.53, Cyrus 2.2</item>
<!-- TODO: Cherokee, lighttpd, and Tomcat 5 are NEW -->
<!-- Note: No significant changes for Roxen4, Boa, and thttpd -->
@@ -476,9 +476,15 @@
<sect id="kernel-changes"><heading>Major kernel-related changes</heading>
<p>&debian; &release; ships with kernel version &kernelversion; for all
- architectures; the release is still mostly<footnote>Some individual
+ architectures; the release is still mostly
+<!-- JFS: Needed because of the cross ref, build errors will appear in some
+ architectures otherwise -->
+<![ %defaulted-2.4 [
+ <footnote>Some individual
packages may no longer work correctly with a 2.4 kernel; see
- <ref id="incompatible-2.4">.</footnote> compatible with 2.4 kernels, but
+ <ref id="incompatible-2.4">.</footnote>
+]]>
+ compatible with 2.4 kernels, but
Debian no longer provides or supports 2.4 kernel packages.</p>
<p>There have been major changes both in the kernel itself and in the
@@ -503,9 +509,9 @@
<![ %i386 [
<tag>Flavor "386" replaced with "486"</tag>
- <item><p>Support for the 80386 sub-architecture for Intel x86 has been
- dropped in &releasename;. The 386 kernel flavor is no longer supported
- and has been replaced by the new 486 flavor.</p></item>
+ <item><p>As support for 80386 processors was dropped with &oldreleasename;,
+ the 386 kernel flavor has now been dropped as well and replaced by a
+ new 486 flavor.</p></item>
]]>
<![ %amd64 [
<tag>Single generic kernel for &arch-title;</tag>
@@ -583,12 +589,14 @@
</sect1>
- <sect1 id="kernel-devfs"><heading>Dynamic <file>/dev</file> management</heading>
+ <sect1 id="kernel-udev">
+ <heading>Dynamic <file>/dev</file> management and hardware discovery</heading>
<p>&releasename; kernels no longer provide support for <tt>devfs</tt>.</p>
- <p>The replacement for <tt>devfs</tt> is <package/udev/.
- <p><package/udev/ is a userspace implementation of devfs. It is mounted
+ <p>The replacement for <tt>devfs</tt> is <package/udev/, a userspace
+ implementation of devfs.</p>
+ <p><package/udev/ is mounted
over the <file>/dev</file> directory and will populate that directory
with devices supported by the kernel. It will also dynamically add and
remove devices as kernel modules are loaded or unloaded respectively,
@@ -596,12 +604,24 @@
versatile than <tt/devfs/ and offers services that are used by other
packages like <package/hal/ (hardware abstraction layer).</p>
+ <p>In combination with the kernel, <package/udev/ also takes care of
+ hardware discovery and module loading for detected devices. Because of
+ this it conflicts with <package/hotplug/.
+ In &oldreleasename;, <package/discover/ could also be used for loading
+ modules during the boot process, but its new version in &releasename; no
+ longer provides that function.
+<![ %not-s390 [
+ <package/discover/ is still used by X.Org to detect what graphics
+ controller is present in the system.
+]]>
+ </p>
+
<![ %uses-initrd [
<p>If you install a Debian kernel image, <package/udev/ will be installed
by default as <package/initramfs-tools/ depends on it.</p>
<p>You can avoid installing <package/udev/ by compiling a custom non-modular
kernel or by using an alternative initrd generator, such as <package/yaird/.
- However, <package/initramfs-tools/ is the recommended initrd generator.
+ However, <package/initramfs-tools/ is the recommended initrd generator.</p>
]]>
</sect1>
@@ -633,7 +653,7 @@
support the SRM console. Be sure to switch your system to SRM before
starting the installation. If your machine supports only the AlphaBIOS/ARC
console, the recommended way to install &releasename; is to first install
- a (minimal) woody system, the upgrade to &oldreleasename; and finally to
+ a (minimal) woody system, then upgrade to &oldreleasename; and finally to
&releasename;. For more information about the different consoles please
read the references on the <url id="http://www.debian.org/ports/alpha"
name="Debian alpha port web pages">.
@@ -948,7 +968,7 @@
planning, although users accessing your system via an <prgn/ssh/
connection should notice little during the upgrade, and should be
able to continue working. </p>
-
+
<p>If you wish to take extra precautions, back up or
unmount users' partitions (<file>/home</file>) before upgrading.</p>
@@ -962,6 +982,78 @@
</sect1>
+ <sect1 id="recovery"><heading>Prepare for recovery</heading>
+
+ <p>Because of the many changes in the kernel between &oldreleasename;
+ and &releasename; regarding drivers, hardware discovery and the
+ naming and ordering of device files, there is a real risk that you
+ may experience problems rebooting your system after the upgrade.
+ A lot of known potential issues are documented in this and the next
+ chapters of these Release Notes.</p>
+
+ <p>For that reason it makes sense to ensure that you will be able to
+ recover if your system should fail to reboot or, for remotely managed
+ systems, fail to bring up networking.</p>
+
+<!-- JFS: probably can be removed for lenny -->
+ <p>If you are upgrading remotely via an <prgn/ssh/ 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, some devices will
+ be renamed (as described in <ref id="device-reorder">) and 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.</p>
+<!-- END - remove for lenny -->
+
+ <p>The most obvious thing to try first is to reboot with your
+ old kernel. However, for various reasons documented elsewhere in this
+ document, this is not guaranteed to work.</p>
+
+ <p>If that fails, you will need an alternative way to boot your
+ system so you can access and repair it. One option is to use a
+ special rescue image or a Linux live CD. After booting from that,
+ you should be able to mount your root file system and <tt/chroot/
+ into it to investigate and fix the problem.</p>
+
+ <p>Another option we'd like to recommend is to use the
+ <em/rescue mode/ of the &releasename; Debian Installer. The advantage
+ of using the installer is that you can choose between its many
+ installation methods for one that best suits your situation.
+ For more information, please consult the section
+ "Recovering a Broken System" in chapter 8 of the
+ <url id="&url-install-manual;" name="Installation Guide"> and the
+ <url id="http://wiki.debian.org/DebianInstaller/FAQ"
+ name="Debian Installer FAQ">.</p>
+
+<![ %uses-initrd [
+ <sect2 id="recovery-initrd"><heading>Debug shell during boot using initrd</heading>
+ <p>The <package/initramfs-tools/ includes a debug shell<footnote>
+ This feature can be disabled by adding the parameter <tt/panic=0/
+ to your boot parameters.</footnote> in the initrds it generates.
+ If for example the initrd is unable to mount your root file system,
+ you will be dropped into this debug shell which has basic commands
+ available to help trace the problem and possibly fix it.</p>
+
+ <p>Basic things to check are:
+ presence of correct device files in <file>/dev</file>;
+ what modules are loaded (<tt>cat /proc/modules</tt>);
+ output of <prgn/dmesg/ for errors loading drivers.
+ The output of <prgn/dmesg/ will also show what device files have
+ been assigned to which disks; you should check that against the
+ output of <tt/cat $ROOT/ to make sure that the root file system
+ is on the expected device.</p>
+
+ <p>If you do manage to fix the problem, typing <tt/exit/ will
+ quit the debug shell and continue the boot process at the point
+ it failed. Of course you will also need to fix the underlying
+ problem and regenerate the initrd so the next boot won't fail
+ again.</p>
+ </sect2>
+]]>
+
+ </sect1>
+
<sect1 id="upgrade_preparations"><heading>Prepare a safe environment for the upgrade</heading>
<p>The distribution upgrade should be done either locally from a
@@ -974,17 +1066,6 @@
the upgrade process is not interrupted even if the remote connection
process fails.</p>
-<!-- JFS: probably can be removed for lenny -->
- <p>If you are upgrading remotely via an <prgn/ssh/ link it is highly
- recommended that you take the necessary precautions to be able to
- access the server through a remote serial terminal. There are chances
- that, after upgrading the kernel and rebooting, some devices will
- be renamed (as described in <ref id="device-reorder">) and 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 are chances you will need to recover using a local console.</p>
-<!-- END - remove for lenny -->
-
<p><strong/Important!/ You should <em/not/ upgrade using <prgn/telnet/,
<prgn/rlogin/, <prgn/rsh/, or from an X session managed by <prgn/xdm/,
<prgn/gdm/ or <prgn/kdm/ etc on the machine you are upgrading. That is
@@ -1351,7 +1432,6 @@
scrolled off-screen. Just switch to VT2 (using <tt/Alt-F2/) and, after
logging in, use <tt>less -R ~root/upgrade-&releasename;.script</tt>
to view the file.</p>
-
<p>After you have completed the upgrade, you can stop <prgn/script/
by typing <tt/exit/ at the prompt.</p>
@@ -1360,7 +1440,7 @@
have not dumped the timing file -->
<p>If you have used the <em>-t</em> switch for <prgn/script/
you can use the <prgn/scriptreplay/ program to replay the whole session:
-
+
<example>
# scriptreplay ~/upgrade-&releasename;.time ~/upgrade-&releasename;.script
</example>
@@ -1787,14 +1867,30 @@
<sect id="newkernel"><heading>Upgrading your kernel and related
packages</heading>
- <p>You should upgrade the Linux kernel separately from the rest of
- your packages.
-<!-- TODO: add something in "before you upgrade", and get the order right -->
- You may wish to do so yourself, either by installing one
- of the <package/linux-image-*/ packages or by compiling a customized
- kernel from sources.
- Please read the information in this section about potential issues
- with kernel upgrades.</p>
+ <p>This section explains how to upgrade your kernel and identifies
+ potential issues related to this upgrade. You can either install one of
+ the <package/linux-image-*/ packages provided by Debian, or compile a
+ customized kernel from source.</p>
+
+<![ %uses-initrd [
+ <p>Note that a lot of information in this section is based on the
+ assumption that you will be using one of the modular Debian kernels,
+ together with <package/initramfs-tools/ and <package/udev/. If you
+ choose to use a custom kernel that does not require an initrd or
+ if you use a different initrd generator, some of the information may not be
+ relevant for you.</p>
+]]>
+<![ %no-initrd [
+ <p>Note that this section contains a lot of information related to
+ the use of <package/initramfs-tools/ and <package/udev/. However,
+ as the Debian kernels for &architecture; do not use an initrd to
+ boot the system, some of this information may not be relevant for
+ you. The information is still included as you may have
+ <package/udev/ installed for other reasons.</p>
+]]>
+ <p>Note also that if <package/udev/ is <em/not/ installed on your
+ system, it is still possible to use <package/hotplug/ for
+ hardware discovery.</p>
<![ %defaulted-2.4 [
<p>If you are currently using a 2.4 kernel, you should also read
@@ -2022,7 +2118,24 @@
</sect1>
]]>
+<![ %uses-initrd [
+<!-- #417643 -->
+ <sect1 id="boot-timing"><heading>Boot timing issues</heading>
+ <p>If an initrd created with <package/initramfs-tools/ is used to
+ boot the system, in some cases the creation of device files by
+ <package/udev/ can happen too late for the boot scripts to act on.</p>
+ <p>The usual symptoms are that the boot will fail because the root
+ file system cannot be mounted and you are dropped into a debug shell,
+ but that when you check afterwards, all devices that are needed are
+ present in <file>/dev</file>. This has been observed in cases where
+ the root file system is on a USB disk or on RAID.</p>
+ <p>A workaround for this issue is to use the boot parameter
+ <tt>rootdelay=<var/9/</tt>. The value for the timeout (in seconds) may
+ need to be adjusted.</p>
+
+ </sect1>
+]]>
</sect>
<sect id="nownownow"><heading>Things to do before rebooting</heading>
@@ -2038,7 +2151,7 @@
<p>If you see the string 'devfs' in <file>/proc/mounts</file>,
you are most likely using <tt>devfs</tt>.
- Any config files that reference <tt>devfs</tt>-style names will need to be
+ Any configuration files that reference <tt>devfs</tt>-style names will need to be
adjusted to use <package>udev</package>-style names. Files that are likely to
refer to <tt>devfs</tt>-style device names include <file>/etc/fstab</file>,
<file>/etc/lilo.conf</file>, <file>/boot/grub/menu.lst</file>, and <file>/etc/inittab</file>.</p>
@@ -2060,6 +2173,7 @@
<example>
# update-initramfs -u -k all
</example></p>
+ </sect1>
]]>
<![ %hppa [
@@ -2107,16 +2221,8 @@
see <em/LI/ when booting the system<footnote>For more information on
<prgn/lilo/'s boot error codes please see <url
id="http://tldp.org/HOWTO/Bootdisk-HOWTO/a1483.html" name="The Linux
- Bootdisk HOWTO">.</footnote>. In order to
- recover from this you will have to start up a media installation disk
- in <em/rescue/ mode. For
- more information on how to do this please review the Debian Installer's
- Manual chapter <url
- id="http://www.debian.org/releases/etch/i386/ch08s07.html"
- name="Recovering a Broken System"> and the
- <url
- id="http://wiki.debian.org/DebianInstaller/FAQ" name="Debian Installer
- FAQ">.</p>
+ Bootdisk HOWTO">.</footnote>. See <ref id="recovery"> for information
+ on how to recover from this.</p>
</sect1>
]]>
@@ -2179,7 +2285,7 @@
</example></p>
<p>Other dasd devices (dasds not needed to bring up the root file
- system are enabled through configuration files in
+ system) are enabled through configuration files in
<file>/etc/sysconfig/hardware/</file>. For a regular dasd, you just
need to touch a file with the device path in its name:
<example>
@@ -2435,7 +2541,7 @@
<!-- JFS: Bug #376158 -->
<sect1 id="apt-pdiff"><heading>Slower updates of APT package index files</heading>
- <p>By default, the &releasename version of <prgn>apt</prgn> uses a
+ <p>By default, the &releasename; version of <prgn>apt</prgn> uses a
new way to update APT package
index files (when you run <tt/aptitude update/) which downloads differences
files (instead of the full package index file) called <tt/pdiff/. This new
@@ -2514,9 +2620,41 @@
in Debian can be found in the <url id="http://wiki.debian.org/WPA"
name="Debian Wiki">.</p>
</sect1>
- </sect>
]]>
+ <sect1 id="partitionenc"><heading>Problems with non-ASCII characters in filenames</heading>
+ <p>
+ Mounting vfat, ntfs or iso9660 file systems with files that include
+ non-ASCII characters in their filenames will give failures when one
+ tries to use the filenames unless mounting is done with the utf8
+ option. An indication might be the following failure: 'Invalid or
+ incomplete multibyte or wide character'. A possible solution is to
+ use <tt>defaults,utf8</tt> as mount options for vfat, ntfs and iso9660
+ file systems when they contain filenames with non-ASCII characters.
+ </p>
+ <p>Note that the Linux kernel does not support case-insensitive
+ filename handling for vfat when the <tt>utf8</tt> option is used.</p>
+ </sect1>
+
+<![ %amd64 [
+ <sect1 id="nvidia-iommu"><heading>Data corruption with Hardware IOMMU on Nvidia chipsets</heading>
+ <p>A problem has been identified on &arch-title; systems with Nvidia
+ chipsets and more than 3GB of RAM that causes sporadic data corruption
+ when the hardware IOMMU is used. This problem is still under
+ investigation by the Linux kernel developers and the hardware
+ manufacturers, and no official upstream fix has been released. To
+ protect the integrity of their data, users of these systems are advised
+ to manually disable the use of hardware IOMMU at boot time by adding
+ <tt>iommu=soft</tt> to their kernel boot options until a correct solution
+ can be found.</p>
+ <p>More information about this issue is available in Debian bug
+ <url id="http://bugs.debian.org/404148" name="#404148">
+ and Linux Kernel bug
+ <url id="http://bugzilla.kernel.org/show_bug.cgi?id=7768" name="#7768">.</p>
+ </sect1>
+]]>
+ </sect>
+
<!-- Controversial, disabled for now, please translate though
<sect id="german-quotes"><heading>Problems with German Quotes</heading>
@@ -2721,7 +2859,7 @@
because the Cairo 2D vector graphics library (<package/libcairo2/)
doesn't have 8-bit pseudocolor support. This library is used by the GNOME
and Xfce desktops as well as by many desktop applications compiled
- with the Gtk2+ toolikt, such as <package/abiword/.</p>
+ with the Gtk2+ toolkit, such as <package/abiword/.</p>
<!-- TODO: make this arch-specific ? This applies to remote terminals, so
it might not make sense to make it arch-specific ... -->
@@ -2807,7 +2945,7 @@
<sect id="zope"> <heading>Upgrading Zope and Plone</heading>
<p>Zope and all related products have been updated. Many products were
also dropped from the distribution (either because they were obsoleted,
- or because they are incompatible with the newer Zope, CMF or Plone.</p>
+ or because they are incompatible with the newer Zope, CMF or Plone).</p>
<p>Unfortunately there is no easy and guaranteed way to upgrade a
complex <prgn/zope/ or <prgn/plone/ server. Even though Plone includes
a migration tool, experience has shown that automatic migrations
@@ -2921,7 +3059,7 @@
not properly handle your old configuration and might not behave properly.</p>
<p>If you have not heavily invested in configuring your GNOME desktop
- you might want to move the the <file>.gconf</file> directory in user's
+ you might want to move the <file>.gconf</file> directory in user's
home directories to a different name (such as <file>.gconf.old</file>)
so that it gets recreated, with the default configuration for
&releasename;, upon starting a new session.</p>
More information about the l10n-russian-cvs-commits
mailing list