Enhanced Dracut Configuration Options in Image Description

[aale24]

Overview

Hello, this ticket derives from #2801

This issue proposes exposing dracut configuration capabilities directly in the kiwi image description XML, allowing users to configure dracut options without requiring manual overlay files.

Note: This proposal aims to provide flexibility while supporting distribution limitations like inexistent modules.

We've experimented with manual dracut and are willing to implement this enhancement as a PR if there's interest.

Current State:

Dracut configuration requires manual overlay files (e.g., etc/dracut.conf.d/some.conf) to set options.

Proposed Enhancement:

Add support for the following dracut configuration options as XML elements under <bootloader><dracut>:

1. Installation of additional tools:

   <install paths="/usr/bin/veritysetup /path/to/debug_tool"/>
   

2. Kernel module configuration:

    <add_drivers names="driver1 driver2"/>
    <force_drivers names="driver3 driver4"/>
    <omit-drivers names="driver5 driver6"/>
   

3. Additional dracut modules:

   <add modules="module1 module2"/>
   <omit modules="module3 module4"/>
   <force-add modules="module5 module6"/>
   

4. Filesystem support:

   <filesystems names="ext4 xfs btrfs"/>
   

5. Compression method:

   <compress method="gzip|bzip2|lzma|xz|lzo|lz4|zstd"/>
   

6. Kernel command line options:

   <kernel_cmdline>root=UUID=xxx dm-mod.create=".." rd.debug</kernel_cmdline>
   

   Note: This option already exists as an attribute in the image type element. We need to determine the best placement for this option and how it should interact with the existing attribute.
7. Persistent policy:

   <persistent-policy value="by-uuid|by-label|mapper"/>
   

Example Configuration:

<bootloader name="systemd_boot" console="serial">
    <dracut>
       <kernel_cmdline>root=/dev/mapper/root dm-mod.create=".." rd.debug</kernel_cmdline>
        <install paths="/usr/bin/veritysetup ..."/>
        <filesystems names="erofs ext4 ..."/>
        <add_drivers names= "erofs ext4 ..." />
        <force_drivers names="erofs ext4 ..."/>
        <add modules="dm-verity ..."/>
       ...
    </dracut>
</bootloader>

Benefits:

• More explicit configuration in image description
• Improved usability by avoiding manual overlay files
• Easier maintenance and review of configurations

[schaefi]

We are discussing this on the matrix channel. Please note there is already an <initrd> section that allows to modify the inclusion of dracut modules and its scope is currently limited to the installmedia creation. We are discussing to extend the existing section with the request you made and also allow it in general not only for installmedia

[schaefi]

PR #2812 covers some parts of this. With the <initrd> section to be allowed for any oem disk type you could set the following

<type ...>
    <initrd action="add">
        <dracut module="some_a"/>
        <dracut module="some_b"/>
    </initrd>
    <initrd action="omit">
        <dracut module="some_c"/>
    </initrd>
</type>

The other call modifications you requested needs to be added one after the other into this concept

A word about the kernel cmdline. This will be handled by kiwi through

<type ... kernelcmdline="..."

The information will be extended by data that is only known during build time, e.g UUIDs and others. The information is passed along as --kernel-cmdline to dracut when building a UKI and in any other case it is passed along to the respective bootloader setup files. There is imho no need to specifiy them elsewhere. If need be they should always be taken from the kernelcmdline. A duplication of this information in another part of the description I would decline and we can also not afford incompatible changes. Thus I'm afraid the handling of kernel cmdline arguments is already set.

Thus missing components are

• install paths
• filesystems
• drivers
• persistent-policy

[aale24]

Can we reopen this issue? it is not fully fixed just partially @schaefi
Components:

• install paths
• filesystems
• drivers
• persistent-policy

[schaefi]

Can we reopen this issue?

yep sorry I think it got auto closed due to a commit message ref

[github-actions]

This issue is stale because it has been open 60 days with no activity. stale label was set.