[l10n-russian CVS] release-notes/sgml release-notes.en.sgml, 1.10, 1.11

Yuri Kozlov yuray-guest at alioth.debian.org
Wed Mar 28 19:06:05 CET 2007


Update of /cvsroot/l10n-russian/release-notes/sgml
In directory alioth:/tmp/cvs-serv12932/sgml

Modified Files:
	release-notes.en.sgml 
Log Message:


Index: release-notes.en.sgml
===================================================================
RCS file: /cvsroot/l10n-russian/release-notes/sgml/release-notes.en.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- release-notes.en.sgml	27 Mar 2007 18:14:08 -0000	1.10
+++ release-notes.en.sgml	28 Mar 2007 18:06:03 -0000	1.11
@@ -642,6 +642,8 @@
           directly related to the upgrade process but which could still be
           relevant.</p>
 
+       <sect1><heading>Backup any data or configuration information</heading>
+ 
           <p>Before upgrading your system, it is strongly recommended that
           you make a full backup, or at least backup any data or
           configuration information you can't afford to lose. The upgrade
@@ -663,26 +665,40 @@
           backup may help to restore or recreate the old settings. You may
           also want to inform users about this.</p>
 
+       </sect1>
+
+       <sect1><heading>Inform users in advance</heading>
+
           <p>It's wise to inform all users in advance of any upgrades you're
           planning, although users accessing your system via an <prgn/ssh/
           connection should notice little during the upgrade, and should be
-          able to continue working. If you wish to take extra precautions, back up or
+          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>
 
-<!-- JFS: Not true in etch 
+<!-- JFS: Not true in etch, maybe for lenny?
           <p>A reboot will not normally be necessary, unless you also plan to
           upgrade your kernel.</p>
 -->
           <p>You will probably have to do a kernel upgrade when upgrading to 
-          &releasename;, so a reboot will normally be necessary. Typically, this 
-          will be done after the upgrade is finished.</p>
-          
-          <!-- TODO: Is not necessary to change the kernel? e.g. udev ? -->
+          &releasename;, so a reboot will normally be necessary. Typically,
+          this will be done after the upgrade is finished.</p>
+
+       </sect1>
+
+       <sect1><heading>Prepair a safe environment for the upgrade</heading>
 
           <p>Distribution upgrade should be done either locally from a
           textmode virtual console (or a directly connected serial
           terminal), or remotely via an <prgn/ssh/ link.</p>
 
+          <p>In order to gain extra safety margin, we suggest you to run
+          upgrade processes in the virtual console provided by the
+          <prgn/screen/ program which enables the safe reconnection and ensures
+          the uninterrupted upgrade processes even if the remote connection
+          process fails by chance.</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
@@ -693,7 +709,7 @@
           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
@@ -702,6 +718,7 @@
           half-upgraded.</p>
 
           <!-- TODO: surely gdm/kdm are sane? -->
+       </sect1>
 
           <p>Any package installation operation must be run with superuser
           privileges, so either login as root or use <prgn/su/ or
@@ -710,6 +727,17 @@
           <p>The upgrade has a few preconditions; you should check them
           before actually executing the upgrade.</p>
 
+       </sect1>
+
+       <sect1><heading>Review actions pending in package manager</heading>
+
+       <P>TODO</p>
+
+       <p>Run aptitude interactively and check that there are no packages
+       scheduled for removal or update (if a packages was installed with
+       apt-get, aptitude may sometimes not know about it and list it for
+       removal; in general, the system should be up-to-date and "clean").</p>
+
        <sect1><heading>Make sure you have sufficient space for the upgrade</heading>
 
        <p>You have to make sure before upgrading your system that you have
@@ -755,7 +783,11 @@
 <!-- JFS: Does aptitude to 'apt-get autoclean' by itself? -->
        <item>Remove packages that have been previously downloaded for
        installation (at <file>/var/cache/apt/archive</file>), cleaning up the
-       package cache by running <prgn>apt-get clean</prgn>.
+       package cache by running <prgn>apt-get autoclean</prgn> or
+       <prgn>aptitude autoclean</prgn> will remove unused package files.  If
+       that does not give you enough space, you can clean up the package cache
+       further by running <prgn>apt-get clean</prgn> or <prgn>aptitude
+       clean</prgn>. 
 
 <!-- JFS Point to http://www.enricozini.org/blog/eng/pkgsizestat.html ?
      Enrico's script shows files that occupy space in a given partition
@@ -767,12 +799,24 @@
        system that occupy the most space. You can also use <prgn/deborphan/
        or <prgn/debfoster/ to find obsolete packages (see 
        <ref id="obsolete">).
