———————————— PART I ————————————————

Howto update a file/s in your SLE10 or SLES 9 installation environment.

The need may someday arise when you will need to update a driver or a specific set of files contained inside the SLE installation environment. Perhaps the hardware detection module or the mkfs utils(hint hint). The following will attempt to describe how to update the “mkfs” related files contained in the installation source.

Use case: There was an issue with the e2fsprogs package (specifically mke2fs, and mkfs.ext3), whereby any ext3 filesystem (created during the install) was unable to be resized (using ext2online) while it was mounted. Obviously this is not good, if a filesystem had to be enlarged (resized) the filesystem had to first be unmounted then resized. Resizing of a mounted filesystem via ext2online was not working.

Once a fix was provided from SUSE, essentially there were two things that needed to be addressed. The first was to get the updated e2fsprogs package into the installation source so that any new servers built would have the updated mkfs files. PART II of this howto covers how this gets accomplished. But this would only affect any newly created filesystems after the the server was built, any ext3 filesystems built during the installation would have been built with the older mkfs.ext3 (contained inside the SLE installation environment – /data/install/SLE10install/boot/i386/root).

This is where PART I comes into play. There is an existing howto which goes into much greater detail, as well as describe howto to update device drivers. ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO. I strongly encourage the reader to read the Update-Media-HOWTO. I will only focus on how to replace/update files in the installation environment itself.

1. Create the following directory structure (perhaps under /tmp):
mkdir -p update-media/linux/suse/i386-sles10/inst-sys

Note: All files below the ‘inst-sys’ directory will be used to update the installation environment.
The directory structure for the appropriate file locations must be preserved.

If you want to replace the mkfs files for example, add the updated mkfs files along with the appropriate directory structure under “inst-sys”:
cd /tmp/update-media/linux/suse/i386-sles10/inst-sys
mkdir sbin
cp -ap ~/new-updated-files/mkfs* ./sbin/

Another example could be if you wish to update the hardware detection library:
cd /tmp/update-media/linux/suse/i386-sles10/inst-sys
mkdir -p usr/lib
cp -ap ~/new-updated-files/libhd.so.X.Y ./usr/lib/

2. Create a Driver Update configuration file (dud.config), under ./linux/suse/i386-sles10 :

vi dud.config, and add the following 2 lines:
UpdateName: Update /sbin/mkfs.ext3 to fix lvm online resize issue
UpdateID: mkfs_update_1

The driver update config file consists of lines with the format ‘key: value’. Valid keys are

  • UpdateName – A short description, shown in linuxrc when the driver update is applied. This key may appear more than once.
  • UpdateID – An unique string identifying the update. There’s no meaning attached to the value. It is only used to avoid applying the same update accidentally twice.

Please refer to the Howto at ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO for details.

3. Most installation sources reside on a servers harddisk and are available from the network via http, ftp, nfs or even SMB.

I am only focusing on http for this howto. Please refer to the Howto at
ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO for details on the other delivery mechanisms.

For HTTP/FTP installations you need to put a file ‘driverupdate’ into the root of your installation source.
(in my example, this is /data/install/SLE10install) This file is a (possibly compressed) filesystem image that contains the Update Media.

Use the following command to create a compressed filesystem called “driverupdate”:

mkfs.cramfs /tmp/update-media /tmp/driverupdate

You can validate that the filesystem was created correctly (with the appropriate root directory structure starting at linux) via the following command:

cd /tmp
mount ./driverupdate /mnt -o loop
cd /mnt

… you should see “linux” as the first directory
cd linux/suse/i386-sles10/inst-sys/sbin/

… you should see all the updated mkfs files here. If all is good, then unmount /mnt.

4. copy the “driverupdate” file to the root of your installation source (my example /data/install/SLE10install):

cp /tmp/driverupdate /data/install/SLE10install/

5. That’s it. Your ready now. Startup an installation, when the install starts, CRTL-ALT-F1 and if all is correct you should see a blurb on the screen with your UpdateName description from the dud.config file (step 2 above).

————————————- PART II ————————————————

Howto update your existing SLE10 installation source with new/updated RPMs

– Create Updates to installation source.

