[76ccbb3] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
[b06ca36] | 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
---|
[76ccbb3] | 4 | <!ENTITY % general-entities SYSTEM "../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
| 7 |
|
---|
| 8 | <sect1 id="ch-system-pkgmgt">
|
---|
| 9 | <?dbhtml filename="pkgmgt.html"?>
|
---|
| 10 |
|
---|
[3f3931b0] | 11 | <title>Package Management</title>
|
---|
| 12 |
|
---|
[76ccbb3] | 13 | <para>Package Management is an often requested addition to the LFS Book. A
|
---|
[4349661] | 14 | Package Manager tracks the installation of files, making it easier to
|
---|
[f8b1860] | 15 | remove and upgrade packages. A good package manager will also handle the
|
---|
| 16 | configuration files specially to keep the user configuration when the
|
---|
| 17 | package is reinstalled or upgraded. Before
|
---|
[d327d74] | 18 | you begin to wonder, NO—this section will not talk about nor recommend
|
---|
[091d624d] | 19 | any particular package manager. What it does provide is a roundup of the more
|
---|
[d327d74] | 20 | popular techniques and how they work. The perfect package manager for you may
|
---|
[4349661] | 21 | be among these techniques, or it may be a combination of two or more of these
|
---|
[d327d74] | 22 | techniques. This section briefly mentions issues that may arise when upgrading
|
---|
| 23 | packages.</para>
|
---|
[76ccbb3] | 24 |
|
---|
[3f3931b0] | 25 | <para>Some reasons why no package manager is mentioned in LFS or BLFS
|
---|
| 26 | include:</para>
|
---|
[76ccbb3] | 27 |
|
---|
| 28 | <itemizedlist>
|
---|
| 29 | <listitem>
|
---|
| 30 | <para>Dealing with package management takes the focus away from the goals
|
---|
| 31 | of these books—teaching how a Linux system is built.</para>
|
---|
| 32 | </listitem>
|
---|
| 33 |
|
---|
| 34 | <listitem>
|
---|
| 35 | <para>There are multiple solutions for package management, each having
|
---|
[4349661] | 36 | its strengths and drawbacks. Finding one solution that satisfies all audiences
|
---|
[76ccbb3] | 37 | is difficult.</para>
|
---|
| 38 | </listitem>
|
---|
| 39 | </itemizedlist>
|
---|
| 40 |
|
---|
| 41 | <para>There are some hints written on the topic of package management. Visit
|
---|
[ba82c18] | 42 | the <ulink url="&hints-root;">Hints Project</ulink> and see if one of them
|
---|
[4349661] | 43 | fits your needs.</para>
|
---|
[76ccbb3] | 44 |
|
---|
[59fef4c] | 45 | <sect2 id='pkgmgmt-upgrade-issues'>
|
---|
[76ccbb3] | 46 | <title>Upgrade Issues</title>
|
---|
| 47 |
|
---|
| 48 | <para>A Package Manager makes it easy to upgrade to newer versions when they
|
---|
[6a156bab] | 49 | are released. Generally the instructions in the LFS and BLFS books can be
|
---|
[76ccbb3] | 50 | used to upgrade to the newer versions. Here are some points that you should
|
---|
| 51 | be aware of when upgrading packages, especially on a running system.</para>
|
---|
| 52 |
|
---|
| 53 | <itemizedlist>
|
---|
| 54 | <listitem>
|
---|
[4349661] | 55 | <para>If the Linux kernel needs to be upgraded (for example, from
|
---|
| 56 | 5.10.17 to 5.10.18 or 5.11.1), nothing else needs to be rebuilt.
|
---|
| 57 | The system will keep working fine thanks to the well-defined interface
|
---|
[7ae2811] | 58 | between the kernel and userspace. Specifically, Linux API headers
|
---|
[4349661] | 59 | need not be (and should not be, see the next item) upgraded
|
---|
| 60 | along with the kernel. You will merely need to reboot your system to use the
|
---|
[7aee318] | 61 | upgraded kernel.</para>
|
---|
| 62 | </listitem>
|
---|
| 63 |
|
---|
| 64 | <listitem>
|
---|
[091d624d] | 65 | <para>If the Linux API headers or Glibc need to be upgraded to a newer
|
---|
| 66 | version, (e.g., from Glibc-2.31 to Glibc-2.32), it is safer to
|
---|
[7aee318] | 67 | rebuild LFS. Though you <emphasis>may</emphasis> be able to rebuild
|
---|
| 68 | all the packages in their dependency order, we do not recommend
|
---|
| 69 | it. </para>
|
---|
[76ccbb3] | 70 | </listitem>
|
---|
| 71 |
|
---|
[6a156bab] | 72 | <listitem> <para>If a package containing a shared library is updated, and
|
---|
[11d5dee] | 73 | if the name of the library changes, then any packages dynamically
|
---|
[4349661] | 74 | linked to the library must be recompiled, to link against the
|
---|
[6a156bab] | 75 | newer library. (Note that there is no correlation between the package
|
---|
| 76 | version and the name of the library.) For example, consider a package
|
---|
[4349661] | 77 | foo-1.2.3 that installs a shared library with the name <filename
|
---|
| 78 | class='libraryfile'>libfoo.so.1</filename>. Suppose you upgrade the package to
|
---|
| 79 | a newer version foo-1.2.4 that installs a shared library with the name
|
---|
[6a156bab] | 80 | <filename class='libraryfile'>libfoo.so.2</filename>. In this case, any
|
---|
| 81 | packages that are dynamically linked to <filename
|
---|
| 82 | class='libraryfile'>libfoo.so.1</filename> need to be recompiled to link
|
---|
| 83 | against <filename class='libraryfile'>libfoo.so.2</filename> in order to
|
---|
[4349661] | 84 | use the new library version. You should not remove the old
|
---|
| 85 | libraries until all the dependent packages have been recompiled.</para>
|
---|
[9a17861] | 86 | </listitem>
|
---|
| 87 |
|
---|
| 88 | <listitem> <para>If a package containing a shared library is updated,
|
---|
[4349661] | 89 | and the name of the library doesn't change, but the version number of the
|
---|
[9a17861] | 90 | library <emphasis role="bold">file</emphasis> decreases (for example,
|
---|
[4349661] | 91 | the library is still named
|
---|
[9a17861] | 92 | <filename class='libraryfile'>libfoo.so.1</filename>,
|
---|
[4349661] | 93 | but the name of the library file is changed from
|
---|
[9a17861] | 94 | <filename class='libraryfile'>libfoo.so.1.25</filename> to
|
---|
| 95 | <filename class='libraryfile'>libfoo.so.1.24</filename>),
|
---|
| 96 | you should remove the library file from the previously installed version
|
---|
[4349661] | 97 | (<filename class='libraryfile'>libfoo.so.1.25</filename> in this case).
|
---|
[6582ddc5] | 98 | Otherwise, a <command>ldconfig</command> command (invoked by yourself from the command
|
---|
[9a17861] | 99 | line, or by the installation of some package) will reset the symlink
|
---|
| 100 | <filename class='libraryfile'>libfoo.so.1</filename> to point to
|
---|
[4349661] | 101 | the old library file because it seems to be a <quote>newer</quote>
|
---|
| 102 | version; its version number is larger. This situation may arise if
|
---|
| 103 | you have to downgrade a package, or if the authors change the versioning
|
---|
| 104 | scheme for library files.</para> </listitem>
|
---|
[9a17861] | 105 |
|
---|
[ccb08fa] | 106 | <listitem><para>If a package containing a shared library is updated,
|
---|
[4349661] | 107 | and the name of the library doesn't change, but a severe issue
|
---|
[59fef4c] | 108 | (especially, a security vulnerability) is fixed, all running programs
|
---|
| 109 | linked to the shared library should be restarted. The following
|
---|
| 110 | command, run as <systemitem class="username">root</systemitem> after
|
---|
[6582ddc5] | 111 | the update is complete, will list which processes are using the old versions of those libraries
|
---|
[59fef4c] | 112 | (replace <replaceable>libfoo</replaceable> with the name of the
|
---|
| 113 | library):</para>
|
---|
| 114 |
|
---|
[365b8c7] | 115 | <screen role="nodump"><userinput>grep -l -e '<replaceable>libfoo</replaceable>.*deleted' /proc/*/maps |
|
---|
[59fef4c] | 116 | tr -cd 0-9\\n | xargs -r ps u</userinput></screen>
|
---|
| 117 |
|
---|
| 118 | <para>
|
---|
[4349661] | 119 | If <application>OpenSSH</application> is being used to access
|
---|
| 120 | the system and it is linked to the updated library, you must
|
---|
| 121 | restart the <command>sshd</command> service, then logout, login again,
|
---|
| 122 | and rerun the preceding ps command to confirm that nothing is still using the
|
---|
[59fef4c] | 123 | deleted libraries.
|
---|
[ccb08fa] | 124 | </para>
|
---|
| 125 |
|
---|
| 126 | <para revision='systemd'>
|
---|
| 127 | If the <command>systemd</command> daemon (running as PID 1) is
|
---|
[4349661] | 128 | linked to the updated library, you can restart it without rebooting
|
---|
[ccb08fa] | 129 | by running <command>systemctl daemon-reexec</command> as the
|
---|
| 130 | <systemitem class='username'>root</systemitem> user.
|
---|
[59fef4c] | 131 | </para></listitem>
|
---|
[de28837] | 132 |
|
---|
| 133 | <listitem>
|
---|
[4349661] | 134 | <para>If an executable program or a shared library is overwritten, the processes
|
---|
| 135 | using the code or data in that program or library may crash. The
|
---|
| 136 | correct way to update a program or a shared library without causing
|
---|
[11d5dee] | 137 | the process to crash is to remove it first, then install the new
|
---|
[4349661] | 138 | version. The <command>install</command> command
|
---|
| 139 | provided by <application>coreutils</application> has already
|
---|
| 140 | implemented this, and most packages use that command to install binary files and
|
---|
[11d5dee] | 141 | libraries. This means that you won't be troubled by this issue most of the time.
|
---|
[de28837] | 142 | However, the install process of some packages (notably Mozilla JS
|
---|
[4349661] | 143 | in BLFS) just overwrites the file if it exists; this causes a crash. So
|
---|
[de28837] | 144 | it's safer to save your work and close unneeded running processes
|
---|
[4349661] | 145 | before updating a package.</para> <!-- binary is an adjective, not a noun. -->
|
---|
[de28837] | 146 | </listitem>
|
---|
[9a17861] | 147 | </itemizedlist>
|
---|
[76ccbb3] | 148 |
|
---|
| 149 | </sect2>
|
---|
| 150 |
|
---|
| 151 | <sect2>
|
---|
| 152 | <title>Package Management Techniques</title>
|
---|
| 153 |
|
---|
| 154 | <para>The following are some common package management techniques. Before
|
---|
| 155 | making a decision on a package manager, do some research on the various
|
---|
[4349661] | 156 | techniques, particularly the drawbacks of each particular scheme.</para>
|
---|
[76ccbb3] | 157 |
|
---|
| 158 | <sect3>
|
---|
| 159 | <title>It is All in My Head!</title>
|
---|
| 160 |
|
---|
[4349661] | 161 | <para>Yes, this is a package management technique. Some folks do not
|
---|
| 162 | need a package manager because they know the packages intimately
|
---|
| 163 | and know which files are installed by each package. Some users also do not
|
---|
[76ccbb3] | 164 | need any package management because they plan on rebuilding the entire
|
---|
[4349661] | 165 | system whenever a package is changed.</para>
|
---|
[3f3931b0] | 166 |
|
---|
[76ccbb3] | 167 | </sect3>
|
---|
| 168 |
|
---|
| 169 | <sect3>
|
---|
| 170 | <title>Install in Separate Directories</title>
|
---|
| 171 |
|
---|
[4349661] | 172 | <para>This is a simplistic package management technique that does not need a
|
---|
| 173 | special program to manage the packages. Each package is installed in a
|
---|
[76ccbb3] | 174 | separate directory. For example, package foo-1.1 is installed in
|
---|
| 175 | <filename class='directory'>/usr/pkg/foo-1.1</filename>
|
---|
| 176 | and a symlink is made from <filename>/usr/pkg/foo</filename> to
|
---|
[4349661] | 177 | <filename class='directory'>/usr/pkg/foo-1.1</filename>. When
|
---|
| 178 | a new version foo-1.2 comes along, it is installed in
|
---|
[76ccbb3] | 179 | <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
|
---|
| 180 | symlink is replaced by a symlink to the new version.</para>
|
---|
| 181 |
|
---|
| 182 | <para>Environment variables such as <envar>PATH</envar>,
|
---|
| 183 | <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
|
---|
| 184 | <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
|
---|
[4349661] | 185 | include <filename>/usr/pkg/foo</filename>. If you install more than a few packages,
|
---|
[76ccbb3] | 186 | this scheme becomes unmanageable.</para>
|
---|
[3f3931b0] | 187 |
|
---|
[76ccbb3] | 188 | </sect3>
|
---|
| 189 |
|
---|
| 190 | <sect3>
|
---|
| 191 | <title>Symlink Style Package Management</title>
|
---|
| 192 |
|
---|
| 193 | <para>This is a variation of the previous package management technique.
|
---|
[4349661] | 194 | Each package is installed as in the previous scheme. But instead of
|
---|
| 195 | making the symlink via a generic package name, each file is symlinked into the
|
---|
[76ccbb3] | 196 | <filename class='directory'>/usr</filename> hierarchy. This removes the
|
---|
| 197 | need to expand the environment variables. Though the symlinks can be
|
---|
[4349661] | 198 | created by the user, many package managers use this approach, and
|
---|
| 199 | automate the creation of the symlinks. A few of the popular ones include Stow,
|
---|
[76ccbb3] | 200 | Epkg, Graft, and Depot.</para>
|
---|
| 201 |
|
---|
[4349661] | 202 | <para>The installation script needs to be fooled, so the package thinks
|
---|
[76ccbb3] | 203 | it is installed in <filename class="directory">/usr</filename> though in
|
---|
| 204 | reality it is installed in the
|
---|
| 205 | <filename class="directory">/usr/pkg</filename> hierarchy. Installing in
|
---|
[091d624d] | 206 | this manner is not usually a trivial task. For example, suppose you
|
---|
[76ccbb3] | 207 | are installing a package libfoo-1.1. The following instructions may
|
---|
| 208 | not install the package properly:</para>
|
---|
| 209 |
|
---|
[942465e] | 210 | <screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
|
---|
[76ccbb3] | 211 | make
|
---|
| 212 | make install</userinput></screen>
|
---|
| 213 |
|
---|
| 214 | <para>The installation will work, but the dependent packages may not link
|
---|
| 215 | to libfoo as you would expect. If you compile a package that links against
|
---|
| 216 | libfoo, you may notice that it is linked to
|
---|
| 217 | <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
|
---|
| 218 | instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
|
---|
| 219 | as you would expect. The correct approach is to use the
|
---|
[4349661] | 220 | <envar>DESTDIR</envar> variable to direct the installation. This
|
---|
[76ccbb3] | 221 | approach works as follows:</para>
|
---|
| 222 |
|
---|
[942465e] | 223 | <screen role="nodump"><userinput>./configure --prefix=/usr
|
---|
[76ccbb3] | 224 | make
|
---|
| 225 | make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
|
---|
| 226 |
|
---|
[3f3931b0] | 227 | <para>Most packages support this approach, but there are some which do not.
|
---|
[4349661] | 228 | For the non-compliant packages, you may either need to install the
|
---|
| 229 | package manually, or you may find that it is easier to install some problematic
|
---|
[3f3931b0] | 230 | packages into <filename class='directory'>/opt</filename>.</para>
|
---|
| 231 |
|
---|
[76ccbb3] | 232 | </sect3>
|
---|
| 233 |
|
---|
| 234 | <sect3>
|
---|
| 235 | <title>Timestamp Based</title>
|
---|
| 236 |
|
---|
| 237 | <para>In this technique, a file is timestamped before the installation of
|
---|
| 238 | the package. After the installation, a simple use of the
|
---|
| 239 | <command>find</command> command with the appropriate options can generate
|
---|
| 240 | a log of all the files installed after the timestamp file was created. A
|
---|
[4349661] | 241 | package manager that uses this approach is install-log.</para>
|
---|
[76ccbb3] | 242 |
|
---|
| 243 | <para>Though this scheme has the advantage of being simple, it has two
|
---|
| 244 | drawbacks. If, during installation, the files are installed with any
|
---|
| 245 | timestamp other than the current time, those files will not be tracked by
|
---|
[4349661] | 246 | the package manager. Also, this scheme can only be used when packages
|
---|
| 247 | are installed one at a time. The logs are not reliable if two packages are
|
---|
| 248 | installed simultaneously from two different consoles.</para>
|
---|
[3f3931b0] | 249 |
|
---|
[76ccbb3] | 250 | </sect3>
|
---|
| 251 |
|
---|
| 252 | <sect3>
|
---|
[d327d74] | 253 | <title>Tracing Installation Scripts</title>
|
---|
[76ccbb3] | 254 |
|
---|
[d327d74] | 255 | <para>In this approach, the commands that the installation scripts perform
|
---|
| 256 | are recorded. There are two techniques that one can use:</para>
|
---|
| 257 |
|
---|
| 258 | <para>The <envar>LD_PRELOAD</envar> environment variable can be set to
|
---|
| 259 | point to a library to be preloaded before installation. During
|
---|
[76ccbb3] | 260 | installation, this library tracks the packages that are being installed by
|
---|
| 261 | attaching itself to various executables such as <command>cp</command>,
|
---|
| 262 | <command>install</command>, <command>mv</command> and tracking the system
|
---|
| 263 | calls that modify the filesystem. For this approach to work, all the
|
---|
| 264 | executables need to be dynamically linked without the suid or sgid bit.
|
---|
| 265 | Preloading the library may cause some unwanted side-effects during
|
---|
[4349661] | 266 | installation. Therefore, it's a good idea to perform some tests to
|
---|
| 267 | ensure that the package manager does not break anything, and that it logs all the
|
---|
[76ccbb3] | 268 | appropriate files.</para>
|
---|
[3f3931b0] | 269 |
|
---|
[4349661] | 270 | <para>Another technique is to use <command>strace</command>, which
|
---|
| 271 | logs all the system calls made during the execution of the installation
|
---|
[d327d74] | 272 | scripts.</para>
|
---|
[76ccbb3] | 273 | </sect3>
|
---|
| 274 |
|
---|
| 275 | <sect3>
|
---|
| 276 | <title>Creating Package Archives</title>
|
---|
| 277 |
|
---|
| 278 | <para>In this scheme, the package installation is faked into a separate
|
---|
[4349661] | 279 | tree as previously described in the symlink style package management section. After the
|
---|
[76ccbb3] | 280 | installation, a package archive is created using the installed files.
|
---|
[4349661] | 281 | This archive is then used to install the package on the local
|
---|
| 282 | machine or even on other machines.</para>
|
---|
[76ccbb3] | 283 |
|
---|
| 284 | <para>This approach is used by most of the package managers found in the
|
---|
| 285 | commercial distributions. Examples of package managers that follow this
|
---|
| 286 | approach are RPM (which, incidentally, is required by the <ulink
|
---|
[fb66c4c] | 287 | url="https://refspecs.linuxfoundation.org/lsb.shtml">Linux
|
---|
[76ccbb3] | 288 | Standard Base Specification</ulink>), pkg-utils, Debian's apt, and
|
---|
| 289 | Gentoo's Portage system. A hint describing how to adopt this style of
|
---|
| 290 | package management for LFS systems is located at <ulink
|
---|
[6b8936f] | 291 | url="&hints-root;fakeroot.txt"/>.</para>
|
---|
[3f3931b0] | 292 |
|
---|
[4349661] | 293 | <para>The creation of package files that include dependency information is
|
---|
| 294 | complex, and beyond the scope of LFS.</para>
|
---|
[33f0959] | 295 |
|
---|
[4349661] | 296 | <para>Slackware uses a <command>tar</command>-based system for package
|
---|
[33f0959] | 297 | archives. This system purposely does not handle package dependencies
|
---|
| 298 | as more complex package managers do. For details of Slackware package
|
---|
| 299 | management, see <ulink
|
---|
[fb66c4c] | 300 | url="https://www.slackbook.org/html/package-management.html"/>.</para>
|
---|
[76ccbb3] | 301 | </sect3>
|
---|
| 302 |
|
---|
| 303 | <sect3>
|
---|
| 304 | <title>User Based Management</title>
|
---|
| 305 |
|
---|
| 306 | <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is
|
---|
[ba82c18] | 307 | available from the <ulink url="&hints-root;">Hints Project</ulink>. In
|
---|
[76ccbb3] | 308 | this scheme, each package is installed as a separate user into the
|
---|
| 309 | standard locations. Files belonging to a package are easily identified by
|
---|
| 310 | checking the user ID. The features and shortcomings of this approach are
|
---|
| 311 | too complex to describe in this section. For the details please see the
|
---|
[6b8936f] | 312 | hint at <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
|
---|
[3f3931b0] | 313 |
|
---|
[76ccbb3] | 314 | </sect3>
|
---|
| 315 |
|
---|
| 316 | </sect2>
|
---|
| 317 |
|
---|
[33f0959] | 318 | <sect2>
|
---|
| 319 | <title>Deploying LFS on Multiple Systems</title>
|
---|
| 320 |
|
---|
[cf7ba91] | 321 | <para>One of the advantages of an LFS system is that there are no files that
|
---|
[33f0959] | 322 | depend on the position of files on a disk system. Cloning an LFS build to
|
---|
[ea23e54] | 323 | another computer with the same architecture as the base system is as
|
---|
[33f0959] | 324 | simple as using <command>tar</command> on the LFS partition that contains
|
---|
[091d624d] | 325 | the root directory (about 900MB uncompressed for a basic LFS build), copying
|
---|
| 326 | <!-- D. Bryant created LFS 11.2 in October 2022; 900MB is (roughly) the size of his rsync archive. -->
|
---|
[4349661] | 327 | that file via network transfer or CD-ROM / USB stick to the new system, and expanding
|
---|
| 328 | it. After that, a few configuration files will have to be changed.
|
---|
[2ca8941] | 329 | Configuration files that may need to be updated include:
|
---|
[33f0959] | 330 | <filename>/etc/hosts</filename>,
|
---|
| 331 | <filename>/etc/fstab</filename>,
|
---|
| 332 | <filename>/etc/passwd</filename>,
|
---|
| 333 | <filename>/etc/group</filename>,
|
---|
[1118b17] | 334 | <phrase revision="systemd">
|
---|
| 335 | <filename>/etc/shadow</filename>, and
|
---|
| 336 | <filename>/etc/ld.so.conf</filename>.
|
---|
| 337 | </phrase>
|
---|
| 338 | <phrase revision="sysv">
|
---|
| 339 | <filename>/etc/shadow</filename>,
|
---|
| 340 | <filename>/etc/ld.so.conf</filename>,
|
---|
| 341 | <filename>/etc/sysconfig/rc.site</filename>,
|
---|
| 342 | <filename>/etc/sysconfig/network</filename>, and
|
---|
| 343 | <filename>/etc/sysconfig/ifconfig.eth0</filename>.
|
---|
| 344 | </phrase>
|
---|
[33f0959] | 345 | </para>
|
---|
| 346 |
|
---|
[4349661] | 347 | <para>A custom kernel may be needed for the new system, depending on
|
---|
[33f0959] | 348 | differences in system hardware and the original kernel
|
---|
| 349 | configuration.</para>
|
---|
| 350 |
|
---|
[1118b17] | 351 | <note><para>There have been some reports of issues when copying between
|
---|
| 352 | similar but not identical architectures. For instance, the instruction set
|
---|
[4349661] | 353 | for an Intel system is not identical with the AMD processor's instructions, and later
|
---|
| 354 | versions of some processors may provide instructions that are unavailable with
|
---|
[ea23e54] | 355 | earlier versions.</para></note>
|
---|
| 356 |
|
---|
[4349661] | 357 | <para>Finally, the new system has to be made bootable via <xref
|
---|
[33f0959] | 358 | linkend="ch-bootable-grub"/>.</para>
|
---|
| 359 |
|
---|
| 360 | </sect2>
|
---|
| 361 |
|
---|
[76ccbb3] | 362 | </sect1>
|
---|