- Timestamp:
- Jun 3, 2009, 12:23:23 AM (15 years ago)
- Branches:
- clfs-1.2, clfs-2.1, clfs-3.0.0-systemd, clfs-3.0.0-sysvinit, master, systemd, sysvinit
- Children:
- 093b0e8
- Parents:
- 984ac82
- Location:
- BOOK/bootable
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
BOOK/bootable/alpha/aboot.xml
r984ac82 r968933d 16 16 </indexterm> 17 17 18 <para os="a">Create a <filename>aboot.conf</filename> file defining aboot's boot18 <para os="a">Create an <filename>aboot.conf</filename> file defining aboot's boot 19 19 menu:</para> 20 20 -
BOOK/bootable/alpha/kernel.xml
r984ac82 r968933d 27 27 28 28 <para os="a3">The following sed prevents GCC from treating warnings as 29 errors when the kernel is compiled .</para>29 errors when the kernel is compiled:</para> 30 30 31 31 <screen os="a4"><userinput>sed -i "s/-Werror//" arch/alpha/kernel/Makefile</userinput></screen> -
BOOK/bootable/mips/arcload.xml
r984ac82 r968933d 43 43 EOF</userinput></screen> 44 44 45 <para os="c">Now we use dvhtool to make the system bootable:</para> 45 <para os="c">Now we use <command>dvhtool</command> to make the system 46 bootable:</para> 46 47 47 48 <screen os="d"><userinput>dvhtool --unix-to-vh /usr/lib/arcload/sash sash -
BOOK/bootable/mips64/arcload.xml
r984ac82 r968933d 43 43 EOF</userinput></screen> 44 44 45 <para os="c">Now we use dvhtool to make the system bootable:</para> 45 <para os="c">Now we use <command>dvhtool</command> to make the system 46 bootable:</para> 46 47 47 48 <screen os="d"><userinput>dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64 -
BOOK/bootable/ppc/yaboot.xml
r984ac82 r968933d 29 29 in preparation for this step. The procedure involves writing the bootloader 30 30 to a bootstrap partition and blessing it so that Open Firmware will boot from 31 it. This is all handled by <command>ybin</command> the yaboot installer.</para>31 it. This is all handled by <command>ybin</command>, the yaboot installer.</para> 32 32 33 33 <para os="d">Ybin writes an optional 'OS selector' menu into Open Firmware, 34 then writes yaboot and yaboot.conf to the bootstrap partition, blesses this, 35 and updates the boot device recorded in nvram. When booted, the OF provides 36 the initial menu to choose between linux, boot from CD, and e.g. OSX 37 (depending on what was in yaboot.conf). If you boot to 'linux', yaboot is 38 executed and lets you select which kernel to use.</para> 34 then writes yaboot and <filename>yaboot.conf</filename> to the bootstrap 35 partition, blesses this, and updates the boot device recorded in nvram. When 36 booted, the OF provides the initial menu to choose between linux, boot from 37 CD, and e.g. OSX (depending on what was in <filename>yaboot.conf</filename>). 38 If you boot to 'linux', yaboot is executed and lets you select which kernel 39 to use.</para> 39 40 40 41 <para os="e">Images (kernels) are specified, together with any necessary path, 41 in yaboot.conf - the details are incorporated into the bootloader, but no attempt 42 is made to access or validate the paths until they are selected. There are many 43 possible options that can be specified in yaboot.conf, see the man page for the 44 details. Most people will be able to specify device=hd: (for a single hard disk), 45 but if you have multiple disks, or if you wish to be pedantic, you can specify the 42 in <filename>yaboot.conf</filename> - the details are incorporated into the 43 bootloader, but no attempt is made to access or validate the paths until 44 they are selected. There are many possible options that can be specified in 45 <filename>yaboot.conf</filename>, see the man page for the details. Most 46 people will be able to specify device=hd: (for a single hard disk), but if 47 you have multiple disks, or if you wish to be pedantic, you can specify the 46 48 full OF path to the device, obtained by running <command>ofpath /dev/hdX</command> 47 49 .</para> 48 50 49 51 <para os="h">Using the above information, determine the appropriate designators 50 for the bootstrap partition and the root partition. 52 for the bootstrap partition and the root partition. For the following example, 51 53 it is assumed that the bootstrap partition is <filename class="partition">hda2 52 </filename> and the root partition is <filename class="partition">hda7</filename> 53 .We will also assume that you wish to be able to boot an OSX installation on54 <filename class="partition">hda4</filename>. 54 </filename> and the root partition is <filename class="partition">hda7</filename>. 55 We will also assume that you wish to be able to boot an OSX installation on 56 <filename class="partition">hda4</filename>. Change these items as necessary 55 57 for your machine.</para> 56 58 57 59 <para os="i">If your machine has a SATA disk, specify the partitions using 58 60 <filename class="devicefile">/dev/sda7</filename> and so forth in the usual 59 way. 61 way. At least some of the distros specify a full OF path to the 'device' and 60 62 to the image(s), such as 61 63 <parameter>device=/ht@0,f2000000/pci@3/k2-sata-root@c/k2-sata@0/disk@0:</parameter> -
BOOK/bootable/x86_64-64/lilo.xml
r984ac82 r968933d 17 17 18 18 <para os="a">Your shiny new CLFS system is almost complete. One of the 19 last things to do is to ensure that the system can be properly 20 booted. The instructions below apply only to computers using Lilo, 21 which in the context of this book means x86_64 Pure64 systems. 22 Information on <quote>boot loading</quote> for other architectures 23 should be available in the usual resource-specific locations for 24 those architectures.</para> 19 last things to do is to ensure that the system can be properly booted. The 20 instructions below apply only to computers using Lilo, which in the 21 context of this book means x86_64 Pure64 systems. Information on 22 <quote>boot loading</quote> for other architectures should be available in 23 the usual resource-specific locations for those architectures.</para> 25 24 26 25 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" … … 28 27 xpointer="xpointer(//*[@os='b'])"/> 29 28 30 <para os="c">If you have multiple systems on your machine using a 31 different bootloader such as GRUB, you may prefer to use that32 instead - consult the appropriate documentation. The rest of33 this section assumes you are goingto use Lilo.</para>29 <para os="c">If you have multiple systems on your machine using a different 30 bootloader such as GRUB, you may prefer to use that instead - consult the 31 appropriate documentation. The rest of this section assumes you are going 32 to use Lilo.</para> 34 33 35 34 <para os="d">Earlier, we compiled and installed the Lilo boot loader 36 software in preparation for this step. The procedure involves37 writing a boot image to a specific location on the hard drive.38 We highly recommend using mkrescue to create a Lilo boot CD39 (using e.g. dvdrecordfrom dvdrtools) as a backup (this requires40 35 software in preparation for this step. The procedure involves writing a 36 boot image to a specific location on the hard drive. We highly recommend 37 using <command>mkrescue</command> to create a Lilo boot CD (using e.g. 38 <command>dvdrecord</command> from dvdrtools) as a backup (this requires 39 loopback block device support in the kernel).</para> 41 40 42 <para os="e">Normally, you interact with Lilo by using the cursor 43 and <literal>enter</literal> keys to select from the available 44 option(s), but sometimes it is necessary to add other boot 45 options, such as e.g. 'init=/bin/bash' to debug boot failures. 46 The more your keyboard layout differs from the US qwerty layout, 47 the harder it becomes to type boot options unless Lilo knows 48 about your keyboard layout. So, we will create a key table for 49 Lilo (.ktl) file - at one point in the documentation these are 50 referred to as .klt files, which may be a typo, but has been 51 followed by some distros. The name, and location, are not 52 important but it is conventional to put these in /boot with 53 the name representing the key layout. For a British keyboard 54 layout, the following command will achieve this:</para> 41 <para os="e">Normally, you interact with Lilo by using the cursor and 42 <literal>enter</literal> keys to select from the available option(s), but 43 sometimes it is necessary to add other boot options, such as e.g. 44 'init=/bin/bash' to debug boot failures. The more your keyboard layout 45 differs from the US qwerty layout, the harder it becomes to type boot 46 options unless Lilo knows about your keyboard layout. So, we will create a 47 key table for Lilo (.ktl) file - at one point in the documentation these 48 are referred to as .klt files, which may be a typo, but has been followed 49 by some distros. The name, and location, are not important but it is 50 conventional to put these in <filename class="directory">/boot</filename> 51 with the name representing the key layout. For a British keyboard layout, 52 the following command will achieve this:</para> 55 53 56 54 <screen os="f" role="nodump"><userinput>keytab-lilo.pl uk >/boot/uk.ktl</userinput></screen> 57 55 58 <para os="g">The argument to the command is the name of the keymap, 59 or if necessary you can specify the full path to the keymap. Use60 whatever isappropriate for your keyboard.</para>56 <para os="g">The argument to the command is the name of the keymap, or if 57 necessary you can specify the full path to the keymap. Use whatever is 58 appropriate for your keyboard.</para> 61 59 62 <para os="h">When the x86 CLFS book used to include Lilo, it 63 a dvised against running it from chroot in case the MBR became64 corrupted. Provided you have /proc mounted and have device special65 files for the disks, it seems to be safe to run recent versions of66 Lilo in chroot, although it is always possible that an updated67 bootloader, or defective configuration file, may render the system68 unbootable.</para>60 <para os="h">When the x86 CLFS book used to include Lilo, it advised 61 against running it from chroot in case the MBR became corrupted. 62 Provided you have <filename class="directory">/proc</filename> mounted 63 and have device special files for the disks, it seems to be safe to run 64 recent versions of Lilo in chroot, although it is always possible that 65 an updated bootloader, or defective configuration file, may render the 66 system unbootable.</para> 69 67 70 <para os="i">The next step is to create /etc/lilo.conf:</para> 68 <para os="i">The next step is to create 69 <filename>/etc/lilo.conf</filename>:</para> 71 70 72 71 <screen os="j" role="nodump"><userinput>cat > /etc/lilo.conf << "EOF" … … 100 99 101 100 <para os="k">Replace <bootdisk> with the name of the disk (or 102 103 104 105 101 partition) on which the boot sector is to be written, e.g. sda. 102 Replace <keytable> with the name of the keytable file you 103 created, and <partition> with the name of the root partition 104 for the new system. 106 105 </para> 107 106 … … 116 115 117 116 <note os='o'> 118 <para>People who have been used to GRUB need to be aware that 119 Lilo works differently - in particular, you cannot edit the 120 available choices as you can in the <command>grub</command> shell, 121 and Lilo records the block addresses of the kernels into the boot 122 blocks each time /sbin/lilo is run. This means that when you 123 compile a new kernel, you have to add it to /etc/lilo.conf and 124 rerun /sbin/lilo. It also means that if you recompile an existing 125 kernel and save it to the same name you still have to rerun /sbin/lilo 126 in case it now occupies different blocks on the filesystem.</para> 117 <para>People who have been used to GRUB need to be aware that Lilo works 118 differently - in particular, you cannot edit the available choices as you 119 can in the <command>grub</command> shell, and Lilo records the block 120 addresses of the kernels into the boot blocks each time 121 <command>/sbin/lilo</command> is run. This means that when you compile a 122 new kernel, you have to add it to <filename>/etc/lilo.conf</filename> and 123 rerun <command>/sbin/lilo</command>. It also means that if you recompile 124 an existing kernel and save it to the same name you still have to rerun 125 <command>/sbin/lilo</command> in case it now occupies different blocks on 126 the filesystem.</para> 127 127 </note> 128 128 129 <para os="p">If you are running multiple systems on this box and 130 using Lilo, it is a good idea to ensure that each system is running131 the same version of Lilo, otherwise an old version may not be able132 t o overwrite the bootloader from a newer version. You will also133 need to ensure that the copies of /etc/lilo.conf on each system are134 keptsynchronised.</para>129 <para os="p">If you are running multiple systems on this box and using 130 Lilo, it is a good idea to ensure that each system is running the same 131 version of Lilo, otherwise an old version may not be able to overwrite 132 the bootloader from a newer version. You will also need to ensure that the 133 copies of <filename>/etc/lilo.conf</filename> on each system are kept 134 synchronised.</para> 135 135 136 136 </sect1>
Note:
See TracChangeset
for help on using the changeset viewer.