use at least version 20060418 of create_update_source.sh from the following SUSE
Homepage (http://www.suse.de/~ug). The latest autoyast2-utils RPM will contain the script as well.

1. create_update_source.sh

This script creates an “updates” tree under the SLE installation source. In the following examples the installation source is located under /data/install/SLE10install on the installation server.

Usage example:
a) Run the create_update_source.sh script to create the “updates” repository. For example:
./create_update_source.sh /data/install/SLE10install
b) copy the updated packages you wish to refresh your installation source with, for example:
cp -a myPackage- /data/install/SLE10install/updates/suse/i586

2. create_package_descr

This script updates the package database with any new packages or updated package versions
in the updates repository.

Usage example:
a) cd /data/SLE10install/updates/suse
b) create_package_descr -x setup/descr/EXTRA_PROV
c) cd setup/descr
d) ls > directory.yast

note: “create_package_descr”, as well as “create_update_source.sh” is part of the autoyast2-utils.rpm
(Starting with 10.2 and SLES10-SP1 these scripts will be part of inst-source-utils.rpm)

3. After you have created the updates tree, and copied your updated RPMS, you have two options to tell autoyast about the new install updates:

Option I – create add_on_products file

a) create a file called “add_on_products” at the root of the installation source (in our example,
that is /data/install/SLE10install )

b) The “add_on_products” file will need to have an entry similar to this (starting in
column 1 of the add_on_products file):


Option II – in the autoyast profile, add the following XML:

<add_on_products config:type="list">

You can do Option II via the autoyast UI on SLES10/SL10.1 as well.

4. Signature Handling of updated or new packages.

YaST checks the signatures of files contained in the installation source. If a package file is not signed, during a manual installation YaST asks the user what to do. However, during an autoinstallation, the installation source will get rejected silently (and the new/updated packages will not be applied) if the autoyast file does not describe how to deal with this situation.

If you use unsigned packages (could be provided as part of a hot fix, or a in-house developed package) in your installation source with autoyast, you can turn off the checks with the following configuration in your autoyast profile.

The following elements must be between the <general><signature-handling> … </signature-handling></general> tags.
Please refer to the autoyast documentation for full details on what each of these do.

<accept_unsigned_file config:type="boolean">true</accept_unsigned_file>
<accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum>
<accept_verification_failed config:type="boolean">true</accept_verification_failed>
<accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key>
<import_gpg_key config:type="boolean">true</import_gpg_key>

5. Example Installation Source directory layout.

The following shows the directory structure of /data/install/SLE10install after the
create_updates_source.sh script is run, and the add_on_products file is created):

> #:/data/install/SLE10install # tree -L 1
> .
> |-- ARCHIVES.gz
> |-- COPYING.de
> |-- COPYRIGHT.de
> |-- ChangeLog
> |-- INDEX.gz
> |-- NEWS
> |-- README
> |-- add_on_products ************** >> here is the add_on_products file
> |-- boot
> |-- content
> |-- control.xml
> |-- directory.yast
> |-- docu
> |-- dosutils
> |-- gpg-pubkey-0dfb3188-41ed929b.asc
> |-- gpg-pubkey-1d061a62-427a396f.asc
> |-- gpg-pubkey-307e3d54-44201d5d.asc
> |-- gpg-pubkey-3d25d3d9-36e12d04.asc
> |-- gpg-pubkey-9c800aca-40d8063e.asc
> |-- ls-lR.gz
> |-- media.1
> |-- pubring.gpg
> |-- suse
> |-- updates ************* >> here is the updates dir created via create_update_source.sh script
> #:/data/install/SLE10install # cat add_on_products

Note: With the add_on_products file in the installation source, you don’t need to specify the additional installation sources in the autoyast profile. You can however, mix the two options. So it’s possible to specify one installation source in the autoyast profile and another one in the “add_on_products”-file.

Miscellaneous Side Note: How to handle the licence agreement pop-up for the SLE10 SDK, or an add_on product like Suse Linux Realtime;

– remove the license.zip file in the corresponding “media.1” directory located under the “SDK” or
add_on product i.e “slert” (like Suse Linux Realtime for example) directory, and remove the line with the filename from the “directory.yast” file.