Novell is now a part of OpenText

Creating a Driver Update Disk (DUD)

Overview

During installation of SLES 9 or SLES/SLED 10, a Driver Update Disk (DUD) can be used to install drivers for devices needed during the boot and install process. Driver Update Disks contain the drivers needed by the installation kernel as well as the drivers which will ultimately be used by the installed system.

DUDs generally contain drivers needed to access the full installation media (e.g., on CD or network). But DUDs may contain any types of kernel modules; they provide a way for any third-party modules to be installed during SLES installation (rather than after the system is running).

The SLES 9 and SLES/SLED 10 installation processes allow a user to add a driver by pressing a function key during the initial boot screen, then inserting a DUD. The SLES/SLED 10 installation process also provides users with an additional opportunity to add products (via Add-on Products) later in the installation. For more information on these SLES/SLED 10 installation options, please see the section "How to Create a Code 10 (SLES 10, SLED 10, OES 2) Driver Update Disk" below.

Definitions

The terms used to describe the install process can be confusing. In this document, the term boot kernel refers to the kernel on the installation media which is booted and then used to install the system. The term installed kernel refers to the kernel running on the final installed system.

For other definitions, please see Driver Process Terminology.

How to Create a Code 9 (SLES 9, NLD 9, OES 1) Driver Update Disk

More detailed instructions on creating a driver update disk are provided in Update Media Howto

  • Technical prerequisites:
    • Modules (*.o or *.ko files) built for the boot kernel (SLES9 first-customer-ship kernel version is 2.6.5-7.97). Modules should be built for “-default” flavor.
    • A gzipped tar file containing modules built for all supported installed kernel versions or rpms (of the driver modules) built for all supported installed kernel versions. It is recommended to use rpms.
    • Media to be used for Driver Update Disk (CD, DVD, or floppy disk).
  • In a staging directory on your local system, create the following directory structure: 
       linux/            
           suse/               
             <architecture>-<suse version>/ (e.g., "i386-sles9" or “i386-sles10)    
                 install/        
                 modules/
  • Place the following in the "modules" directory:
    • The actual driver modules (*.o or *.ko) to be loaded by the boot kernel.
  • Place the following files in the "install" directory:
    • A gzipped tar archive (update.tar.gz) which contains driver modules for different installed kernel versions and flavors or rpms (of the driver modules) built for the different installed kernel versions. It is recommended to use rpms.
    • If using rpms, make certain that they are built as detailed in Kernel Module Packages Manual for Code 9 so that you use the correct installation locations (the "updates" directory) for your driver updates.
    • If using a gzipped tar archive, the update.tar.gz file should contain:
      • Full directory structure and built modules to be installed onto the system. Make sure to include directories and modules for all kernel versions and flavors (SMP and uni-processor) expected to exist on the installed system. Also make sure to use the installation directory structure (the "updates" directory) specified by Kernel Module Packages Manual for Code 9.
      • (Optional) New device nodes or other files that should be installed onto the system.
    • (Optional) Installation shell scripts as detailed in Update Media Howto
    • (Optional) rpms for Novell Kernel-Update-Tool patch (appropriate rpms may be downloaded from http://support.novell.com/linux/psdb/). Including these rpms on the DUD ensures that the customer will have the kernel-update-tool installed and in place for any subsequent kernel updates.
  • Create the driver update disk by burning (CD/DVD) or copying (floppy disk) the contents of <staging>/ onto the chosen media.

How to Create a Code 10 (SLES 10, SLED 10, OES 2) Driver Update Disk/Add-on Product

The SLES/SLED 10 installation process provides users with two methods to add drivers during installation: 1) via a traditional DUD, and 2) via an Add-on Product. To provide installation media that addresses both methods, we recommend creating a combined "DUD/Add-on Product" as detailed below.

Technical prerequisites

  • Modules (*.o or *.ko files) built for the -default flavor of the boot kernel. Note:
    • SLE 10 initial kernel: 2.6.16.21-0.8
    • SLE 10 SP1 initial kernel: 2.6.16.46-0.12
    • SLE 10 SP2 initial kernel: 2.6.16.60-0.21
    • SLE 10 SP3 initial kernel: 2.6.16.60-0.54
  • Kernel Module Packages (KMPs) to be used with the final installed kernel.
  • Media to be used for the DUD/Add-on Product (CD, DVD, floppy disk, or space for an iso image).
  • Staging directory on your local system (e.g., /home/staging).