+       Alternatively you can start <prgn/aptitude/ into "visual mode" and find
+       obsolete packages under "Obsolete and Locally Created Packages".
        
        <item>Remove packages taking up too much space, which are not currently 
        needed (you can always reinstall them after the
        upgrade). You can list the packages that take up most of the disk space
        with <prgn/dpigs/ (available in the <package/debian-goodies/ package)
        or with <prgn/wajig/ (running <tt>wajig size</tt>).
+
+<!-- TODO: consider this for lenny
+You can list packages that take up most of the disk space with
+       <prgn/aptitude/ .  Start <prgn/aptitude/ into "visual mode", select
+       "Views" and "New Flat Package List" (this menu entry is available only
+       after etch version), press "l" and enter "~i", press "S" and enter
+       "~installsize", then it will give you nice list to work with.  Doing
+       this after partial upgrade described in <ref id="upgrading_aptitude">
+       should give you access to this new feature.
+-->
        
        <item>Temporarily move to another system, or permanently remove, system
        logs residing under <file>/var/log/</file>.
@@ -836,7 +880,7 @@
           or
 
           <example>
-# dpkg --get-selections &gt; ~/curr-pkgs.txt
+# dpkg --get-selections "*" &gt; ~/curr-pkgs.txt
           </example></p>
 
           <p>It is desirable to remove any holds before upgrading. If any
@@ -1086,8 +1130,9 @@
 
 	  <p>Next you should double check that the APT source entries (in
 	  <file>/etc/apt/sources.list</file>) refer either to
-	  "<tt/&releasename;/" or to "<tt>stable</tt>". Note: source
-	  lines for a CD-ROM will often refer to "<tt/unstable/";
+          "<tt/&releasename;/" or to "<tt>stable</tt>". There should not be
+          any sources entries pointing to &oldreleasename;. 
+          Note: source lines for a CD-ROM will often refer to "<tt/unstable/";
 	  although this may be confusing, you should <em/not/ change it.</p>
 
 	<sect1 id="record_session"><heading>Recording the session</heading>
@@ -1147,7 +1192,14 @@
 
         <sect1 id="minimal_upgrade"><heading>Minimal system upgrade</heading>
 
-        <p>TBD</p>
+        <p>TODO</p>
+
+        <p>Run 
+          <example>
+# aptitude upgrade
+          </example></p>
+
+        <p>Followed by:</p>
 
         <p>Server system with no X, do a minimal upgrade with:
 
@@ -1167,55 +1219,27 @@
 # aptitude install initrd-tools libfam0 xlibmesa-glu
           </example></p>
 
-        <p>Note: Once this minimal upgrade has been done might want to consider
-        upgrading the kernel before upgrading the full system.
-        (either in 2.4 or 2.6). This reduces the window of exposure of not having
-        a bootable systems. If using lilo, it could be upgraded (and run) afterwards
-        for similar reasons. However, installing coreutils + udev might force
-        the removal of large parts of the system if in a desktop.</p>
+        <p>Note: After this minimal upgrade has finished you might want to
+        consider upgrading the kernel before upgrading the full system,
+        as described in <ref id="newkernel">.
+        Doing so reduces the timeframe in which, if the system will not
+        properly boot if rebooted accidentally.
+        This is because the full upgrade will
+        install a new version of <prgn/udev/ and will remove <prgn/hotplug/.
+        If you are running a desktop environment large parts of the
+        system will be removed if you do the kernel upgrade here.</p>
 
         </sect1>
 
-<!-- FJP: This next section can probably be dropped for etch -->
-<!-- JFS: Actually, this caused issues if done, as documented in 396331, such as 
-     removing the current *running* kernel does this still apply with the
-     latest aptitude 0.4.4-1  -->
-        <sect1 id="upgrading_aptitude"><heading>Upgrading aptitude</heading>
-          
-          <p>TODO: This is no longer true and will be removed. TESTS pending.
-
-          <p>Upgrade tests have shown that &releasename;'s version of
-          <prgn/aptitude/ is better at solving the complex dependencies during
-          an upgrade than either <prgn/apt-get/ or &oldreleasename;'s
-          <prgn/aptitude/.
-
-          It should therefore be upgraded first using:
-          <example>
-# aptitude install aptitude
-          </example></p>
-
-          <p>You will be shown a list of the changes that will be
-          made and asked you to confirm them. You should take a careful look at
-          the proposed changes, especially packages that will be removed by the
-          upgrade, before you confirm.</p>
-
-          <p>In some cases if a large number of packages is listed for removal,
-          you may be able to reduce this list by "pre-upgrading" selected other
-          packages alongside <package/aptitude/. An example may clarify this.
-          During upgrade tests for systems having KDE installed, we have seen
-          that this step would cause removal of a large number of KDE packages
-          and/or perl. The solution proved to be to <tt>install aptitude perl</tt>
-          instead of <tt>install aptitude</tt>.</p>
-
-        </sect1>
+<!-- TODO: For lenny, consider restoring the section 'Upgrade aptitude' -->
 
         <sect1 id="upgrading_other"><heading>Upgrading the rest of the system</heading>
 
