feat(systemd): pull 'drm' module unless excluded by pvalena · Pull Request #1982 · dracut-ng/dracut

pvalena · 2025-12-22T21:30:20Z

This is a clone of PR dracutdevs/dracut#2719 by @rmetrich

Changes

Some graphic cards require the 'drm' module to be present to be able to setup the console font (e.g. 'i915' requires it).

Checklist

I have tested it locally
I have reviewed and updated any documentation if relevant
I am providing new code and test(s) for it

Manual testing only on a QEMU/KVM
Remove plymouth package from the system
Set the console font
# grep FONT /etc/vconsole.conf
FONT="latarcyrheb-sun32"
Rebuild the initramfs and verify there is no "drm" module (original state, without this patch)
# dracut -f
# lsinitrd --mod | grep drm
--> nothing
Reboot and add rd.break to drop to emergency

At emergency prompt, confirm the font was not applied (the font is very pixelized)

Apply the patch
Rebuild the initramfs and verify there is "drm" module
# dracut -f
# lsinitrd --mod | grep drm
drm
Reboot and add rd.break to drop to emergency

At emergency prompt, confirm the font was applied (the font is very pixelized)

LaszloGombos · 2026-01-06T00:45:42Z

This PR seem to cause regression for ubuntu:devel.

If dracut introducea a dependency on the drm module, is the systemd dracut module the best place to do so ? Why not plymouth or perhaps i18n module ?

Also how does this relates to the work on the simpledrm dracut module ? What if user adds simpledrm dracut module to the configuration ?

pvalena · 2026-01-06T14:56:37Z

Sure, makes sense, as console fonts are set/loaded via i18n, lets move it there. I will refresh this PR. The failures / timeouts for ubuntu:devel seem to be however somewhat unrelated :) (or in the very least it's strange that this change would introduce a breakage, as drm is just loading some kernel modules).

pvalena · 2026-01-07T15:25:29Z

@LaszloGombos @Conan-Kudo PTAL.

bdrung · 2026-01-07T16:46:50Z

Same question as Laszlo: How does this relates to the work on the simpledrm dracut module?

jozzsi · 2026-01-07T16:47:40Z

Same question as Laszlo: How does this relates to the work on the simpledrm dracut module?

@pvalena please see https://github.com/dracut-ng/dracut-ng/blob/main/modules.d/45plymouth/module-setup.sh#L48 for reference

pvalena · 2026-01-08T17:18:46Z

I don't think it's related -- they're simply different drivers. I do not know if/how they interoperate, but I'd suppose DRM takes precedence over SimpleDRM, since it utilizes the accelerated rendering (and simpledrm is just a kernel fallback). I don't have any HW currently to test it, however.

Maybe @rmetrich will know?

WRT the plymouth question, this configuration assumes plymouth is not available on the system, so I'd say we can't know. And since it's only for better font support, I don't think it matters.

We can however have a conditional (inverse) depends based on whether simpledrm module is added.

jozzsi · 2026-01-08T17:23:47Z

# Module dependency requirements.                                                                                                                                                                                                     
depends() {                                                                                                                                                                                                                           
    local deps                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                                                                                                                                                                                                  
    # install optional dependencies unless they are omitted                                                                                                                                                                           
    for module in simpledrm drm; do                                                                                                                                                                             
        module_check $module > /dev/null 2>&1                                                                                                                                                                                         
        if [[ $? == 255 ]] && ! [[ " $omit_dracutmodules " == *\ $module\ * ]]; then                                                                                                                                                  
            deps+=" $module"
            break                                                                                                                                                                                                          
        fi                                                                                                                                                                                                                            
    done                                                                                                                                                                                                                              
                                                                                                                                                                                                                                      
    echo "$deps"                                                                                                                                                                                                                      
    return 0                                                                                                                                                                                                                          
}

This is an established patter - see e.g. https://github.com/dracut-ng/dracut-ng/blob/main/modules.d/11systemd-udevd/module-setup.sh#L27

jozzsi · 2026-01-08T17:26:17Z

I'd suppose DRM takes precedence over SimpleDRM, since it utilizes the accelerated rendering (and simpledrm is just a kernel fallback

Is this true even if you end up later loading e.g. NVIDIA drivers ?

jozzsi · 2026-01-08T17:27:15Z

Title of the commit message needs to be fixed

feat(systemd): pull 'drm' module unless excluded

pvalena · 2026-01-08T17:45:53Z

    for module in simpledrm drm; do                                                                                                                                                                             
        module_check $module > /dev/null 2>&1

This is an established patter - see e.g. https://github.com/dracut-ng/dracut-ng/blob/main/modules.d/11systemd-udevd/module-setup.sh#L27

I think that's however a different logic.

We probably want dracut_module_included instead of module_check. I'll push the proposed changes tomorrow.

EDIT: In addition we could use this logic as well, although I don't know whether simpledrm does support the font rendering, which is what we want (we'd need to test).