Making the Traditional DUD Portion

  • In your staging directory, create the following directory structure. Include <architecture>-<suse version> directories for each platform the DUD is intended to support: 
      linux/          
         suse/        
            <architecture>-<suse version>/ (e.g., “i386-sles10")      
                 install/         
                 modules/     
            <architecture>-<suse version>/ (e.g., "x86_64-sles10")               
                 install/         
                 modules/           
            <architecture>-<suse version>/ (e.g., "i386-sled10")    
                 install/        
                 modules/    
            <architecture>-<suse version>/ (e.g., "x86_64-sled10")       
                 install/   
                 modules/ 
            ...
  • Place the following files in the “modules” directories:
    • The driver modules (*.o or *.ko) to be used by the boot kernel.
  • Place the following files in the "install" directories:
    • Kernel Module Packages (KMPs) and any other RPMs to be installed onto the final system. The "install" directories should contain KMPs for all kernel flavors, and the KMPs should be built in accordance with PLDP guidelines. Note: Novell Bugzilla #220579 details a problem with how SLES10 processes the multiple rpms when installing them into the installed filesystem. A workaround is to create an update.post script as shown below: 
               #! /bin/sh       
               #     
               # update.post 
               # 
               # This script is required due to a bug in rpm in which `rpm -ihv *.rpm'   
               # won't install anything if one of the rpms fails.  `yast -i *.rpm'    
               # installs just the required kmp rpm. (gmonroy Nov 2006)    

               echo -e "`date` :\tbegin update.post" >> /tmp/DUD.log      
               pushd `dirname $0`      
               yast -i *.rpm >> /tmp/DUD.log      
               popd           
               echo -e "`date` :\tend update.post" >> /tmp/DUD.log
  • • Optional installation shell scripts as detailed in Update Media Howto
  • Actually, there is one more bug in modules/Vendor.ycp as shipped with SLES10 SP2. It prevents any RPMs from being installed. To make it work, apply this fix and put the new file into the "y2update/modules" directory. In other words, every DUD which installs an RPM must also be a Yast Update Disk. This step not needed if you apply the workaround shown above.

Making the Add-on Product Portion

  • Note 1: Detailed instructions on creating a SLES/SLED 10 Add-on product are provided in the document Creating Add-Ons.
  • Note 2: A GUI tool to create Add-on products may be obtained at Creating Add-On Media with YaST.
  • In your staging directory, create the following directory structure: 
       <staging>/ 
       media.1/  
       suse/    
          i386/   
          i486/ 
            .   
            .     
          ia64/     
            .    
          setup/    
             descr/
  • Place the RPMs for different supported architectures in the appropriate architecture directories.
  • Create a file "media" (containing at least the author name, creation date, and number of media) in the "media.1" directory. Example: 
       SUSE Linux Products GmbH  
       20060505000500 
       1
  • Create a "products" file to describe the different products and their locations on your Add-on media in the "media.1" directory. Example: 
       /                       Product 1 Name 
       product_2_directory     Product 2 Name   
       product_3_directory     Product 3 Name      
               .   
               . 
               .
  • Create directory.yast files by typing "ls -A1 -p >directory.yast" in each directory except the <staging>/suse/<arch> directories (where the RPMs are located).
  • Create MD5SUMS files by typing "md5sum * >MD5SUMS" in each <staging>/suse/<arch>/ directory.
  • Install the autoyast2-utils package.
  • From within <staging>/suse, run "create_package_descr -C" to create package description files in <staging>/suse/setup/descr/.
  • Create a <staging>/content file as detailed in Creating Add-Ons. Example: 
        PRODUCT x1000_8.0.0_SLE10_GA_driver_kit 
        VERSION 1.0  
        DISTPRODUCT test-x1000-GA   
        DISTVERSION 8.0.0 
        VENDOR Novell, Inc. 
        LABEL test-x1000 GA add-on  
        REQUIRES sles-release-10
        ARCH.i586 i586 i486 i386 noarch
        ARCH.i486 i486 i386 noarch 
        ARCH.i386 i386 noarch
        DEFAULTBASE i586 
        DESCRDIR suse/setup/descr  
        DATADIR suse    
        UPDATEURLS http://testserver.test.com/testdir 
        META SHA1 04ef39995b65f02d81d6e1cc22fffda5c3a2a40e MD5SUMS 
        META SHA1 b8b7146ce7b1e957bec2978ecaa38078db400ce5 pacakges 
        META SHA1 12ee25db081bf57beaef32b798262a18f9242216 packages.DU   
           .       
           .   
           .
Note: The "META SHA1 ..." lines list the sha1 message digests of each file in the <staging>/suse/setup/descr/ directory. To obtain these digest values, run "sha1sum <filename>" for each file.
If the add-on product is intended to replace a previous product, the content file should include an "OBSOLETES" tag. As an example, the following content file would be for a product intended to replace the "x1000_8.0.0_SLE10_GA_driver_kit" product described in the content file shown above. 
        PRODUCT x1000_8.0.0_SLE10_SP_driver_kit  
        VERSION 1.1
        DISTPRODUCT test-x1000-SP1
        DISTVERSION 8.0.0
        VENDOR Novell, Inc. 
        LABEL test-x1000 SP1 add-on 
        REQUIRES sles-release-10-sp1
        OBSOLETES product:x1000_8.0.0_SLE10_GA_driver_kit < 1.1
        ARCH.i586 i586 i486 i386 noarch
        ARCH.i486 i486 i386 noarch
        ARCH.i386 i386 noarch 
        DEFAULTBASE i586
        DESCRDIR suse/setup/descr 
        DATADIR suse 
        UPDATEURLS http://testserver.test.com/sp1_testdir
        META SHA1 04ef39995b65f02d81d6e1cc22fffda5c3a2a40e MD5SUMS  
        META SHA1 b8b7146ce7b1e957bec2978ecaa38078db400ce5 pacakges   
        META SHA1 12ee25db081bf57beaef32b798262a18f9242216 packages.DU 
           .    
           .  
           .
  • Sign the repository as detailed in How to Sign a YaST Repository. Note: If you do not sign your repository, the end-user will be asked to approve its use as an installation source.
  • Using the SLES/SLED 10 YaST "Installation Sources" utility, test your directory structure by adding your staging directory as a local installation source.

How to Create a Code 11 (SLES 11, SLED 11) Driver Update Disk/Add-on Product

The SLES/SLED 11 installation process provides users with two methods to add drivers during installation: 1) via a traditional DUD, and 2) via an Add-on Product. To provide installation media that addresses both methods, we recommend creating a combined "DUD/Add-on Product" as detailed below.

