Table of Contents
{{:Design Warning}}
Background
During the installation of diskfull node or netboot of diskless node, the initrd needs to supply the drivers to drive the devices like network card, scsi card which are needed during the installation or netboot. But sometimes, the drivers of some kinds of device are not included in the default initrd for diskfull. Linux supplies an approach which can load the "driver update disk" during the diskfull installation. The driver update disk is a formatted image which including the drivers and related configuration files.
During the installation, admin can specify the kernel parameter "dd=path:/xx" or add the "driverdisk xx" entry in the kickstart/autoyast configuration file to make the installation program (anaconda/linuxrc) to load drivers from the "driver update disk" before the real installation.
The deployment of Operating System is an important function for xCAT, how to use the "driver update disk" to drive the devices during the xCAT controlled installation/netboot will be described in this mini design.
Interface
User needs to put the driver update disks into the directory "/<install>/ driverdisk/<os>/<arch>/" base on the os and arch that the driver disk can support. xCAT will look for the driver update disk from this directory during the "nodeset command". Then hack the driver update disk and put drivers into the initrd and do some proper configuration so that the driver can be loaded automatically during the installation or netboot.
Implementation
[Diskfull]
xCAT has three possible methods to load the driver update disk.
- 1. Use the kernel parameter or add kickstart/autoyast configuration entry to make the installation program anaconda/linuxrc to load the "driver update disk" from network server (httpd, nfs or ftp). By this method, xCAT does not need to touch the initrd. But this method can NOT handle the case that the network device needs driver from "driver update disk".
- 2. Insert the whole "driver update disk" image into the initrd and use the kernel parameter to notice the installation program anaconda/linuxrc to load the "driver update disk" from initrd. In this approach, the whole "driver update disk" will be put in the initrd and it will be loaded by anaconda/linuxrc. An issue for redhat is that the kernel parameter only can specify one "driver update disk", if there are multiple "driver update disks" need to be loaded during the installation, xCAT has to merge multiple "driver update disk" into one and put it into the initrd.
- 3. Extract the drivers out from "driver update disk" and put it into the proper place of initrd, then the drivers will be loaded directly by installation program during the installation initialization.
Method 1 can NOT handle the network driver, so it is NOT considered.
Method 2 is good, but it has two problems: 1. xCAT still needs to hack the "driver update disk"; 2. For the redhat, the"driver update disk" can NOT handle the case that the initrd has the driver same with the driver in the "driver update disk". That means if the initrd has an old driver, then the old driver will be loaded first and the new driver in the "driver update disk" will not be used. Since the "driver update disk" is loaded later than the pci probe in which time the old driver has been loaded, and the new driver in the "driver update disk" will not replace the old one.
Method 3 is a little complex, but it can handle all the cases.
Base on these three methods, the redhat will merge all the drivers form driver disk to the initrd; the sles will insert the driver disk into the initrd and use the kernel parameter to load the driver disk.
The implementation steps:
[Rhel <install>/ driverdisk/<os>/<arch>/"
- 2. Extract the content of initrd image to a directory. The kernel modules information are located in the /modules directory. The drivers are located in /modules/modules.cgz.
- 3. For each "driver update disk", extract all the valid drivers (*.ko) (valid means match the kernel version and arch) out and inserts them into the driver modules located in the initrd. (The modules directory is /modules) This step will replace old driver with the new one.
- 4. For each "driver update disk", merge the configuration files into the driver modules configuration files in the initrd. The old driver information will be removed from configuration files. (The configuration files include modinfo, modules.alias, modules.dep, pcitable)
- 5. Repack the initrd image.
[Rhel >= 6.0] (The ppc and x86 have the same process)
- 1. Get the "driver update disk" list from the directory: "/<install>/ driverdisk/<os>/<arch>/"
- 2. Extract the content of initrd image to a directory. The kernel modules are located in the /lib/modules/<kernel>/.
- 3. For each "driver update disk", extract all the valid drivers (*.ko) (valid means match the kernel version and arch) out and copy them to the initrd:/lib/modules/<kernel>/. If certain kernel modules existed, then over write, otherwise copy it to the initrd:/lib/modules/<kernel>/kernel/drivers/driverdisk/
- 4. Run the depmod to regenerate the modules.dep for the initrd
- 5. Repack the initrd.
[Sles - ppc]
- 1. Get the "driver update disk" list from the directory: "/<install>/ driverdisk/<os>/<arch>/"
- 2. Copy the initrd from iso: /suseboot/initrd64, extract the content of initrd image to a directory.
- 3. Make directory initrd:/driverdisk; copy all the driver update disk to the initrd:/driverdisk.
- 4. Get the kernel from iso: /suseboot/linux64.gz
- 5. Use the /lib/lilo/scripts/make_zimage_chrp.sh to repack the initrd and kernel to a inst64 file.
- 6. Add the kernel parameter dud=file:/cus_driverdisk/ for each driver disk.
[Sles - x86]
- 1. Get the "driver update disk" list from the directory: "/<install>/ driverdisk/<os>/<arch>/"
- 2. Extract the content of initrd image to a directory.
- 3. Make directory initrd:/driverdisk; copy all the driver update disk to the initrd:/driverdisk.
- 4. Repack the initrd.
- 5. Add the kernel parameter dud=file:/cus_driverdisk/ for each driver disk.
[Diskless]
For diskless netboot, there is no installation programs anaconda or linuxrc can help to load the "driver update disk" during the netboot process. xCAT has to extract the drivers out from "driver update disk" and insert them into the initrd. The initrd of diskless has different format with the diskfull one.
The implementation steps:
[Rhel]
- 1. Get the "driver update disk" list from the directory: "/install/ driverdisk/<os>/<arch>/"
- 2. For each "driver update disk", extract all the valid drivers (*.ko) (valid means match the kernel version and arch) out and copy them to the rootimage:/lib/modules/<kernel>/. If certain kernel modules existed, then over write, otherwise copy it to the rootimage:/lib/modules/<kernel>/kernel/drivers/driverdisk/
- 3. Run the depmod to regenerate the modules.dep for the rootimage.
- 4. Add the name of drivers from driver disk into the network driver list, so that the original code logic can add them into the initrd. (It works for Rhel 5.x and 6.x)
[Sles]
- 1. Get the "driver update disk" list from the directory: "/install/ driverdisk/<os>/<arch>/"
- 2. For each "driver update disk", extract all the valid drivers (*.ko) (valid means match the kernel version and arch) out and copy them to the rootimage:/lib/modules/<kernel>/. If certain kernel modules existed, then over write, otherwise copy it to the rootimage:/lib/modules/<kernel>/kernel/drivers/driverdisk/
- 3. Figure out the driver loading order by the name of the first level directory in the driver disk. If there is module.order file, use the driver loading order in the module.order.
- 4. Run the depmod to regenerate the modules.dep for the rootimage.
- 5. Add the name of drivers from driver disk into the network driver list, so that the original code logic can add them into the initrd.
The driver installation for diskfull node
For the Redhat, after the installation, the drivers in the "driver update disk" will not be installed in the new installed system.
For the sles, if the driver update disk has the kmod rpm packages, the kmod will be installed into the new installed system.
If user wants to install a driver for a new installed system, the otherpkgs.pkglist can be used to install the kernel module rpm packages during the installation.
News
- Apr 22, 2016: xCAT 2.11.1 released.
- Mar 11, 2016: xCAT 2.9.3 (AIX only) released.
- Dec 11, 2015: xCAT 2.11 released.
- Nov 11, 2015: xCAT 2.9.2 (AIX only) released.
- Jul 30, 2015: xCAT 2.10 released.
- Jul 30, 2015: xCAT migrates from sourceforge to github
- Jun 26, 2015: xCAT 2.7.9 released.
- Mar 20, 2015: xCAT 2.9.1 released.
- Dec 12, 2014: xCAT 2.9 released.
- Sep 5, 2014: xCAT 2.8.5 released.
- May 23, 2014: xCAT 2.8.4 released.
- Jan 24, 2014: xCAT 2.7.8 released.
- Nov 15, 2013: xCAT 2.8.3 released.
- Jun 26, 2013: xCAT 2.8.2 released.
- May 17, 2013: xCAT 2.7.7 released.
- May 10, 2013: xCAT 2.8.1 released.
- Feb 28, 2013: xCAT 2.8 released.
- Nov 30, 2012: xCAT 2.7.6 released.
- Oct 29, 2012: xCAT 2.7.5 released.
- Aug 27, 2012: xCAT 2.7.4 released.
- Jun 22, 2012: xCAT 2.7.3 released.
- May 25, 2012: xCAT 2.7.2 released.
- Apr 20, 2012: xCAT 2.7.1 released.
- Mar 19, 2012: xCAT 2.7 released.
- Mar 15, 2012: xCAT 2.6.11 released.
- Jan 23, 2012: xCAT 2.6.10 released.
- Nov 15, 2011: xCAT 2.6.9 released.
- Sep 30, 2011: xCAT 2.6.8 released.
- Aug 26, 2011: xCAT 2.6.6 released.
- May 20, 2011: xCAT 2.6 released.
- Feb 14, 2011: Watson plays on Jeopardy and is managed by xCAT!
- xCAT Release Notes Summary
- xCAT OS And Hw Support Matrix
- xCAT Test Environment Summary
History
- Oct 22, 2010: xCAT 2.5 released.
- Apr 30, 2010: xCAT 2.4 is released.
- Oct 31, 2009: xCAT 2.3 released.
xCAT's 10 year anniversary! - Apr 16, 2009: xCAT 2.2 released.
- Oct 31, 2008: xCAT 2.1 released.
- Sep 12, 2008: Support for xCAT 2
can now be purchased! - June 9, 2008: xCAT breaths life into
(at the time) the fastest
supercomputer on the planet - May 30, 2008: xCAT 2.0 for Linux
officially released! - Oct 31, 2007: IBM open sources
xCAT 2.0 to allow collaboration
among all of the xCAT users. - Oct 31, 1999: xCAT 1.0 is born!
xCAT started out as a project in
IBM developed by Egan Ford. It
was quickly adopted by customers
and IBM manufacturing sites to
rapidly deploy clusters.