More importantly, IIUC, the plymouths depends() needs to run earlier than the i18n one -- or, alternatively, we run conditionally only when plymouth is not included (module_check).

pvalena · 2026-01-27T01:58:39Z

@jozzsi @bdrung PTAL.

jozzsi · 2026-01-27T02:53:09Z

Plymouth module might pull in simpledrm module, and at the same time this module might pull in the drm module - so both simpledrm and drm is pulled in since i18n is order earlier (20) than plymouth (45). This issue is only impacting distro's that would be pulling in simpledrm as part of plymouth - which is why perhaps it did not impacted Fedora. Please double check, and if this is the case than module ordering also need to change.

I am wondering if this is why test 70,71 is failing on ubuntu:devel.

pvalena · 2026-01-27T03:27:34Z

Plymouth module might pull in simpledrm module, and at the same time this module might pull in the drm module - so both simpledrm and drm is pulled in since i18n is order earlier (20) than plymouth (45). This issue is only impacting distro's that would be pulling in simpledrm as part of plymouth - which is why perhaps it did not impacted Fedora. Please double check, and if this is the case than module ordering also need to change.

You're right, I was unsure how else to resolve it, and didn't want to introduce several changes at once. Would it then make sense to load plymouth module earlier?

jozzsi · 2026-01-27T03:47:47Z

You're right, I was unsure how else to resolve it, and didn't want to introduce several changes at once. Would it then make sense to load plymouth module earlier?

Since I am just guessing, best to comfirm the issue before trying to solve it. If it is indeed the issue, than I would order i18n after plymouth - maybe like 46i18n ?

pvalena · 2026-01-28T07:30:24Z

@LaszloGombos PTAL.

bdrung · 2026-01-28T13:49:56Z

+    for _module in "${_modules[@]}"; do
+        if dracut_module_included "$_module"; then
+            _drm="$_module"
+            break
+        fi
+    done
+
+    if [[ -z $_drm ]]; then
+        for _module in "${_modules[@]}"; do
+            module_check "$_module" > /dev/null 2>&1
+            if [[ $? == 255 ]] && ! [[ " $omit_dracutmodules " == *\ $_module\ * ]]; then
+                _drm="$_module"
+                break
+            fi
+        done
+    fi


The whole logic looks identical to other modules like 40network. Maybe we should add a helper function to dracut-functions.sh for that.

Can we do refactoring in other PR?

jozzsi · 2026-01-28T16:05:09Z

drm, as I'm not even sure simpledrm has this required functionality (can someone test?).

First hit when I do a search for "simpledrm" and "Fedora"

https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm

I would think Fedora should care about simpledrm just as much as any other major distro.

This avoids the textmode fallback if the GPU driver takes a long time to initialize.
This shows the splash earlier instead of letting the user look at a static screen

Similar sentiment as I pointed out at #1982 (comment)

CC @jwrdegoede

pvalena · 2026-02-05T10:58:37Z

drm, as I'm not even sure simpledrm has this required functionality (can someone test?).

First hit when I do a search for "simpledrm" and "Fedora"

https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm

