wiley publishing suse linux 9 bible phần 10 ppsx

554 Part V ✦ SUSE Linux in the Enterprise Upgrading a Kernel Package Upgrading from one kernel package to another is simple; you just need to install the new package using the rpm command. If you want to retain the ability to run the old kernel, you should back up the files called /boot/vmlinuz-<version number> and /boot/ initrd-<version-number> and also the directory /lib/modules/<version-number>/ and restore them after you have installed the new kernel RPM. You also want to check that you have an entry in the GRUB configuration for the old kernel and possibly do a mkinitrd (see the section “Building the Kernel” later in the chapter). If you use LILO for booting, check the LILO configuration and rerun LILO before rebooting. Kernel Configuration To be able to build kernels, you obviously need the kernel source package (called kernel- source) installed. In addition, you need gcc, make, and a number of other packages. One of the SUSE installation package set options is “Kernel development”; if you have installed that selection, you have everything you need. If you want to base your kernel configuration on the currently running kernel, you have more than one way to begin. The configuration of the kernel that is actually running is always available in /proc/config .gz, which is a gzipped “virtual” file in the /proc filesystem, which is created in memory on the fly by the running kernel (see Listing 27-1). Listing 27-1: Looking at the Configuration of the Running Kernel root@bible: /proc # zcat config.gz | more # # Automatically generated make config: don’t edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # CONFIG_STANDALONE is not set CONFIG_BROKEN_ON_SMP=y # # General setup 37_577395 ch27.qxd 12/15/04 12:28 AM Page 554 555 Chapter 27 ✦ The Kernel It is instructive to page through this file and look at the various options in it that refer to the hardware, filesystems, and so on that are to be supported by the kernel. ✦ The =y at the end of lines means that the support for the relevant item is compiled into the kernel. ✦ Lines ending is not set clearly imply that the support is not included. ✦ Lines ending =m imply that the support is provided by a loadable kernel module rather than being compiled into the kernel itself. SUSE provides most functionality in the form of modules. In a newly installed system, you should find that /usr/src/linux/.config is identical to /boot/config-<version-number>-default and to the content of /proc/config.gz when uncompressed. The kernel build process takes place in /usr/src/linux/, which is a symbolic link to /usr/src/linux-<version number>/ (for example, /usr/src/ linux-2.6.5-7.79/). The commands that you use to build the kernel must be issued in this directory because they refer to the top-level kernel makefile, which is /usr/src/linux/Makefile. The configuration file for building the kernel is the file .config in this directory. If this file does not exist, you need to create it for the first time. If the kernel that is running is the exact same version that the source code is for, you can simply do this: root@bible:~ # zcat /proc/config.gz > /usr/src/linux/.config root@bible:~ # cd /usr/src/linux/ root@bible: /usr/src/linux-2.6.5-7.79/ # make oldconfig You may want to back up any existing .config file first. Alternatively, the command make cloneconfig has exactly the same effect. If the version of the kernel source is newer than the running kernel, then the command make oldconfig is what you need. Creating a new kernel configuration can be done in essentially one of three ways. ✦ If you type root@bible: ~ # cd /usr/src/linux/ root@bible: /usr/src/linux-2.6.5-7.79/ # make config (note that the version number you see on the directory depends on the kernel source version that is installed), you will see something like this: root@bible: /usr/src/linux-2.6.5-7.79/ # make config scripts/kconfig/conf arch/i386/Kconfig drivers/char/lirc/Kconfig:102:warning: ‘select’ used by config symbol ‘LIRC_SIR’ refer to undefined symbol ‘LIRC_SIR_IRDA’ # # using defaults found in .config # * * Linux Kernel Configuration * Tip 37_577395 ch27.qxd 12/15/04 12:28 AM Page 555 556 Part V ✦ SUSE Linux in the Enterprise * * Code maturity level options * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] Y Select only drivers expected to compile cleanly (CLEAN_COMPILE) [Y/n/?] Y Select only drivers that don’t need compile-time external firmware (STANDALONE) [N/y/?] * * General setup * Support for paging of anonymous memory (swap) (SWAP) [Y/n/?] This is simply a series of questions and answers; there is no way to go back, and it cer- tainly could not be described as “user friendly.” ✦ A more pleasant method is the following: root@bible: /usr/src/linux-2.6.5-7.79 # make menuconfig This requires the ncurses-devel package to be installed. You will see a screen some- thing like the one in Figure 27-1. Figure 27-1: Using make menuconfig for kernel configuration This is a much nicer text-based, menu-driven interface that splits the items into sec- tions and submenus. When you have completed your selections, save the configuration file (see Figure 27-2). 37_577395 ch27.qxd 12/15/04 12:28 AM Page 556 557 Chapter 27 ✦ The Kernel Figure 27-2: Saving the configuration ✦ However, the nicest interface is the graphical one that you can get by running the command root@bible: /usr/src/linux-2.6.5-7.79 # make xconfig This requires the qt3-devel package to be installed to create the graphical user inter- face. This contains exactly the same information as the other two systems but is easier to navigate and is a new interface (previously make xconfig used the less elegant Tk graphical toolkit to create its graphical user interface). See Figures 27-3 and 27-4 for examples of the interface. A nice feature of this interface is that if you choose Options➪ Show all Options, you can see the name of each kernel configuration variable, the possible values it can have, and its current setting. There is also an option make gconfig that uses the GTK+ libraries for a GNOME-like interface. Whichever interface you use for configuring the kernel, most items offer the choice of y, m, or n (in the xconfig interface these are represented by a tick in the checkbox, a dot in the checkbox, and an empty checkbox, respectively): ✦ y means “Compile this option into the kernel.” ✦ m means “Compile this option as a module.” ✦ n means “Don’t include this option.” When you have saved your configuration, you will have a new .config file. This is the one you will use when you start building the kernel. Tip 37_577395 ch27.qxd 12/15/04 12:28 AM Page 557 558 Part V ✦ SUSE Linux in the Enterprise Figure 27-3: Using make xconfig for kernel configuration Figure 27-4: Selecting options in the xconfig interface 37_577395 ch27.qxd 12/15/04 12:28 AM Page 558 559 Chapter 27 ✦ The Kernel Building the Kernel Now, assuming the architecture is x86, you need to do the following: root@bible: /usr/src/linux-2.6.5-7.79/ # make bzImage Historically, the b stands for big, and the z indicates that it is a compressed image. On other architectures, the command you need is different. Details specific to SUSE are available at www.suse.de/~agruen/kernel-doc/. This is where the real work gets done. In the 2.6 kernels, by default you see slightly less out- put on the screen than before (see Listing 27-2). Listing 27-2: Output from the Kernel Build Process root@bible: /usr/src/linux-2.6.5-7.79/ # make bzImage SPLIT include/linux/autoconf.h -> include/config/* make[1]: `arch/i386/kernel/asm-offsets.s’ is up to date. CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o CC init/kerntypes.o IKCFG kernel/ikconfig.h GZIP kernel/config_data.gz IKCFG kernel/config_data.h CC kernel/configs.o LD kernel/built-in.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o [ ] When the build process has completed, all being well, you will see a message similar to this: Root device is (3, 1) Boot sector 512 bytes. Setup is 5039 bytes. System is 1426 kB Kernel: arch/i386/boot/bzImage is ready You can now navigate to that directory and see the file that has been created. root@bible: ~ # cd /usr/src/linux/arch/i386/boot/ root@bible: /usr/src/linux-2.6.5-7.79/arch/i386/boot/ # ls –l bzImage You should see a brand-new file bzImage with a timestamp showing that it has just been created. 37_577395 ch27.qxd 12/15/04 12:28 AM Page 559 560 Part V ✦ SUSE Linux in the Enterprise When you’ve made the bzImage, you have several more steps to perform: 1. Build the modules: root@bible: /usr/src/linux-2.6.5-7.79/ # make modules Note that if you simply issue the command make or make all, the bzImage and the modules will be built in one step. 2. Install the kernel and the modules: root@bible: /usr/src/linux-2.6.5-7.79/ # make install This copies the bzImage file to the /boot directory. (Before you do this you may want to back up the old kernel, particularly if it has the same version number.) root@bible: /usr/src/linux-2.6.5-7.79/ # make modules_install 3. Create a new initial ramdisk to correspond to the new kernel: root@bible: /usr/src/linux-2.6.5-7.79/ # mkinitrd 4. Check that both the new and old kernels are referenced in the GRUB menu so that you can go back to the old kernel if you need to. Edit the file /boot/grub/menu.lst to con- firm this. If you use LILO for booting, you need to both edit /etc/lilo.conf to ensure that both the new and old kernels are included and run the lilo command. Now, all being well, you can reboot and select the new kernel. If you have compiled things into the kernel that were previously being loaded as mod- ules, it is important that these modules themselves should not be loaded when the new ker- nel is booted; otherwise, unexpected problems could occur. You may need to adjust /etc/ modprobe.conf in this case. Rebuilding the km_* Packages A number of packages have names beginning with km_. These packages contain source code for additional external kernel modules that you may need to compile separately to add sup- port for certain things. For example, the km_ocfs package adds support for the Oracle Cluster File System (OCFS), and the km_smartlink-softmodem package adds support for a certain class of “winmodems.” You can find these packages by searching for “km_” in YaST’s software module. To make use of these packages, you must have the source for the running kernel installed. When you install these packages, they install the relevant source code to a directory under /usr/src/kernel-modules/. To add support for OCFS, for example, change to the directory /usr/src/kernel-modules/ocfs2/, and then issue the commands: # make modules KERNEL_SOURCE=/usr/src/linux # make install KERNEL_SOURCE=/usr/src/linux Alternatively, you can issue this command: # make -C /usr/src/linux SUBDIRS=$PWD modules Caution 37_577395 ch27.qxd 12/15/04 12:28 AM Page 560 561 Chapter 27 ✦ The Kernel This runs the make command in /usr/src/linux while referring to the current directory to find the module code. You will then find that the module has been built and installed as: /lib/modules/<version-number>-default/extra/ocfs2.ko If you install a new kernel, you will need to rebuild these modules, whether or not you build the new kernel from source. The kernel and third-party software Third-party commercial software that requires low-level kernel support is sometimes run only on or with particular kernel versions. In the worst case this is because the vendor ships binary-only kernel modules, but even when a module source is shipped that needs to be built against the running kernel, it can be limited to very specific kernel versions. This can be a real problem, particularly when a kernel update is recommended by SUSE (for example, for security reasons) and vendors are slow to respond. The problem can be worse if you are try- ing to run two such pieces of software at the same time. Consider the following example of this kind of problem in a production environment: A cus- tomer needed to run a piece of proprietary software allowing multipath access to storage area network (SAN) storage and at the same time needed to run a third-party clustering solu- tion with kernel modules for its filesystem. Although both of these products supported the version of SLES that the customer was running, when you looked at the small print, things were more difficult because only one version of the kernel package among the various updates provided by SUSE worked with both products. And that kernel version was not the latest and had been officially superceded because of a security patch. These problems will persist until all third-party vendors gain a better understanding of the dynamics of Linux and realize that releasing their code in a more flexible and open way does not necessarily prevent them from making money from their products. When certain third-party modules load, you will see a message of the form: Warning: loading <module file> will taint the kernel: non-GPL license - Proprietary. [ ] See <http://www.tux.org/lkml/#export-tainted> for information about tainted modules Module <module file> loaded, with warnings This indicates that a module with a non-GPL license is being loaded into the kernel. This warning is not simply about software ideology: When proprietary (and particularly binary- only) modules are loaded, little can be done to debug any problems they may cause. Kernel of the Day The SUSE FTP server always has a so-called “kernel of the day,” which is the latest test kernel, with versions available for each supported architecture. This is available at ftp://ftp.suse.com/pub/ projects/kernel/kotd/. It goes without saying that these kernels should be used only with cau- tion because they have not been officially released and are provided for testing purposes. 37_577395 ch27.qxd 12/15/04 12:28 AM Page 561 562 Part V ✦ SUSE Linux in the Enterprise Loading kernel modules In the 2.6 kernel, kernel modules have filenames ending with .ko (rather than .o as in 2.4). To check what modules are loaded: root@bible: ~ # lsmod Module Size Used by nls_cp437 6016 0 vfat 14208 0 fat 43584 1 vfat usb_storage 60096 0 nls_iso8859_1 4352 2 udf 85380 0 nls_utf8 2304 0 [ ] Dependencies between modules are indicated in the last column of the output. To load a module manually, you use the following: root@bible: ~ # modprobe tulip To unload a module, use the following: root@bible: ~ # rmmod tulip The automatic loading of modules is now (in 2.6 kernels) controlled by the file /etc/ modprobe.conf, which has replaced the /etc/modules.conf file. The file /lib/modules/<version-number>-default/modules.dep contains a listing of all the dependencies between available modules. This file can be regenerated if necessary by the command depmod -a. Kernel Parameters at Boot Time You can pass parameters to the kernel at boot time either permanently by editing the GRUB configuration file or temporarily by typing at the boot prompt. These control the behavior of the kernel when it boots in various ways. Current versions of SUSE use the showopts keyword in the GRUB configuration file, which has the unfortunate effect of hiding the parameters that are being passed. Actually what this keyword does is to hide the options that are listed before it and show those that appear after it. If you remove showopts from the default entry line in /boot/grub/menu.lst, then at the next boot you will see exactly which boot parameters are being passed to the kernel when it loads. You will also be able to edit these parameters in the initial boot screen. A list of supported parameters and their meanings are in the file: /usr/src/linux/Documentation/kernel-parameters.txt A few examples of parameters that you might want to pass at boot time are as follows: ✦ root=/dev/hda3 — Sets the root device ✦ vga=791 — Sets the framebuffer resolution to 1024 × 768 37_577395 ch27.qxd 12/15/04 12:28 AM Page 562 563 Chapter 27 ✦ The Kernel See Chapter 8 for more information on framebuffer graphics and resolution. ✦ acpi=off — Disables Advanced Configuration and Power Interface (ACPI), often required on troublesome hardware ✦ ide=nodma — Disables Direct Memory Access (DMA) access to IDE disks ✦ noapic — Does not use the APIC interrupt controller These last three will be seen as part of the failsafe entry in /boot/grub/menu.lst because each of them can solve common problems with particular hardware. The Initial Ramdisk As the system boots, it needs drivers for (for example) the disk controllers and the filesys- tems on the hard disk; otherwise, it will not be able to mount the disks. The necessary drivers may not be included in the kernel itself but loaded as drivers. This is not a problem on the running system but can create a “chicken and egg” situation at boot time. This prob- lem is solved by loading the initrd into memory at boot time. (Typically the initrd loaded is whatever is pointed to by the symbolic link /boot/initrd, but a different initrd can be speci- fied if required in the GRUB menu /boot/grub/menu.lst. The initrd is in fact a compressed EXT2 filesystem that is decompressed and loaded into memory at initial boot time.) The ini- trd and the kernel are loaded in the same way: either directly from known physical locations on the boot device (in the case of LILO) or through the use of a boot loader that is capable of reading at the filesystem “from the outside” (in the case of GRUB). The initrd is then mounted temporarily by the kernel prior to the mounting of the disk partitions. Exactly what the initrd includes is set in the file /etc/sysconfig/kernel in the INITRD_MODULES variable. On a desktop machine, this may simply look like this: INITRD_MODULES=”reiserfs” If you have SCSI disks, it will almost certainly need to include a driver for the disk controller. This will normally be handled correctly during installation, but there are occasions when you may need to change this manually. Having done so, you will need to run the command mkinitrd to create a new initrd with the correct modules included. Once the initrd has been created, if you reboot, the necessary support should be present. See Chapter 4 for a description of the booting process. Although the process described in this chapter for configuring and building a kernel from source is an interesting one, it is probably not something you will often need to do in prac- tice. If you are running SLES in a production environment, SUSE will probably not give you support for a self-built kernel unless they themselves have recommended this course of action for a specific reason. It is, however, certainly useful to have some familiarity with the process, and it is interesting and instructive to look around in /usr/src/linux/, particularly in the Documentation subdirectory. ✦✦✦ Cross- Reference Note Cross- Reference 37_577395 ch27.qxd 12/15/04 12:28 AM Page 563 [...]... UnitedLinux consortium was a collaboration between four Linux vendors (SUSE, TurboLinux, Connectiva, and SCO) with SUSE as the main development partner The aim was to produce a core Enterprise Linux distribution on top of which vendors could create their own products In the case of SUSE, the products created on top of the UnitedLinux base were SLES 8, SUSE Linux OpenExchange Server, and SUSE Linux. .. UnitedLinux SUSE, Caldera, and TurboLinux, along with the major vendors, decided that a base, certified Linux distribution was needed so that vendors could certify against it Since the SCO lawsuit, UnitedLinux has been disbanded, but SUSE has still used the UnitedLinux base as the certified platform for SUSE Linux Enterprise Server (SLES) 8 and SLOX As SUSE was the distributor that UnitedLinux was written... for your network 6 As with normal SUSE installation, enter the IP and subnet mask of the node (see Figure 29- 7) and click Next 587 588 Part V ✦ SUSE Linux in the Enterprise Figure 29- 6: Configuring your network Figure 29- 7: Configuring the IP address of the SLOX installation Chapter 29 ✦ SUSE Linux OpenExchange Server 7 When configuring the name resolution (see Figure 29- 8), you must be sure that your... Relating the Standard Server to SUSE Linux Enterprise Server Installing the Standard Server Working with the web interface ✦ ✦ ✦ 566 Part V ✦ SUSE Linux in the Enterprise Standard Server Structure In common with SLES 8 and the SUSE Linux OpenExchange Server (SLOX), the Standard Server is a UnitedLinux-based product (UnitedLinux is the core of SLES 8 and was developed by SUSE but used by certain other... we have set the domain to be susebible.com By default, SLOX is able to receive mail for user@susebible.com without any further configuration You can further configure SLOX once installed to receive mail for other domains, and we talk about this later in the chapter Figure 29- 8: Configuring name resolution 8 Set the default route for the SLOX installation (see Figure 29- 9) 9 After the network has been... UnitedLinux and SLOX disks a few times When all packages have been installed, YaST initializes the system configuration and proceeds to boot to SLOX and continue with the configuration of SLOX itself Figure 29- 2: Changing your system configuration before installation Chapter 29 ✦ SUSE Linux OpenExchange Server Configuring UnitedLinux The SLOX system’s base operating system is the now deprecated UnitedLinux...28 C H A P T E R The SUSE Linux Standard Server ✦ ✦ ✦ ✦ In This Chapter T he SUSE Linux Standard Server was introduced by SUSE some time after the release of SUSE Linux Enterprise Server (SLES) 8, and it was marketed partly as an “entry-level” version of the Enterprise Server But its real distinguishing... the supportability by SUSE of any business products they provide The configuration of UnitedLinux is very similar to the installation of a normal SUSE system: 1 When the system configuration has been saved and YaST has booted into your installed system, you will be asked for the root password (see Figure 29- 3) Figure 29- 3: Setting the root user password 585 586 Part V ✦ SUSE Linux in the Enterprise... you are happy with the X configuration, YaST will run SuSEconfig to commit the changes to the system 4 As with the standard SUSE installation, you will be asked to configure ancillary hardware (see Figure 29- 5) If you want to use SLOX to provide printing for your network, you can configure it here Chapter 29 ✦ SUSE Linux OpenExchange Server Figure 29- 5: Configuring ancillary hardware 5 When you are happy... interface makes it a viable solution for Linux newcomers When it is set up on a small network, the only frequent interventions required are likely to be for the addition of users or machines to the network ✦ ✦ ✦ 29 C H A P T E R SUSE Linux OpenExchange Server ✦ ✦ ✦ ✦ In This Chapter Installing SLOX Administering SLOX O ne of SUSE s most popular business products, SUSE Linux OpenExchange Server (SLOX) provides . for, you can simply do this: root @bible: ~ # zcat /proc/config.gz > /usr/src /linux/ .config root @bible: ~ # cd /usr/src /linux/ root @bible: /usr/src /linux- 2.6.5-7. 79/ # make oldconfig You may want. ch27.qxd 12/15/04 12:28 AM Page 564 The SUSE Linux Standard Server T he SUSE Linux Standard Server was introduced by SUSE some time after the release of SUSE Linux Enterprise Server (SLES) 8, and. products. In the case of SUSE, the products created on top of the UnitedLinux base were SLES 8, SUSE Linux OpenExchange Server, and SUSE Linux Standard Server. The UnitedLinux consortium is no