137 lines
4.9 KiB
ReStructuredText
137 lines
4.9 KiB
ReStructuredText
|
Brief description of DriverDisc version 3
|
||
|
|
==========================================
|
||
|
|
|
||
|
|
For a new major release we decided to introduce a new version of DriverDisc
|
||
|
|
feature to ensure the smoothest vendor and user experience possible. We had
|
||
|
|
many reasons for it:
|
||
|
|
|
||
|
|
- the old DD didn't support multiple architectures
|
||
|
|
- the old DD wasn't particulary easy to create
|
||
|
|
- the old DD had two copys of modules, one for anaconda and one for
|
||
|
|
instalation
|
||
|
|
- the modules in old DD weren't checked for kernel version
|
||
|
|
|
||
|
|
We also changed the feature internal code to enable some functionality that
|
||
|
|
was missing from the old version. More about it below.
|
||
|
|
|
||
|
|
|
||
|
|
Devices which can contain DDs
|
||
|
|
-----------------------------
|
||
|
|
|
||
|
|
The best place to save your DriverDisc to is USB flash device. We also support
|
||
|
|
IDE and SATA block devices with or without partitions, DriverDisc
|
||
|
|
image stored on block device, initrd overlay (see documentation below) and for
|
||
|
|
special cases even network retrieval of DriverDisc image.
|
||
|
|
|
||
|
|
|
||
|
|
What can be updated using DDs?
|
||
|
|
------------------------------
|
||
|
|
|
||
|
|
All drivers for block devices, which weren't used for retrieving DriverDiscs,
|
||
|
|
the same applies also for network drivers eg. you cannot upgrade network
|
||
|
|
driver for device, which was used prior the DriverDisc extraction.
|
||
|
|
|
||
|
|
RPMs for installation. If the DriverDisc repo contains newer package, than the
|
||
|
|
official repository, the newer package will get used.
|
||
|
|
|
||
|
|
We also plan to support anaconda's updates.img placement on the DriverDisc to
|
||
|
|
update stage2 behaviour of anaconda.
|
||
|
|
|
||
|
|
|
||
|
|
Selecting DD manually
|
||
|
|
---------------------
|
||
|
|
|
||
|
|
Use the 'inst.dd' kernel command line option to trigger DD mode.
|
||
|
|
If no argument is specified, the UI will prompt for the location of the driver
|
||
|
|
rpm. Otherwise, the rpm will be fetched from the specified location.
|
||
|
|
|
||
|
|
Please consult the appropriate Installer Guide for further information.
|
||
|
|
|
||
|
|
|
||
|
|
Automatic DriverDisc detection
|
||
|
|
------------------------------
|
||
|
|
|
||
|
|
Anaconda automatically looks for driverdiscs during startup.
|
||
|
|
|
||
|
|
The DriverDisc has to be on partition or filesystem which has been labeled
|
||
|
|
with 'OEMDRV' label.
|
||
|
|
|
||
|
|
Because disks can take some time to appear, an additional delay of 5 seconds
|
||
|
|
has been added. This can be overridden by boot argument
|
||
|
|
`inst.wait_for_disks=<value>` to let dracut wait up to <value> additional
|
||
|
|
seconds (0 turns the feature off, causing dracut to only wait up to 500ms).
|
||
|
|
Alternatively, if the `OEMDRV` device is known to be present but too slow to be
|
||
|
|
autodetected, the user can boot with an argument like `inst.dd=hd:LABEL=OEMDRV`
|
||
|
|
to indicate that dracut should expect an `OEMDRV` device and not start the
|
||
|
|
installer until it appears.
|
||
|
|
|
||
|
|
|
||
|
|
DDv3 structure
|
||
|
|
--------------
|
||
|
|
|
||
|
|
The new DriverDisc format uses simple layout which can be created on top of
|
||
|
|
any anaconda's supported filesystem (vfat, squashfs, ext2 and ext3).
|
||
|
|
|
||
|
|
::
|
||
|
|
|
||
|
|
/
|
||
|
|
|rhdd3 - DD marker, contains the DD's description string
|
||
|
|
/rpms
|
||
|
|
| /i386 - contains RPMs for this arch and acts as package repo
|
||
|
|
| /i586
|
||
|
|
| /x86_64
|
||
|
|
| /ppc
|
||
|
|
| /... - any other architecture the DD provides drivers for
|
||
|
|
|
||
|
|
There is a special requirement for the RPMs used to update drivers. Anaconda
|
||
|
|
picks up only RPMs which provide "kernel-modules = <running kernel version>".
|
||
|
|
|
||
|
|
|
||
|
|
Initrd overlay driverdisc image
|
||
|
|
-------------------------------
|
||
|
|
|
||
|
|
We have designed another possible way of providing updates in network boot
|
||
|
|
environments. It is possible to update all modules this way, so if special
|
||
|
|
storage module (which gets used early) needs to be updated, this is the
|
||
|
|
preffered way.
|
||
|
|
|
||
|
|
This kind of driverdisc image is applied over the standard initrd and so has
|
||
|
|
to respect some rules.
|
||
|
|
|
||
|
|
- All updated modules belong to /lib/modules/<kernel version>/.. according to
|
||
|
|
their usual location
|
||
|
|
- All new modules belong to /lib/modules/<kernel version>/updates
|
||
|
|
- All new firmware files belong to /lib/firmware
|
||
|
|
- The rpm repo with updated packages belongs to /tmp/DD-initrd/
|
||
|
|
- The (empty) trigger file /.rundepmod must be present
|
||
|
|
|
||
|
|
|
||
|
|
Firmware and module update
|
||
|
|
--------------------------
|
||
|
|
|
||
|
|
The firmware files together with all .ko, .ko.bz2, .ko.gz, .ko.xz and .ko.zst
|
||
|
|
files from the RPMs are exploded to special module location, which has
|
||
|
|
preference over built-in Anaconda modules.
|
||
|
|
|
||
|
|
Anaconda doesn't use built-in modules (except some storage modules needed for
|
||
|
|
the DD to function properly) during the DriverDisc mode, so even in case when
|
||
|
|
you are updating some modules with second (or later) DriverDisc, the updated
|
||
|
|
modules will be loaded. There is one exception though, if your module depends
|
||
|
|
on a module which is only present in built-in module directory, that built-in
|
||
|
|
module gets also loaded.
|
||
|
|
|
||
|
|
|
||
|
|
Package installation
|
||
|
|
--------------------
|
||
|
|
|
||
|
|
It is also possible to include arbitrary packages on the DriverDisc media and
|
||
|
|
mark them for installation. You just have to include the package name in the
|
||
|
|
package repo for correct architecture and mark it as mandatory.
|
||
|
|
|
||
|
|
|
||
|
|
Summary
|
||
|
|
-------
|
||
|
|
|
||
|
|
This new DriverDisc format should simplify the DD creation and usage a lot. We
|
||
|
|
will gladly hear any comments as this is partially still work in progress.
|