I would think Fedora should care about simpledrm just as much as any other major distro.

It's not that I wouldn't know what it is, but rather whether it actually uses the fonts -- without plymouth (situation this PR is trying to address). But I can simply assume they do as well :).

This avoids the textmode fallback if the GPU driver takes a long time to initialize.
This shows the splash earlier instead of letting the user look at a static screen

Similar sentiment as I pointed out at #1982 (comment)

ditto; this PR is not about plymouth

Some graphic cards require the 'drm' module to be present to be able to setup the console font (e.g. 'i915' requires it). Also avoid conflicts of 'drm' with 'simpledrm' module. Signed-off-by: Renaud Métrich <rmetrich@redhat.com> Co-authored-by: Renaud Métrich <rmetrich@redhat.com>

i18n module loads different drm module based on what is already loaded, but plymouth module decides which drm to load based on config files - therefore plymouth needs to load before i18n.

pvalena · 2026-02-05T16:11:43Z

pushed the comment wrt ordering & rebased (no other change)

jwrdegoede · 2026-02-08T09:04:00Z

A couple of remarks here:

IMHO we should try to move to never having the drm modules in the initrd not do so more often: https://hansdegoede.dreamwidth.org/28291.html
I think the font-setting problem here needs to be root-caused a lot better before accepting this PR. All drm/kms drivers use fbcon to do the text rendering. So there is no reason why font-setting should not work with simpledrm.

I can see a couple of reasons why font-setting would not work without the i915 driver loaded:

This is on BIOS booting systems which lack a firmware-framebuffer (efifb), so no simpledrm and before the i915 driver loads the good old vga-console is used instead of fbcon

I expect this to be the most likely root-cause. The upstream kernel has recently grown support for running simpledrm over vesa for this setup and IMHO the correct fix would be to move towards using that, which means running the latest kernel with the right Kconfig. If someone wants to look into enabling this for their distro I suggest reaching out to Thomas Zimmermann tzimmermann@suse.de who did all the kernel work for this. I believe this is likely all in place in 6.18.

deferred-fbcon-takeover is in play and the delay caused by loading i915 allows some message to get printed and fbcon to takeover: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83d83bebf40132e2d55ec58af666713cc76f9764
Before fbcon takeover the dummy console driver is used which I presume does not support font-loading and even if it does, any loaded font will likely be forgotten when fbcon takes over as the console driver.

Note deferred-fbcon-takeover takes over the console from dummycon as soon as the first character is printed to the console. So unless you're booting with "quiet" and your userspace is also fully quiet before the i18n module does the console setup this will not be the problem.

jwrdegoede · 2026-02-08T09:11:01Z

One more possible root-cause, already mentioned above

The i18n code in the initrd sets the fbcon font using vgacon before the drm driver loads and then on the switch to fbcon this is lost, since different console drivers do not share the font.

Rereading the original PR description. I'm even more confused about the root-cause there. The drm module itself is mostly a "library" module, that is it provides functionality to other drivers. Is the i915 drm/kms driver already in the initrd and is the drm module somehow not being brought in, that would be a bug in dracut's kernel-module dependency resolution.

This feels to me that like instead of a PR, this needs a proper bug report with logs (e.g. dmesg output) of both the working and non-working cases. Also it would be good to try and manually set the font from the cmdline in the non-working case to rule out a race/timing issue as the root cause.

Then once we understand what the problem is we can start looking into fixing this.

pvalena · 2026-02-09T16:22:01Z

A couple of remarks here:

IMHO we should try to move to never having the drm modules in the initrd not do so more often: https://hansdegoede.dreamwidth.org/28291.html

I think the font-setting problem here needs to be root-caused a lot better before accepting this PR. All drm/kms drivers use fbcon to do the text rendering. So there is no reason why font-setting should not work with simpledrm.

Great! Thanks for the confirmation it works as expected. Like I said in my earlier comment, the order doesn't really matter, so it can be reversed if that is benefitial.
To clarify, there's no problem, just that there's just no drm at all:) in initrd; no drm or simpledrm, as it didn't get pulled in (plymouth is not installed).