-<!-- FIXME: we have not tested with the with-recommends option -->
           <p>You are now ready to continue with the main part of the
           upgrade. Execute:</p>
+<!-- NOTE (jfs): we have not tested with the -f and with-recommends option -->
 	  <p><example>
-# aptitude -f --with-recommends dist-upgrade
+# aptitude dist-upgrade
 	  </example></p>
 
 	  <p>This will perform a complete upgrade of the system, i.e. install
@@ -1223,7 +1247,7 @@
 	  possible dependency changes between packages in different releases.
 	  If necessary, it will install some new packages (usually new library
 	  versions, or renamed packages), and remove any conflicting obsoleted
-	  packages (such as <package>console-tools-libs</package>).</p>
+	  packages.</p>
 
           <p>When upgrading from a set of CD-ROMs, you will be asked to
           insert specific CDs at several points during the upgrade. You
@@ -1237,11 +1261,6 @@
 	  packages for installation or by trying <tt>aptitude -f install
 	  <var>package</var></tt>.</p>
 
-          <p>The <tt/--fix-broken/ (or just <tt/-f/) option causes
-          <package/apt/ to attempt to correct a system with broken
-          dependencies in place. <package/apt/ does not allow broken package
-          dependencies to exist on a system.</p>
-
         </sect1>
 
         <sect1 id="trouble"><heading>Possible issues during upgrade</heading>
@@ -1359,22 +1378,89 @@
           in <ref id="upgrade-to-2.6">.</p>
 ]]>
 
-        <sect1><heading>Upgrading from a 2.6 kernel</heading>
+        <sect1><heading>Installing the kernel metapackage</heading>
+          <p>When you dist-upgrade from &oldreleasename; to &releasename;,
+          it is strongly recommended that you install a new
+          linux-image-2.6-* metapackage.
+          This package may be installed automatically by the dist-upgrade
+          process. You can verify this by running:
+<!-- NOTE (jfs): Users using apt/aptitude might not have their available file
+     updated so '^ii' is really unnecesary, maybe dpkg -l 'linux-image*' would be
+     better here? -->
+          <example>
+# dpkg -l | grep '^ii  linux-image'
+          </example></p>
+
+          <p>If you do not see any output, then you will need to install a
+          new linux-image package by hand. To see a list of available
+          linux-image-2.6 metapackages, run:
+          <example>
+# apt-cache search linux-image-2.6- | grep -v transition
+          </example></p>
+
+          <p>If you are unsure about which package to select, run
+          <tt>uname -r</tt> and look for a package with a similar name.
+          For example, if you see '2.4.27-3-686', it is recommended that you
+          install <package/linux-image-2.6-686/.
+          You may also use <prgn>apt-cache</prgn> to see a long description of each
+          package in order to help choose the best one available.
+          For example:
+          <example>
+# apt-cache show linux-image-2.6-686
+          </example></p>
+
+         <p>You should then use <tt/aptitude install/ to install it. Once
+         this new kernel is installed you should reboot at the next available
+         opportunity to get the benefits provided by the new kernel version.</p>
+
+         <p>For the more adventurous there is an easy way to compile your
+         own custom kernel on &debian;. Install the
+         <package>kernel-package</package> tool and read the documentation
+         in <file>/usr/share/doc/kernel-package</file>.</p>
+
+        </sect1>
+
+        <sect1 id="upgrade-from-2.6"><heading>Upgrading from a 2.6 kernel</heading>
 
 <!-- JFS: Bug #413458, undeclared linux depency on coreutils' readlink's -m option -->
