Building a Kernel
This section shows an example of taking an existing kernel running on an Integrity (Itanium) server and making some changes to it. Figure 5-1 shows some commonly performed kernel-related steps. I perform many of these steps in the following example.
Figure 5-1 Commonly Performed Kernel Configuration Steps
Normally, you should change the kernel configuration before making any changes to it. To save the configuration, use -s and place a comment with -C as shown in the following command:
# kconfig -C "Initial configuration of vPars/Oracle/Peoplesoft system" -s Initial_vPars_Oracle_Peoplesoft * The current configuration has been saved to 'Initial_vPars_Oracle_Peoplesoft'. #
This command results in the following entry being made in /var/adm/kc.log:
====================================================================== Change to configuration 'Initial_vPars_Oracle_Peoplesoft' at 09:38:45 EDT on 21 September 2004 by root: Configuration saved from currently running configuration. Initial configuration of vPars/Oracle/Peoplesoft system
This is the last entry in /var/adm/kc.log immediately after the kconfig command was issued. The -s option results in this kernel having been saved in the directory /stand/Initial_vPars_Oracle_Peoplesoft, as shown in the following long listing of /stand:
Initial configuration of vPars/Oracle/Peoplesoft system
# ll /stand total 96976 drwxr-xr-x 5 root sys 8192 Sep 21 09:38 Initial_vPars_Oracle_Peoplesoft drwxr-xr-x 5 root sys 8192 Sep 21 09:11 backup dr-xr-xr-x 3 bin bin 96 May 5 15:46 boot.sys -rw-r--r-- 1 root sys 21 May 5 15:44 bootconf lrwxr-xr-x 1 root root 14 Sep 21 09:17 bootfs -> current/bootfs drwxr-xr-x 5 root root 8192 May 25 12:03 crashconfig drwxr-xr-x 5 root sys 8192 Sep 21 09:11 current drwxr-xr-x 5 root sys 8192 Sep 19 15:38 initial_11iv2 drwxr-xr-x 5 root sys 8192 Sep 12 20:28 installed -rw-r--r-- 1 root sys 16024 Sep 21 09:17 ioconfig -r--r--r-- 1 root sys 82 May 5 16:11 kernrel drwxr-xr-x 2 root sys 96 Sep 21 09:21 krs drwxr-xr-x 5 root sys 8192 May 5 16:12 last_install drwxr-xr-x 2 root root 96 May 5 15:43 lost+found lrwxr-xr-x 1 root root 7 Sep 21 09:17 nextboot -> current -rw------- 1 root root 12 Sep 21 09:17 rootconf lrwxr-xr-x 1 root root 15 Sep 21 09:17 system -> nextboot/system -r--r--r-- 1 root sys 1996 May 5 16:01 system.import -rw-r--r-- 1 root sys 2537 May 5 16:51 system.prev -rwxr-xr-x 5 root other 4656 Jun 15 15:49 vmunix #
This directory contains all files associated with the currently running kernel, as shown in the following long listing which are in the directory Initial_vPars_Oracle_Peoplesoft:
# ll total 96784 -rw-r--r-- 1 root sys 0 Sep 21 09:38 .config -rw-r--r-- 1 root sys 147 Sep 21 09:38 README drwxr-xr-x 3 root sys 96 Sep 21 09:38 bootfs drwxr-xr-x 2 root sys 96 Sep 21 09:38 krs drwxr-xr-x 2 root sys 96 Sep 21 09:38 mod -rw-r--r-- 1 root sys 2877 Sep 21 09:38 system -rwxr-xr-x 5 root other 49534656 Jun 15 15:49 vmunix #
This directory contains the currently running kernel vmunix, the current system file, and other files associated with the currently running kernel. You may also want to give each configuration a title using the -t option to kconfig.
At this point I am protected in that if I had to revert to the saved kernel configuration after making changes I can do so. Now that the current configuration has been saved I will view an existing tunable parameter and module that I plan to change with the following commands:
# kctune -d nproc Tunable Value Expression Changes Description nproc 4200 Default Immed Maximum number of processes on the system # kcmodule -d idds Module State Cause Description idds unused Intrusion Detection Data Source #
I also issue kcusage on a system before making a change to see the level of usage. If the system is not in use, however, and you're preparing it for use, the usage will be low so the output is not meaningful.
In this example, I change nproc from 4200 to 8020 and change idds to best. Immediately before making these changes I add a comment to /var/adm/kc.log so that a record exists of why these changes were made:
# kctune -C "first of many tunable changes for vPars/Oracle/Peoplesoft config" nproc=8020 WARNING: The automatic 'backup' configuration currently contains the configuration that was in use before the last reboot of this system. ==> Do you wish to update it to contain the current configuration before making the requested change? y * The automatic 'backup' configuration has been updated. * The requested changes have been applied to the currently running system. Tunable Value Expression Changes nproc (before) 4200 Default Immed (now) 8020 8020 # # kcmodule -C "first of many module changes for vPars/Oracle/Peoplesoft config" idds=best NOTE: The configuration being loaded contains the following change(s) that cannot be applied immediately and which will be held for the next boot: -- The configuration is supposed to include a module 'idds' which is not available without a kernel rebuild. * The automatic 'backup' configuration has been updated. * Building a new kernel for configuration 'nextboot'... * Adding version information to new kernel... * The requested changes have been saved, and will take effect at next boot. Module State Cause idds (now) unused (next boot) static explicit #
This tunable is dynamic, so the change was made immediately as you can see at the bottom of the listing with now. The kcmodule command changed idds; however, this will be applied at next boot, as shown in the following kconfig command:
# kconfig -D Module State Cause idds (now) unused (next boot) static explicit NOTE: There are no tunable changes being held until next boot. #
In both the kctune and kcmodule commands, I preceded the change with a comment (-C) that appears on the /var/adm/kc.log file.
For the module change to take place, a reboot is required. After the reboot takes place, I again issue the kcmodule command to show that the idds change has been incorporated into the new current kernel:
# kcmodule -d idds Module State Cause Description idds static explicit Intrusion Detection Data Source #
You would probably make more changes to the kernel than the two used in this example. After the changes are made, you would save the update configuration with the kconfig command:
# kconfig -C "Rev1 of vPars/Oracle/Peoplesoft kernel configuration" -s rev1_vPars_oracle_peoplesoft * The current configuration has been saved to 'rev1_vPars_oracle_peoplesoft'. # ll /stand total 96992 drwxr-xr-x 5 root sys 8192 Sep 21 09:38 Initial_vPars_Oracle_Peoplesoft drwxr-xr-x 5 root sys 8192 Sep 21 10:34 backup dr-xr-xr-x 3 bin bin 96 May 5 15:46 boot.sys -rw-r--r-- 1 root sys 21 May 5 15:44 bootconf lrwxr-xr-x 1 root root 14 Sep 21 10:51 bootfs -> current/bootfs drwxr-xr-x 5 root root 8192 May 25 12:03 crashconfig drwxr-xr-x 5 root sys 8192 Sep 21 10:34 current drwxr-xr-x 5 root sys 8192 Sep 19 15:38 initial_11iv2 drwxr-xr-x 5 root sys 8192 Sep 12 20:28 installed -rw-r--r-- 1 root sys 16024 Sep 21 10:52 ioconfig -r--r--r-- 1 root sys 82 May 5 16:11 kernrel drwxr-xr-x 2 root sys 96 Sep 21 10:56 krs drwxr-xr-x 5 root sys 8192 May 5 16:12 last_install drwxr-xr-x 2 root root 96 May 5 15:43 lost+found lrwxr-xr-x 1 root root 7 Sep 21 10:51 nextboot -> current drwxr-xr-x 5 root sys 8192 Sep 21 11:06 rev1_vPars_oracle_peoplesoft -rw------- 1 root root 12 Sep 21 10:51 rootconf lrwxr-xr-x 1 root root 15 Sep 21 10:51 system -> nextboot/system -r--r--r-- 1 root sys 1996 May 5 16:01 system.import -rw-r--r-- 1 root sys 2537 May 5 16:51 system.prev -rwxr-xr-x 3 root sys 49536344 Sep 21 10:34 vmunix #
The long listing of /stand shows the kconfig command did indeed save the current kernel configuration under the name specified, beginning with rev1. In addition, a new comment in /var/adm/kc.log identifies that this step was taken. Now both the original configuration that was saved earlier and the current configuration exist in /stand.
I don't think you can save your kernel configuration too often. I sometimes make hundreds of kernel configuration parameter changes when I prepare a new system to run a specific application, so I'm careful to save my kernel before making these many changes. The only problem with saving many kernel configurations is the space consumed in /stand. If you run out of space in /stand it can be difficult to increase it, so you must keep an eye on the available space in /stand.
You may find yourself in a situation where you have to boot a saved kernel configuration, which is covered in the next section.
Reverting to a Saved Kernel Configuration
Although the two configuration changes made in the previous section were trivial if, for any reason, you need to revert to a saved kernel configuration you can do so. The easiest way to do this is to run kconfig -n oldconfig. An alternative is to load the saved configuration at the time of boot. In the following example, I could revert back to Initial_vPars_Oracle_Peoplesoft or initial_11iv2 which were saved in /stand. To revert to this kernel configuration issue the following command at the HP-UX prompt on an Itanium system running EFI:
Please select a boot option HP-UX Primary Boot: 0/0/0/2/0.6.0 Acpi(000222F0,0)/Pci(1|0)/Mac(00306E4B9AD9) Acpi(000222F0,100)/Pci(1|0)/Mac(00306E4BAA28) EFI Shell [Built-in] Boot option maintenance menu Use ^ and v to change option(s). Use Enter to select an option Loading.: HP-UX Primary Boot: 0/0/0/2/0.6.0 Starting: HP-UX Primary Boot: 0/0/0/2/0.6.0 (c) Copyright 1990-2003, Hewlett Packard Company. All rights reserved HP-UX Boot Loader for IPF -- Revision 1.73 Press Any Key to interrupt Autoboot \EFI\HPUX\AUTO ==> boot vmunix Seconds left till autoboot - 9 Type 'help' for help HPUX> boot initial_11iv2
From EFI, I select the HP-UX Primary Boot and then interrupt the boot. At this point, I enter initial_11iv2 as the configuration to load.
On a PA-RISC system, this old configuration would have been entered at the ISL prompt with ISL> hpux config_name vmunix.
System File
Although the kernel commands covered support modifying your configuration and building a new kernel, you can still use /stand/system or the system file for any kernel configuration. There is a system file in the directory for all the kernel configurations that you've built on your system. These can be exported from one system and imported to another system in order to replicate a kernel configuration that you like onto another system. You can, for example, export a configuration with kconfig -e name on one system, import a configuration on another system with kconfig -i name, and thereby replicate a configuration on another system.
Device bindings are also managed in the system files. Device bindings are configuration settings that have to do with specific hardware devices such as primary swap (swap lines in the system file), dump devices (dump in the system file). and device driver (device in the system file) specifications.
Another common use of system files is to make multiple changes in the system file and have all the changes take effect on the next reboot.
The following is an abbreviated system file showing some of the lines in the currently running system file:
# example system file * Module entries * module prm best [3F56E2F0] module ipf loaded 0.1.0 module mpt best [40075F90] module vols best [3F41B706] . . . * Swap entries * * * Dump entries * dump lvol * * Driver binding entries * * * Tunables entries * tunable nproc 4200 tunable shmmax 68719476736 tunable semume 512 tunable semmnu 4092 tunable semmns 8192 tunable maxfiles 8192 tunable maxfiles_lim 8192 . . .
This listing shows module, swap (none present), dump, and tunable entries.
You could update numerous entries in the system file. Issue kconfig -i system_file_name and reboot this system to incorporate the changes incorporated into the running kernel, as shown in the following listing:
# kconfig -i /stand/Initial_vPars_Oracle_Peoplesoft/system WARNING: The automatic 'backup' configuration currently contains the configuration that was in use before the last reboot of this system. ==> Do you wish to update it to contain the current configuration before making the requested change? y * The automatic 'backup' configuration has been updated. NOTE: The configuration being loaded contains changes that cannot be applied immediately: NOTE: The changes will be held for next boot. * /stand/Initial_vPars_Oracle_Peoplesoft/system has been imported. The changes will take effect at next boot. [rx8620b{root}:/]>
The kconfig command updates the currently running kernel. The changes can not be applied immediately, so a reboot is required. The file /stand/current/system reflects the changes that you made to the configuration. You can also give a name to the updated configuration so that a new configuration is produced, as shown in the next example.
You can also make changes to /stand/current/system and save the configuration to a specific name, as shown the following example:
# kconfig -i test2 /stand/current/system WARNING: The system file was created from the configuration 'nextboot'. The import operation is targeted at 'test2'. ==> Do you wish to continue? y * /stand/current/system has been imported to 'test2'. #
Prior to running this kconfig command, I update /stand/current/system with numerous changes. The changes were made immediately and no reboot was required for these dynamic changes to take effect. This kconfig command imports the system file and saves it to configuration called test2. This results in a test2 directory in /stand, as shown in the following listing:
# ll /stand/test2 total 96784 -rw-r--r-- 1 root sys 0 Sep 25 11:24 .config -rw-r--r-- 1 root sys 147 Sep 25 11:24 README drwxr-xr-x 3 root sys 96 Sep 25 11:24 bootfs drwxr-xr-x 2 root sys 96 Sep 25 11:24 krs drwxr-xr-x 2 root sys 96 Sep 25 11:24 mod -rw-r--r-- 1 root sys 2902 Sep 25 11:24 system -rwxr-xr-x 5 root other 49534656 Jun 15 15:49 vmunix #
This results in a saved configuration reflecting the changes that have been made. This configuration has been saved and can be loaded anytime.
The mk_kernel -s system_file_name command can also build the new kernel. mk_kernel is fully supported and is great for those of us who have used this command in past releases of HP-UX.