| AutoYast2: SLES8 - Automatic Linux Installation and Configuration with YaST2 | ||
|---|---|---|
| <<< Previous | Chapter 5. Autoinstallation | Next >>> |
There are different methods for booting the client. The computer can boot from its network interface card (NIC) to receive the boot images via DHCP /TFTP or a suitable kernel as well as an initrd image are loaded from a floppy or a bootable CDROM.
For testing/rescue purposes or because the NIC does not have a PROM or PXE you can build a boot floppy to use with AutoYaST2. Using a floppy to initiate an auto-install process is limited due to the size of the data a floppy can hold. However, it is still possible to use floppies when auto-installing a single, disconnected machine.
Floppies can be used to store the control file, especially when using the original SuSE CD-ROMs for a single, disconnected machine. Using the kernel command line, you can specify the location of the control file on the floppy. (See "Control file on a Floppy")
Even without specifying any command line options, it is still possible to initiate the auto-install process by placing a control file on a floppy with a special, pre-defined file name. (autoinst.xml) YaST2 will check for autoinst.xml upon startup and if it was found it will switch from interactive to automated installation.
For administrative purposes, booting from network card (NIC) is much more suitable than booting from a floppy. In order to use this boot method, the client's NIC needs a boot PROM that is able to communicate with a DHCP server to receive communication-related configuration parameters such as network addresses and which additionaly is capable of communicating with a TFTP-server to get the boot image.
Etherboot and netboot are capable of creating a PROM binary (which must still be programmed onto a PROM) and a corresponding "tagged" TFTP boot image which includes a kernel and an initial ramdisk. Some tools exist that help test a boot PROM image, in fact the support utilities are pretty much common to both etherboot and netboot.
Another alternative to etherboot and netboot is to use a PXE-compliant boot PROM. PXE (Pre-boot Execution Environment) is a protocol designed by Intel that allows computers to boot through the network. PXE is stored in the ROM of new generation network cards. When the computer boots up, the BIOS loads the PXE ROM in the memory and executes it. A menu is displayed, allowing the computer to boot an operating system loaded through the network.
To install a client via Pre-Boot Execution Environment (PE) you don't need a PE server! PE uses a BOOTP request to get an IP address and other network information and a bootloader program to the client. You can either use a BOOTP server for doing this or a DHCP and TFTP server.
In the following sections, you will find a description of how DHCP and TFTP should be setup to make PE installations possible.
Install the DHCP server from ISC (http://www.isc.org/) by using the package available in the SuSE distribution. Configure the DHCP server parameter in /etc/sysconfig/dhcpd and make sure you have a working configuration file /etc/dhcpd.conf.
PXE can load a program into the client's memory and start it. The bootloader then loads its configuration file via TFTP from the the server defined in next-server (in the dhcpd.conf file example above).
The bootloader configuration file determines whether a client boots from its local hard disk or over the network.
Here are example configuration files for both cases:
Example 5-1. Configuration file for PXELINUX net boot
default linux serial 0,9600n8 label linux kernel linux append console=ttyS0,9800 console=tty0 load_ramdisk=1 initrd=initrd autoyast=nfs://nfsserv/file.xml |
Boot from local hard disk (filename default):
pxelinux.0 tries to read several configuration files. It uses the first one it finds. The filenames it looks for are determined by the IP address of the client it is running on. It converts the four decimal number parts of an IP address (they are devided by dots) into hexadecimal numbers and concatenates them. Example: IP address 192.168.0.11 gets converted into C0 A8 00 0B (without the spaces).
The search for files starts at C0A8000B and proceeds by removing one digit from the right (leaving C0A8000) and so forth. When all digits are removed it will try as last resort the filename default.
On your TFTP server, this algorithm can be used to tell each single machine how to boot:
Example 5-3. PXELINUX Configuration
/tftpboot/pxelinux.cfg/
C0A8000B -> default.netboot-8.0
C0A8000C -> default.netboot-8.1
default.netboot-8.0
default.netboot-8.1
default
|
This is important if you install a lot of machines at the same time. You can watch the syslog file on your TFTP server and whenever a client got its initial RAM disk transmitted, you can remove the symlink for that machine from the pxelinux.cfg directory. This forces the client to load the default configuration which says: "Boot from local disk!" when it reboots after AutoYaST is done.
PXE requires a special TFTP server. Read pxelinux.doc from the already mentioned syslinux package for details.
The inetd based TFTP server cannot reliably handle much more than 64 clients at a time! With more clients not all of them will get an answer from your TFTP and you will see syslog messages like this:
tftpd: read: Connection refused. |
To overcome this problem you can use atftp which is available as a package. This TFTP server can run as stand-alone daemon.
The TFTP server directory /tftpboot should look like this:
See next section for how to get the files linux and initrd.
For network booting and other configurations, it is recommended to use the images available on every SuSE CD-ROM in the directory /suse/images/boot. The initial ramdisk (initrd) contains all kernel modules needed for successful installation. In special cases, you might need to build you own kernel or use special kernels available on the CD-ROM.
To allow the specification of the source media location when booting over the network, another DHCP option can be used.The root-path option as shown in the next example.
Example 5-5. /etc/dhcpd.conf with the root-path option
subnet 192.168.1.0 netmask 255.255.255.0
{
range dynamic-bootp 192.168.1.100 192.168.1.110;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
filename "vmlinuz.nbi";
option root-path "/tftpboot/CDs";
next-server 192.168.1.1;
}
|
One more example shows how the DHCP server can send an image to the client, depending on the type of the requesting client (PXE or Etherboot).
Example 5-6. DHCP server configuration with PXE and Etherboot options
ddns-update-style none;
allow bootp;
allow booting;
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.100 192.168.1.110;
option domain-name "cluster.suse.de";
option routers 192.168.1.240;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
filename "vmlinuz-node.nbi";
option root-path "/local/CD1";
}
group {
next-server 192.168.1.240;
use-host-decl-names on;
host n1 {
hardware ethernet 00:00:1c:b5:6e:71;
fixed-address n1;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
filename "/tulip.lzpxe";
} else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/vmlinuz-node.nbi";
}
}
host n2 {
hardware ethernet 00:00:1c:b5:72:ea;
fixed-address n2;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
filename "pxelinux.0";
} else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/vmlinuz-node.nbi";
}
}
}
|
You can use the original SuSE CD-ROMs in combination with other media, i.e. with a floppy to hold the control file or in combination with network where the control file can be located.
It is also possible to create customized CD-ROMs to hold only the package you need in addition to the control file which also can be saved on the CD-ROM. This method requires creation of CD-ROMs every time you wish to change the configuration though.
| <<< Previous | Home | Next >>> |
| Auto-installing a loose system | Up | Installation Server Setup |