-         <p>If you are currently running a 2.6 series kernel from &oldreleasename;
-         you will have to upgrade to the latest version of <package/coreutils/ before
-         you upgrade to the 2.6 series kernel available in &releasename;.
+        <p>If you are currently running a 2.6 series kernel from
+        &oldreleasename; this upgrade will take place after do a full upgrade
+        of the system packages (as described in <ref id="upgradingpackages">).
+        </p>
+
+        <p>Take in account that the <prgn/udev/ version in &releasename; does
+        not support kernel earlier than 2.6.15 (which includes
+        &oldreleasename; 2.6.8 kernels), conversely the <prgn/udev/ version in
+        &oldreleasename; will not work properly with the latest kernels.
+        As a consequence, the previous kernel package will probably not boot
+        properly after this upgrade. Similarly, there is a time window through
+        the upgrade in which <prgn/udev/ has been upgraded but not the
+        latest kernel. If the system were to be rebooted at this point,
+        in the middle of the upgrade, it might not be bootable.</p>
+
 <!-- JFS: Bug #325568 -->
-         In order to do this you first have to do a minimal upgrade of the
-         system, a full upgrade of the system packages (as described in <ref
-         id="upgradingpackages">) is not an option since the <prgn/udev/
-         version in &releasename; does not support 2.6.8 kernels, conversely
-         the <prgn/udev/ version in &oldreleasename; will not work properly with the
-         latest kernels.</p>
+        <p>Consequently, you might want to upgrade to the latest kernel
+        before doing the full upgrade. Before you can upgrade to the 2.6
+        series kernel available in &releasename; you will have to
+        upgrade to the latest version of <package/coreutils/ and
+        <package/initrd-tools/. To upgrade the kernel before the upgrade, take 
+        all the steps up to and including the steps related to the a minimal
+        upgrade of the system, as described in <ref id="minimal_upgrade">,
+        and then do the following:
+        <example>
+# aptitude install initrd-tools coreutils linux-image-2.6-686
+        </example>
+        </p>
 
-         <p><em>TODO</em>: Describe the steps for this minimal upgrade, should take care
-         of glibc, initrd-tools and udev + linux-image 2.6.</p>
+        <p>This step will also update libc6, install <prgn/udev/ and
+        remove <package/base-config/ and <package/hotplug/.</p>
+
+        <p>You can also take this step if you are using your own custom
+        kernel and want to use the kernel available in &releasename;.
+        If your kernel version is not supported by <prgn/udev/ then
+        it is recommended you upgrade after the minimal upgrade.
+        If your version is supported by <prgn/udev/ you can safely wait
+        until after the full system upgrade.</p>
 
 <!--
          <p><em>TRY</em>: In aptitude, upgrade only 'required' 'important'
@@ -1385,6 +1471,11 @@
 -->
         </sect1>
 
+        <sect1 id="upgrade-from-2.4"><heading>Upgrading from a 2.4 kernel</heading>
+        <p>TODO</p>
+
+        </sect1>
+
         <sect1><heading>initrd-tools deprecated</heading>
           <p><package/initrd-tools/ is no longer supported and has been
           superseded by <package/initramfs-tools/ and <package/yaird/.
@@ -1542,47 +1633,6 @@
         </sect1>
 ]]>
 
-        <sect1><heading>Upgrading the kernel</heading>
-          <p>When you dist-upgrade from &oldreleasename; to &releasename;,
-          it is strongly recommended that you install a new
-          linux-image-2.6-* metapackage.
-          This package may be installed automatically by the dist-upgrade
-          process. You can verify this by running:
-<!-- NOTE (jfs): Users using apt/aptitude might not have their available file
-     updated so '^ii' is really unnecesary, maybe dpkg -l 'linux-image*' would be
-     better here? -->
-          <example>
-# dpkg -l | grep '^ii  linux-image'
-          </example></p>
-
-          <p>If you do not see any output, then you will need to install a
-          new linux-image package by hand. To see a list of available
-          linux-image-2.6 metapackages, run:
-          <example>
-# apt-cache search linux-image-2.6- | grep -v transition
-          </example></p>
-
-          <p>If you are unsure about which package to select, run
-          <tt>uname -r</tt> and look for a package with a similar name.
-          For example, if you see '2.4.27-3-686', it is recommended that you
-          install <package/linux-image-2.6-686/.
-          You may also use <prgn>apt-cache</prgn> to see a long description of each
-          package in order to help choose the best one available.
-          For example:
-          <example>
-# apt-cache show linux-image-2.6-686
-          </example></p>
-
-         <p>You should then use <tt/aptitude install/ to install it. Once
-         this new kernel is installed you should reboot at the next available
-         opportunity to get the benefits provided by the new kernel version.</p>
-
-         <p>For the more adventurous there is an easy way to compile your
-         own custom kernel on &debian;. Install the
-         <package>kernel-package</package> tool and read the documentation
-         in <file>/usr/share/doc/kernel-package</file>.</p>
-
-        </sect1>
         </sect>
 
         <sect id="nownownow"><heading>Things to do before rebooting</heading>




More information about the l10n-russian-cvs-commits mailing list