I can see a couple of reasons why font-setting would not work without the i915 driver loaded:

I don't understand how this is relevant -- i915 is nowhere mentioned? (i18n is something completely different)

(Skipping the rest for now, as I need this answered first.)

jwrdegoede · 2026-02-09T21:11:22Z

On 9-Feb-26 18:50, Pavel Valena wrote: I don't understand how this is relevant -- i915 is nowhere mentioned? (i18n is something completely different) (Skipping the rest for now, as I need this answered first.)

Just having the drm module in the initrd by itself should not do anything. As mentioned in my previous comments the drm module is mostly a library module providing helper functions for drm drivers. So you also need an actual drm driver (e.g. i915 or simpledrm) in the initrd for the mere act of just adding the drm module to the initrd to make a difference.

jwrdegoede · 2026-02-09T21:14:36Z

Let me rephrase things a bit. If you run lsinitrd on the generated initrd both before and after the suggested changes like this:

lsinitrd > lsinitrd.before
lsinitrd > lsinitrd.after
diff -u lsinitrd.before lsinitrd.after

What changes does the diff command show, or in other words which extra files get added to the initrd?

In your original description you sorta claim that only the drm module gets added. But I think that is only because of your filtering of the lsinitrd output. I presume that a whole bunch of other drm modules are also getting added ?

pvalena · 2026-02-09T23:08:40Z

Diff: https://gist.github.com/pvalena/5ae5dca31b5410d89a377febfc612937

Note: It's run on my VM which is a clone of my previous fedora-rawhide laptop (workstation) installation :).

(Sorry for sending it multiple times, there was a github outage, and it just timed out for me every time -- but it did get to some queue...)

pvalena · 2026-02-09T23:16:03Z

In your original description you sorta claim that only the drm module gets added. But I think that is only because of your filtering of the lsinitrd output. I presume that a whole bunch of other drm modules are also getting added ?

Firstly, I'm sorry, but the description was copied from the original 1-line PR. I have made some changes since, but the idea is the same; added dependency in between dracut modules.

Also, I'm not aware that it actually says it adds only the drm module exclusively, but, more importantly: here module = dracut module; which also pulls dependencies (modules, binaries, and various files it might as well; recursively; if needed).

jozzsi · 2026-02-10T01:47:05Z

here module = dracut module; which also pulls dependencies (modules, binaries, and various files it might as well; recursively; if needed).

I do not think the drm dracut module pulls in any (non-kernel) binary. This is also what seems to be in your logs - only additional kernel modules. Also it does not seem to pull in any other dracut module.

jozzsi · 2026-02-10T03:04:29Z

I don't understand how this is relevant -- i915 is nowhere mentioned? (i18n is something completely different)

From the git commit message of this PR:

Some graphic cards require the 'drm' module to be present to be able to setup the console font (e.g. 'i915' requires it).

If 'i915' requires it, would that mean that i915 is in the initramfs ?

pvalena · 2026-02-10T16:47:54Z

here module = dracut module; which also pulls dependencies (modules, binaries, and various files it might as well; recursively; if needed).

I do not think the drm dracut module pulls in any (non-kernel) binary. This is also what seems to be in your logs - only additional kernel modules. Also it does not seem to pull in any other dracut module.

I was refering to the dracut module concept in general (only if that specific module needs it), not to this specific case. Just as an examle to illustrate what dracut module is.

From the git commit message of this PR:

Some graphic cards require the 'drm' module to be present to be able to setup the console font (e.g. 'i915' requires it).

If 'i915' requires it, would that mean that i915 is in the initramfs ?

Right, I'm afraid I also copied the commit message as well. Let me ping the original author for comment on this specific example -- @rmetrich PTAL.

