[Clfs-commits] commit: r4966 - in /trunk/BOOK/bootable: alpha/aboot.xml alpha/kernel.xml mips/arcload.xml mips64/arcload.xml ppc/yaboot.xml x86_64-64/lilo.xml
svn at cross-lfs.org
svn at cross-lfs.org
Wed Jun 3 00:23:24 PDT 2009
Author: chris at beaker67.com
Date: Wed Jun 3 07:23:23 2009
New Revision: 4966
Log:
Text updates
Modified:
trunk/BOOK/bootable/alpha/aboot.xml
trunk/BOOK/bootable/alpha/kernel.xml
trunk/BOOK/bootable/mips/arcload.xml
trunk/BOOK/bootable/mips64/arcload.xml
trunk/BOOK/bootable/ppc/yaboot.xml
trunk/BOOK/bootable/x86_64-64/lilo.xml
Modified: trunk/BOOK/bootable/alpha/aboot.xml
==============================================================================
--- trunk/BOOK/bootable/alpha/aboot.xml (original)
+++ trunk/BOOK/bootable/alpha/aboot.xml Wed Jun 3 07:23:23 2009
@@ -15,7 +15,7 @@
<secondary>configuring</secondary>
</indexterm>
- <para os="a">Create a <filename>aboot.conf</filename> file defining aboot's boot
+ <para os="a">Create an <filename>aboot.conf</filename> file defining aboot's boot
menu:</para>
<screen><userinput>cat > /etc/aboot.conf << "EOF"
Modified: trunk/BOOK/bootable/alpha/kernel.xml
==============================================================================
--- trunk/BOOK/bootable/alpha/kernel.xml (original)
+++ trunk/BOOK/bootable/alpha/kernel.xml Wed Jun 3 07:23:23 2009
@@ -26,7 +26,7 @@
xpointer="xpointer(//*[@os='a'])"/>
<para os="a3">The following sed prevents GCC from treating warnings as
- errors when the kernel is compiled.</para>
+ errors when the kernel is compiled:</para>
<screen os="a4"><userinput>sed -i "s/-Werror//" arch/alpha/kernel/Makefile</userinput></screen>
Modified: trunk/BOOK/bootable/mips/arcload.xml
==============================================================================
--- trunk/BOOK/bootable/mips/arcload.xml (original)
+++ trunk/BOOK/bootable/mips/arcload.xml Wed Jun 3 07:23:23 2009
@@ -42,7 +42,8 @@
}</literal>
EOF</userinput></screen>
- <para os="c">Now we use dvhtool to make the system bootable:</para>
+ <para os="c">Now we use <command>dvhtool</command> to make the system
+ bootable:</para>
<screen os="d"><userinput>dvhtool --unix-to-vh /usr/lib/arcload/sash sash
dvhtool --unix-to-vh /boot/arc.cf arc.cf
Modified: trunk/BOOK/bootable/mips64/arcload.xml
==============================================================================
--- trunk/BOOK/bootable/mips64/arcload.xml (original)
+++ trunk/BOOK/bootable/mips64/arcload.xml Wed Jun 3 07:23:23 2009
@@ -42,7 +42,8 @@
}</literal>
EOF</userinput></screen>
- <para os="c">Now we use dvhtool to make the system bootable:</para>
+ <para os="c">Now we use <command>dvhtool</command> to make the system
+ bootable:</para>
<screen os="d"><userinput>dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64
dvhtool --unix-to-vh /boot/arc.cf arc.cf
Modified: trunk/BOOK/bootable/ppc/yaboot.xml
==============================================================================
--- trunk/BOOK/bootable/ppc/yaboot.xml (original)
+++ trunk/BOOK/bootable/ppc/yaboot.xml Wed Jun 3 07:23:23 2009
@@ -28,35 +28,37 @@
<para os="c">Earlier, we compiled and installed the yaboot boot loader software
in preparation for this step. The procedure involves writing the bootloader
to a bootstrap partition and blessing it so that Open Firmware will boot from
- it. This is all handled by <command>ybin</command> the yaboot installer.</para>
+ it. This is all handled by <command>ybin</command>, the yaboot installer.</para>
<para os="d">Ybin writes an optional 'OS selector' menu into Open Firmware,
- then writes yaboot and yaboot.conf to the bootstrap partition, blesses this,
- and updates the boot device recorded in nvram. When booted, the OF provides
- the initial menu to choose between linux, boot from CD, and e.g. OSX
- (depending on what was in yaboot.conf). If you boot to 'linux', yaboot is
- executed and lets you select which kernel to use.</para>
+ then writes yaboot and <filename>yaboot.conf</filename> to the bootstrap
+ partition, blesses this, and updates the boot device recorded in nvram. When
+ booted, the OF provides the initial menu to choose between linux, boot from
+ CD, and e.g. OSX (depending on what was in <filename>yaboot.conf</filename>).
+ If you boot to 'linux', yaboot is executed and lets you select which kernel
+ to use.</para>
<para os="e">Images (kernels) are specified, together with any necessary path,
- in yaboot.conf - the details are incorporated into the bootloader, but no attempt
- is made to access or validate the paths until they are selected. There are many
- possible options that can be specified in yaboot.conf, see the man page for the
- details. Most people will be able to specify device=hd: (for a single hard disk),
- but if you have multiple disks, or if you wish to be pedantic, you can specify the
+ in <filename>yaboot.conf</filename> - the details are incorporated into the
+ bootloader, but no attempt is made to access or validate the paths until
+ they are selected. There are many possible options that can be specified in
+ <filename>yaboot.conf</filename>, see the man page for the details. Most
+ people will be able to specify device=hd: (for a single hard disk), but if
+ you have multiple disks, or if you wish to be pedantic, you can specify the
full OF path to the device, obtained by running <command>ofpath /dev/hdX</command>
.</para>
<para os="h">Using the above information, determine the appropriate designators
- for the bootstrap partition and the root partition. For the following example,
+ for the bootstrap partition and the root partition. For the following example,
it is assumed that the bootstrap partition is <filename class="partition">hda2
- </filename> and the root partition is <filename class="partition">hda7</filename>
- . We will also assume that you wish to be able to boot an OSX installation on
- <filename class="partition">hda4</filename>. Change these items as necessary
+ </filename> and the root partition is <filename class="partition">hda7</filename>.
+ We will also assume that you wish to be able to boot an OSX installation on
+ <filename class="partition">hda4</filename>. Change these items as necessary
for your machine.</para>
<para os="i">If your machine has a SATA disk, specify the partitions using
<filename class="devicefile">/dev/sda7</filename> and so forth in the usual
- way. At least some of the distros specify a full OF path to the 'device' and
+ way. At least some of the distros specify a full OF path to the 'device' and
to the image(s), such as
<parameter>device=/ht at 0,f2000000/pci at 3/k2-sata-root at c/k2-sata at 0/disk at 0:</parameter>
for the disk, and
Modified: trunk/BOOK/bootable/x86_64-64/lilo.xml
==============================================================================
--- trunk/BOOK/bootable/x86_64-64/lilo.xml (original)
+++ trunk/BOOK/bootable/x86_64-64/lilo.xml Wed Jun 3 07:23:23 2009
@@ -16,58 +16,57 @@
</indexterm>
<para os="a">Your shiny new CLFS system is almost complete. One of the
- last things to do is to ensure that the system can be properly
- booted. The instructions below apply only to computers using Lilo,
- which in the context of this book means x86_64 Pure64 systems.
- Information on <quote>boot loading</quote> for other architectures
- should be available in the usual resource-specific locations for
- those architectures.</para>
+ last things to do is to ensure that the system can be properly booted. The
+ instructions below apply only to computers using Lilo, which in the
+ context of this book means x86_64 Pure64 systems. Information on
+ <quote>boot loading</quote> for other architectures should be available in
+ the usual resource-specific locations for those architectures.</para>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../x86/grub.xml"
xpointer="xpointer(//*[@os='b'])"/>
- <para os="c">If you have multiple systems on your machine using a
- different bootloader such as GRUB, you may prefer to use that
- instead - consult the appropriate documentation. The rest of
- this section assumes you are going to use Lilo.</para>
+ <para os="c">If you have multiple systems on your machine using a different
+ bootloader such as GRUB, you may prefer to use that instead - consult the
+ appropriate documentation. The rest of this section assumes you are going
+ to use Lilo.</para>
<para os="d">Earlier, we compiled and installed the Lilo boot loader
- software in preparation for this step. The procedure involves
- writing a boot image to a specific location on the hard drive.
- We highly recommend using mkrescue to create a Lilo boot CD
- (using e.g. dvdrecord from dvdrtools) as a backup (this requires
- loopback block device support in the kernel).</para>
+ software in preparation for this step. The procedure involves writing a
+ boot image to a specific location on the hard drive. We highly recommend
+ using <command>mkrescue</command> to create a Lilo boot CD (using e.g.
+ <command>dvdrecord</command> from dvdrtools) as a backup (this requires
+ loopback block device support in the kernel).</para>
- <para os="e">Normally, you interact with Lilo by using the cursor
- and <literal>enter</literal> keys to select from the available
- option(s), but sometimes it is necessary to add other boot
- options, such as e.g. 'init=/bin/bash' to debug boot failures.
- The more your keyboard layout differs from the US qwerty layout,
- the harder it becomes to type boot options unless Lilo knows
- about your keyboard layout. So, we will create a key table for
- Lilo (.ktl) file - at one point in the documentation these are
- referred to as .klt files, which may be a typo, but has been
- followed by some distros. The name, and location, are not
- important but it is conventional to put these in /boot with
- the name representing the key layout. For a British keyboard
- layout, the following command will achieve this:</para>
+ <para os="e">Normally, you interact with Lilo by using the cursor and
+ <literal>enter</literal> keys to select from the available option(s), but
+ sometimes it is necessary to add other boot options, such as e.g.
+ 'init=/bin/bash' to debug boot failures. The more your keyboard layout
+ differs from the US qwerty layout, the harder it becomes to type boot
+ options unless Lilo knows about your keyboard layout. So, we will create a
+ key table for Lilo (.ktl) file - at one point in the documentation these
+ are referred to as .klt files, which may be a typo, but has been followed
+ by some distros. The name, and location, are not important but it is
+ conventional to put these in <filename class="directory">/boot</filename>
+ with the name representing the key layout. For a British keyboard layout,
+ the following command will achieve this:</para>
<screen os="f" role="nodump"><userinput>keytab-lilo.pl uk >/boot/uk.ktl</userinput></screen>
- <para os="g">The argument to the command is the name of the keymap,
- or if necessary you can specify the full path to the keymap. Use
- whatever is appropriate for your keyboard.</para>
+ <para os="g">The argument to the command is the name of the keymap, or if
+ necessary you can specify the full path to the keymap. Use whatever is
+ appropriate for your keyboard.</para>
- <para os="h">When the x86 CLFS book used to include Lilo, it
- advised against running it from chroot in case the MBR became
- corrupted. Provided you have /proc mounted and have device special
- files for the disks, it seems to be safe to run recent versions of
- Lilo in chroot, although it is always possible that an updated
- bootloader, or defective configuration file, may render the system
- unbootable.</para>
+ <para os="h">When the x86 CLFS book used to include Lilo, it advised
+ against running it from chroot in case the MBR became corrupted.
+ Provided you have <filename class="directory">/proc</filename> mounted
+ and have device special files for the disks, it seems to be safe to run
+ recent versions of Lilo in chroot, although it is always possible that
+ an updated bootloader, or defective configuration file, may render the
+ system unbootable.</para>
- <para os="i">The next step is to create /etc/lilo.conf:</para>
+ <para os="i">The next step is to create
+ <filename>/etc/lilo.conf</filename>:</para>
<screen os="j" role="nodump"><userinput>cat > /etc/lilo.conf << "EOF"
<literal># Begin /etc/lilo.conf
@@ -99,10 +98,10 @@
<para os="k">Replace <bootdisk> with the name of the disk (or
- partition) on which the boot sector is to be written, e.g. sda.
- Replace <keytable> with the name of the keytable file you
- created, and <partition> with the name of the root partition
- for the new system.
+ partition) on which the boot sector is to be written, e.g. sda.
+ Replace <keytable> with the name of the keytable file you
+ created, and <partition> with the name of the root partition
+ for the new system.
</para>
<warning os="l">
@@ -115,22 +114,23 @@
<screen os="n" role="nodump"><userinput>/sbin/lilo -v</userinput></screen>
<note os='o'>
- <para>People who have been used to GRUB need to be aware that
- Lilo works differently - in particular, you cannot edit the
- available choices as you can in the <command>grub</command> shell,
- and Lilo records the block addresses of the kernels into the boot
- blocks each time /sbin/lilo is run. This means that when you
- compile a new kernel, you have to add it to /etc/lilo.conf and
- rerun /sbin/lilo. It also means that if you recompile an existing
- kernel and save it to the same name you still have to rerun /sbin/lilo
- in case it now occupies different blocks on the filesystem.</para>
+ <para>People who have been used to GRUB need to be aware that Lilo works
+ differently - in particular, you cannot edit the available choices as you
+ can in the <command>grub</command> shell, and Lilo records the block
+ addresses of the kernels into the boot blocks each time
+ <command>/sbin/lilo</command> is run. This means that when you compile a
+ new kernel, you have to add it to <filename>/etc/lilo.conf</filename> and
+ rerun <command>/sbin/lilo</command>. It also means that if you recompile
+ an existing kernel and save it to the same name you still have to rerun
+ <command>/sbin/lilo</command> in case it now occupies different blocks on
+ the filesystem.</para>
</note>
- <para os="p">If you are running multiple systems on this box and
- using Lilo, it is a good idea to ensure that each system is running
- the same version of Lilo, otherwise an old version may not be able
- to overwrite the bootloader from a newer version. You will also
- need to ensure that the copies of /etc/lilo.conf on each system are
- kept synchronised.</para>
+ <para os="p">If you are running multiple systems on this box and using
+ Lilo, it is a good idea to ensure that each system is running the same
+ version of Lilo, otherwise an old version may not be able to overwrite
+ the bootloader from a newer version. You will also need to ensure that the
+ copies of <filename>/etc/lilo.conf</filename> on each system are kept
+ synchronised.</para>
</sect1>
More information about the Clfs-commits
mailing list