Technical prerequisites

  • Modules (*.o or *.ko files) built for the -default flavor of the boot kernel. Note:
    • SLE 11 initial kernel: 2.6.27.19-5.1
  • Kernel Module Packages (KMPs) to be used with the final installed kernel.
  • Media to be used for the DUD/Add-on Product (CD, DVD, floppy disk, or space for an iso image).
  • Staging directory on your local system (e.g., /home/staging).

Making the Traditional DUD Portion

  • In your staging directory, create the following directory structure. Include <architecture>-<suse version> directories for each platform the DUD is intended to support: 
          linux/   
             suse/   
                <architecture>-<suse version>/ (e.g., "i386-sles11")  
                     install/ 
                     modules/    
                <architecture>-<suse version>/ (e.g., "x86_64-sles11")   
                     install/     
                     modules/  
                <architecture>-<suse version>/ (e.g., "i386-sled11")  
                     install/   
                     modules/   
                <architecture>-<suse version>/ (e.g., "x86_64-sled11") 
                     install/   
                     modules/ 
                ...
  • Place the following files in the "modules" directories:
    • The driver modules (*.o or *.ko) to be used by the boot kernel.
  • Place the following files in the "install" directories:
    • Kernel Module Packages (KMPs) and any other RPMs to be installed onto the final system. The "install" directories should contain KMPs for all kernel flavors, and the KMPs should be built in accordance with PLDP guidelines. Note: Novell Bugzilla #220579 details a problem with how SLES/SLED 11 processes the multiple rpms when installing them into the installed filesystem. A workaround is to create an update.post script as shown below: 
               #! /bin/sh     
               #       
               # update.post  
               #   
               # This script is required due to a bug in rpm in which `rpm -ihv *.rpm'  
               # won't install anything if one of the rpms fails.  `yast -i *.rpm'  
               # installs just the required kmp rpm. (gmonroy Nov 2006)    

               echo -e "`date` :\tbegin update.post" >> /tmp/DUD.log  
               pushd `dirname $0`   
               yast -i *.rpm >> /tmp/DUD.log     
               popd      
               echo -e "`date` :\tend update.post" >> /tmp/DUD.log
  • • Optional installation shell scripts as detailed in Update Media Howto
  • Actually, there is one more bug in modules/Vendor.ycp. It prevents any RPMs from being installed. To make it work, apply this fix and put the new file into the "y2update/modules" directory. In other words, every DUD which installs an RPM must also be a Yast Update Disk. This step not needed if you apply the workaround shown above.

