NAME¶

mkdud - create and manage SUSE Linux driver updates

SYNOPSIS¶

mkdud [OPTIONS]... SOURCES...

DESCRIPTION¶

mkdud manages driver updates (DUD) for SUSE Linux. You can create them, view their contents, and combine several driver updates into a single one.

CONFIGURATION FILE¶

mkdud reads $HOME/.mkdudrc at startup. There’s only one possible entry:

sign-key=KEY_FILE

sign-key-id=KEY_ID

DRIVER UPDATE SOURCES¶

To create a driver update you need SOURCES. SOURCES may be:

ADDING RPMS¶

If you add RPMs to SOURCES, these RPMs can be used to update the installation system and/or to be installed in the target system. See --install option on how to choose.

The best way is to go for repo to install them in the target system as then they are handled by the package manager and package dependencies are automatically resolved.

But there are two catches:

DISTRIBUTION (PRODUCT) NAMES:¶

The --dist option accepts these values (case-insensitive; X, Y: decimal numbers):

As a shorthand and to avoid common mistakes, these aliases do also work (X, Y: decimal numbers):

Note 1: there aren’t any products anymore that actually use sledX, even SLED uses the sles DUDs meanwhile. Because of this, please just use sleX when creating a DUD for a SUSE Linux Enterprise product.

Note 2: CaaSP releases are based on SLE releases. Since driver updates are usually released for a specific SLE version mkdud provides a mapping CaaSP release <→ SLE release when building with --dist=caspX.Y. Currently:

Kubic is based on Tumbleweed. For compatibility, --dist=kubic... variants are still supported but will be mapped to Tumbleweed. Please use --dist=tw directly.

openSUSE MicroOS (not to be confused with SUSE Linux Enterprise Micro) is based on Tumbleweed. Use --dist=tw.

Driver updates built for SLE 12 will implicitly also work with CaaSP3.0; those built for SLE 15 will implicitly also work with CaaSP4.0. But this is not true for CaaSP1.0 and CaaSP2.0.

Normally, a DUD will apply to the main release as well as to all the service packs. To target a specific service pack, use the --condition option. For example, to get a DUD exclusively for sle15-sp1: --dist=sle15 --condition=ServicePack1

This works also to target a specifc Tumbleweed release: --dist=tw --condition=20191231.

You can specify several --condition options. They must all be fulfilled (logical and).

AGAMA VS. YAST¶

Starting with SLE 16 and Leap 16.0, the installer changes from YaST to Agama. With this, the installation system setup changes substantially and there are a few differences in driver update handling.

With Agama:

ADDING DRACUT HOOKS¶

You can add dracut hooks using the --dracut-hook HOOK:CMD option. This can either be a provided custom script or a command to run - which is implicitly inserted into a suitable script.

Let’s see some excamples:

mkdud --create foobar.dud --dist sle16 \
--dracut-hook pre-pivot:90-foobar.sh 90-foobar.sh

mkdud --create foobar.dud --dist sle16 \
--dracut-hook "pre-pivot:echo hello"

Hook names can be (or use --no-check-hooks to allow arbitrary names):

See dracut.modules(7) for documentation.

CONSISTENCY CHECKS¶

It is possible to create driver updates that will predictably not work because they interfere with the setup of the installation environment.

mkdud will warn you and try to work around these cases. But there still may be valid use-cases so the --fix-XXX / --no-fix-XXX group of options lets you enable (default) or disable these workarounds.

HOW TO APPLY DRIVER UPDATES¶

There are several ways to apply driver updates:

The difference between --apply-dud and --initrd is that --apply-dud applies the driver update directly to the installation medium while --initrd only adds the driver update to the initrd where it will be found and applied at installation time (equivalent to using the inst.dud or dud boot options).

Only with --apply-dud you can apply changes to the initrd, boot options, or the installation ISO.

mkdud --show DUD_FILE tells you which ways are available for a specific driver update.

Using mkdud --format=iso ... produces an ISO9660 file system with label OEMDRV - ready to be used in the OEMDRV method described above (no unpacking needed).

Note: If you have package updates for the live root file system (using --install=instsys) the updated packages are added to the installation system / live root - but rpm scripts are not run and the live root rpm database is not updated.

Hint: If it simplifies your workflow, combine several driver updates into a single update; e.g.:
mkdud --create foo_all.dud foo1.dud foo2.dud foo3.dud ...

EXAMPLES¶

# show content of foo.dud
mkdud --show foo.dud
# create update for hello.rpm
mkdud --create foo.dud --dist leap15.1 hello.rpm
# create kernel update
mkdud --create foo.dud --dist leap15.1 kernel-*.rpm
# create kernel update and replace tg3 module
mkdud --create foo.dud --dist leap15.1 kernel-*.rpm tg3.ko
# create kernel update, replace tg3 module, add some docs
# and give the driver update a nice name
mkdud --create foo.dud --dist leap15.1 --name 'for granny' kernel-*.rpm tg3.ko README
# update some YaST stuff
mkdud --create foo.dud --dist leap15.1 BootCommon.y*
# add directory tree below newstuff/ to installation system
mkdud --create foo.dud --dist leap15.1 newstuff
# extract driver updates from ISO (you need root permissions for that)
mkdud --create foo.dud xxx.iso
# create update for hello.rpm and join with foo1.dud and foo2.dud
mkdud --create foo.dud --dist sle15 foo1.dud foo2.dud hello.rpm

Find more usage examples here: <https://github.com/openSUSE/mkdud/blob/master/HOWTO.md>.

SEE ALSO¶

mkmedia(1), dracut.modules(7), dracut.cmdline(7).

LINKS¶