(Note: I think he's currently unavailable and will respond in 2-3 weeks)

jozzsi · 2026-02-10T17:22:37Z

I just want to point out that this PR already landed in the RHEL-10 repo - redhat-plumbers/dracut-rhel10#59 .

I wonder how it was tested and reviewed before merging into product branch (and before landing it upstream).

pvalena · 2026-02-10T18:09:29Z

I just want to point out that this PR already landed in the RHEL-10 repo - redhat-plumbers/dracut-rhel10#59 .

I wonder how it was tested and reviewed before merging into product branch (and before landing it upstream).

To clarify: yes, this was merged, and is being tested internally as now :) nothing landed yet. Thank you for the interest in our processes.

jozzsi · 2026-03-31T12:08:43Z

To clarify: yes, this was merged, and is being tested internally as now :)

Thanks for the clarification. Can you share the result of this testing to help with the upstream PR review ?

devkontrol · 2026-04-14T12:40:40Z

@Vogtinator - based on valuable feedback on other PRs - for visibility and potentially for more input on this. Thanks

Vogtinator · 2026-04-14T13:11:28Z

AFAICT this would pull in the drm and simpledrm modules even if plymouth is not installed?

IMO that's a major regression in initrd size, as it will pull in all kinds of DRM modules and GPU firmware by default that way.

Rolv-Apneseth · 2026-04-14T14:20:16Z

IMO that's a major regression in initrd size, as it will pull in all kinds of DRM modules and GPU firmware by default that way.

Potentially relevant: #2362 (comment)

jwrdegoede · 2026-04-14T15:08:52Z

Diff: https://gist.github.com/pvalena/5ae5dca31b5410d89a377febfc612937

Thank you for providing this and sorry for being slow to respond. So what is new here is the addition of the bochs.ko kernel module.

I was confused before because when you mentioned adding the drm module I though you mentioned adding the drm.ko kernel module (which appears to be builtin on your kernel), but I now see you meant the drm dracut module. In cases where there can be confusion like this please fully spell out "dracut module" when talking about a dracut module.

So it seems that loading the bochs drm kernel module which will use fbcon as console, likely replacing vgacon, makes things work. This suggests that you are using a font which is not compatible with vgacon. So a less invasive fix would be to select a font which is compatible with vgacon.

An alternative fix would be to use the new vesa drivers/gpu/drm/sysfb/vesadrm.c driver which is a drm driver for vesa framebuffers and the bochs compatible VGA card in your vm should support a vesa framebuffer. This will give you fbcon over the vesadrm fb which should be just as compatible as doing this through the bochs drm driver without requiring the addition of drm kernel modules to the initramfs.

IMHO adding drm kernel modules to the base initramfs without plymouth as this PR does is not acceptable since for non-hostonly / generic initramfs builds this will make the initramfs absolutely huge since the amdgpu and especially the nova drm drivers require huge firmwares to get added to the initramfs.

Also all in all I still miss the following here:

A proper use-case description / description of the problem this tries to fix. You mention that rd.break shows the font not being loaded, but why is this actually a problem ? We don't put translations in the initramfs, so the default font should work fine, at least until the switch to the real rootfs happens ?
A proper root-cause analysis of why adding the drm modules helps. As mentioned I suspect the problem is that setfont fails because the vgacon console driver is in use at this point and the selected font is not vgacon compatible, but why not select another vgacon compatible font ?

pvalena requested a review from a team as a code owner December 22, 2025 21:30

github-actions Bot added systemd Issues related to the systemd module modules Issue tracker for all modules labels Dec 22, 2025

pvalena mentioned this pull request Dec 22, 2025

feat(systemd): pull 'drm' module unless excluded redhat-plumbers/dracut-rhel10#59

Merged

Conan-Kudo previously approved these changes Dec 22, 2025

View reviewed changes

Conan-Kudo enabled auto-merge (rebase) December 22, 2025 22:10

auto-merge was automatically disabled January 6, 2026 17:00
Head branch was pushed to by a user without write access

pvalena dismissed Conan-Kudo’s stale review via d6f6b30 January 6, 2026 17:00

pvalena force-pushed the pr-2719 branch from 1df1dae to d6f6b30 Compare January 6, 2026 17:00

github-actions Bot added the i18n Issues related to the i18n module label Jan 6, 2026