Making the Add-on Product Portion

  • Note 1: Detailed instructions on creating a SLES/SLED 11 Add-on product are provided in the document Creating Add-Ons.
  • Note 2: A GUI tool to create Add-on products may be obtained at Creating Add-On Media with YaST.
  • In your staging directory, create the following directory structure: 
       <staging>/
       media.1/  
       suse/   
          i386/  
          i486/   
            .    
            .    
          ia64/   
            .    
          setup/  
             descr/
  • Place the RPMs for different supported architectures in the appropriate architecture directories.
  • Create a file "media" (containing at least the author name, creation date, and number of media) in the "media.1" directory. Example: 
       SUSE Linux Products GmbH
       20060505000500
       1
  • Create a "products" file to describe the different products and their locations on your Add-on media in the "media.1" directory. Example: 
       /                       Product 1 Name  
       product_2_directory     Product 2 Name
       product_3_directory     Product 3 Name 
               .
               .
               .
  • Create directory.yast files by typing "ls -A1 -p >directory.yast" in each directory except the <staging>/suse/<arch> directories (where the RPMs are located).
  • Create MD5SUMS files by typing "md5sum * >MD5SUMS" in each <staging>/suse/<arch>/ directory.
  • Install the autoyast2-utils package.
  • From within <staging>/suse, run "create_package_descr -C" to create package description files in <staging>/suse/setup/descr/.
  • Create a <staging>/content file as detailed in Creating Add-Ons. Example: 
         PRODUCT x1000_8.0.0_SLE11_GA_driver_kit
         VERSION 1.0 
         DISTPRODUCT test-x1000-GA 
         DISTVERSION 8.0.0
         VENDOR Novell, Inc. 
         LABEL test-x1000 GA add-on  
         REQUIRES sles-release-11
         ARCH.i586 i586 i486 i386 noarch  
         ARCH.i486 i486 i386 noarch     
         ARCH.i386 i386 noarch 
         DEFAULTBASE i586  
         DESCRDIR suse/setup/descr
         DATADIR suse  
         UPDATEURLS http://testserver.test.com/testdir
         META SHA1 04ef39995b65f02d81d6e1cc22fffda5c3a2a40e MD5SUMS
         META SHA1 b8b7146ce7b1e957bec2978ecaa38078db400ce5 pacakges 
         META SHA1 12ee25db081bf57beaef32b798262a18f9242216 packages.DU 
            .  
            .   
            .
Note: The "META SHA1 ..." lines list the sha1 message digests of each file in the <staging>/suse/setup/descr/ directory. To obtain these digest values, run "sha1sum <filename>" for each file.
  • Sign the repository as detailed in How to Sign a YaST Repository. Note: If you do not sign your repository, the end-user will be asked to approve its use as an installation source.
  • Using the SLES/SLED 10 YaST "Installation Sources" utility, test your directory structure by adding your staging directory as a local installation source.

Creating the media

  • Create the DUD/Add-on Product by burning (CD/DVD), copying (floppy disk), or writing (iso) the contents of <staging>/ onto the chosen media.

 

© Copyright Micro Focus or one of its affiliates