pvalena force-pushed the pr-2719 branch from d6f6b30 to 24c4b5b Compare January 6, 2026 18:57

pvalena force-pushed the pr-2719 branch from 24c4b5b to 2b724f0 Compare January 22, 2026 07:14

github-advanced-security AI found potential problems Jan 22, 2026

View reviewed changes

Comment thread modules.d/20i18n/module-setup.sh Fixed

pvalena force-pushed the pr-2719 branch from 2b724f0 to 0ee9ce8 Compare January 22, 2026 07:17

pvalena force-pushed the pr-2719 branch from 0ee9ce8 to d56b581 Compare January 27, 2026 03:27

pvalena force-pushed the pr-2719 branch from 7ef1049 to b391fa7 Compare January 27, 2026 04:55

LaszloGombos force-pushed the pr-2719 branch from b391fa7 to 5eb003e Compare January 28, 2026 01:44

LaszloGombos previously approved these changes Jan 28, 2026

View reviewed changes

bdrung requested changes Jan 28, 2026

View reviewed changes

pvalena and others added 2 commits February 5, 2026 17:10

fix(i18n): load module after plymouth module to avoid collision

3170826

i18n module loads different drm module based on what is already loaded, but plymouth module decides which drm to load based on config files - therefore plymouth needs to load before i18n.

pvalena dismissed LaszloGombos’s stale review via 3170826 February 5, 2026 16:10

pvalena force-pushed the pr-2719 branch from 5eb003e to 3170826 Compare February 5, 2026 16:10

jozzsi mentioned this pull request Apr 9, 2026

Enable virtio-gpu by default in aarch64 in hostonly=no mode #2362

Open

travier mentioned this pull request Apr 15, 2026

OCPBUGS-83404: overlay/05rhcos: omit the dracut drm module by default due to its size coreos/rhel-coreos-config#241

Merged

Conversation

pvalena commented Dec 22, 2025

Changes

Checklist

Manual testing only on a QEMU/KVM

Uh oh!

LaszloGombos commented Jan 6, 2026

Uh oh!

pvalena commented Jan 6, 2026

Uh oh!

pvalena commented Jan 7, 2026

Uh oh!

bdrung commented Jan 7, 2026

Uh oh!

jozzsi commented Jan 7, 2026

Uh oh!

pvalena commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jozzsi commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jozzsi commented Jan 8, 2026

Uh oh!

jozzsi commented Jan 8, 2026

Uh oh!

pvalena commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pvalena commented Jan 27, 2026

Uh oh!

jozzsi commented Jan 27, 2026

Uh oh!

pvalena commented Jan 27, 2026

Uh oh!

jozzsi commented Jan 27, 2026

Uh oh!

pvalena commented Jan 28, 2026

Uh oh!

Uh oh!

Uh oh!

bdrung Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

pvalena Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

jozzsi commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pvalena commented Feb 5, 2026

Uh oh!

pvalena commented Feb 5, 2026

Uh oh!

jwrdegoede commented Feb 8, 2026

Uh oh!

jwrdegoede commented Feb 8, 2026

Uh oh!

pvalena commented Feb 9, 2026

Uh oh!

jwrdegoede commented Feb 9, 2026 via email

Uh oh!

jwrdegoede commented Feb 9, 2026

Uh oh!

pvalena commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pvalena commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jozzsi commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jozzsi commented Feb 10, 2026

Uh oh!

pvalena commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jozzsi commented Feb 10, 2026

pvalena commented Jan 8, 2026 •

edited

Loading

jozzsi commented Jan 8, 2026 •

edited

Loading

pvalena commented Jan 8, 2026 •

edited

Loading

jozzsi commented Jan 28, 2026 •

edited

Loading

pvalena commented Feb 9, 2026 •

edited

Loading

pvalena commented Feb 9, 2026 •

edited

Loading

jozzsi commented Feb 10, 2026 •

edited

Loading

pvalena commented Feb 10, 2026 •

edited

Loading