Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #92449 > unrolled thread

[RFC] Using SimpleDRM in the initramfs

Back to article view | Back to linux.debian.kernel

Contents

  [RFC] Using SimpleDRM in the initramfs Ben Hutchings <benh@debian.org> - 2026-05-10 20:50 +0200
    Re: [RFC] Using SimpleDRM in the initramfs Askar Safin <safinaskar@gmail.com> - 2026-05-11 16:50 +0200
      Re: [RFC] Using SimpleDRM in the initramfs Ben Hutchings <benh@debian.org> - 2026-05-11 19:00 +0200
    Re: [RFC] Using SimpleDRM in the initramfs Askar Safin <safinaskar@gmail.com> - 2026-05-11 18:30 +0200
      Re: [RFC] Using SimpleDRM in the initramfs Ben Hutchings <benh@debian.org> - 2026-05-11 19:10 +0200
    Re: [RFC] Using SimpleDRM in the initramfs Askar Safin <safinaskar@gmail.com> - 2026-06-27 17:00 +0200

#92449 — [RFC] Using SimpleDRM in the initramfs

[Multipart message — attachments visible in raw view] — view raw

This is a follow-up to
<a0c1139da2cf2b39ac0d9b3e39ee076fe5156dde.camel@decadent.org.uk> and the
merge request
<https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453>, and
I'm hoping to include all the involved maintainers so that we can agree
on what we're trying to do.

Please reply to let me know whether I've understood the goals correctly,
or if there's already a plan that I haven't seen, or if you already know
a reaosn why this implementation wouldn't work.  Also there are some
questions at the end that I would like to know the answer to.

Ben.

## Goals

On systems where UEFI (or other platform firmware or boot loader) sets
up a usable framebuffer, the default behaviour should be that:

- SimpleDRM a.k.a. `drm_simple` is:
  - included in either the kernel image or the initramfs
  - binds to that framebuffer
  - is used by Plymouth immediately
  For the last point, see
  <https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm>.

- Other graphics drivers are not included in the initramfs.  This
  would result in much smaller images that load faster and don't fill
  up a separate `/boot` partition.

## Problems

- In the kernel, we cannot assume that an EFI framebuffer is always
  usable.  In particular, older versions of GRUB may break it by using
  a native graphics driver, but without clearing whatever signals the
  kernel that it is available.  This was fixed upstream in the default
  config for GRUB 2.14 but we cannot assume that the config change
  actually gets applied to existing installations.

- In an initramfs builder, we cannot assume that SimpleDRM will work
  just because the system boots with UEFI.

- Plymouth prefers not to use SimpleDRM devices.  This is because they
  might not be rotated or scaled properly, in which case the splash
  screen may change when the native graphics driver is loaded.  But
  the Fedora wiki page says the rotation and scaling issues have
  been mitigated.

## Implementation

It does not seem that we can safely make this change automatically on
upgrade.  It may be worth documenting how to opt-in to it in the
release notes and/or some package's NEWS file.

### Kernel

`CONFIG_SYSFB_SIMPLEFB` and `CONFIG_DRM_SIMPLE` must be enabled for all
relevant architectures.  The above merge request would do this on amd64.

### Initramfs

In initramfs-tools or plymouth, there should be a configuration option
that tells Plymouth to only include `drm_simple` (if modular) in the
initramfs, overriding `MODULES=most` for graphics drivers.

For dracut, there should be a similar configuration option that
overrides non-hostonly mode for graphics drivers.

### Installation

When booted through UEFI, the installer should:

- For itself:
  - Disable GRUB graphics drivers besides `efi_gop`:
    - Change `grub.cfg` in line with upstream changes
  
  - Disable kernel native graphics drivers.  This is not essential but
    it means that if SimpleDRM doesn't work the user will see this
    immediately rather than only after installation:
    - Add `nomodeset` to the kernel command lines in the GRUB menu

- For the installed system:
  - Configure Plymouth to use SimpleDRM devices:
    - Add `plymouth.use-simpledrm=y` to the kernel command line, or
      edit `plymouthd.conf`
  
  - Disable inclusion of additional graphics drivers in the initramfs
    - Set the configuration option added above

## Questions

What about sytsems with non-UEFI firmware (e.g. Coreboot) that sets up a
usable framebuffer?  Will they ever run the installer, or can we assume
they will be supported by images in which the above configuration should
be set up by the image builder?

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

[toc] | [next] | [standalone]

#92459

Ben Hutchings <benh@debian.org>:
> - In the kernel, we cannot assume that an EFI framebuffer is always
>   usable.  In particular, older versions of GRUB may break it by using
>   a native graphics driver, but without clearing whatever signals the
>   kernel that it is available.  This was fixed upstream in the default
>   config for GRUB 2.14 but we cannot assume that the config change
>   actually gets applied to existing installations.

It WILL be applied to existing installations.

Here is upstream commit in question:
https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=ea0b76dc4a003f2b7f828ef0c24cc8227148b2f8

It changed file util/grub.d/00_header.in in the repo. It corresponds to
/etc/grub.d/00_header in installed system. It is script, which is used
when generating /boot/grub/grub.cfg .

/etc/grub.d/00_header is present in output of
"dpkg-query -W -f='${Conffiles}\n' grub-*", but I think that this is
highly unlikely that users manually edited that file.

So the file will be simply replaced on upgrade, and then new /boot/grub/grub.cfg
will be generated from it.

Also note that I only was able to reproduce that GRUB bug in Qemu only.
And I was not able to reproduce it on real hardware. The original bug
report by Cyril Brulebois also talks about Qemu:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036019 .

Here is output of "ls /boot/grub/x86_64-efi/video*.mod" on my machine:

/boot/grub/x86_64-efi/video_bochs.mod
/boot/grub/x86_64-efi/video_cirrus.mod
/boot/grub/x86_64-efi/video_colors.mod
/boot/grub/x86_64-efi/video_fb.mod
/boot/grub/x86_64-efi/videoinfo.mod
/boot/grub/x86_64-efi/video.mod
/boot/grub/x86_64-efi/videotest_checksum.mod
/boot/grub/x86_64-efi/videotest.mod

As you can see, there is no mention of Intel, AMD or Nvidia. So usual
desktop computers should not be affected by that GRUB bug. But
there are mentions of Bochs and Cirrus, which are videocards emulated
by Qemu.

==
Askar Safin

[toc] | [prev] | [next] | [standalone]

#92461

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2026-05-11 at 17:27 +0300, Askar Safin wrote:
> Ben Hutchings <benh@debian.org>:
> > - In the kernel, we cannot assume that an EFI framebuffer is always
> >   usable.  In particular, older versions of GRUB may break it by using
> >   a native graphics driver, but without clearing whatever signals the
> >   kernel that it is available.  This was fixed upstream in the default
> >   config for GRUB 2.14 but we cannot assume that the config change
> >   actually gets applied to existing installations.
> 
> It WILL be applied to existing installations.

That depends on just how much customisation was done.

> Here is upstream commit in question:
> https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=ea0b76dc4a003f2b7f828ef0c24cc8227148b2f8
> 
> It changed file util/grub.d/00_header.in in the repo. It corresponds to
> /etc/grub.d/00_header in installed system. It is script, which is used
> when generating /boot/grub/grub.cfg .
> 
> /etc/grub.d/00_header is present in output of
> "dpkg-query -W -f='${Conffiles}\n' grub-*", but I think that this is
> highly unlikely that users manually edited that file.

It is a conffile, therefore we support users modifying it.

So if we want to make a switch on upgrade we'll have to check the GRUB
configuration to figure out whether that is safe.  That's not actually
possible because the configuration is a script and not static
definitions.  The best I think we can do is "if the GRUB configuration
is unmodified from the shipped files, we can safely switch".

> So the file will be simply replaced on upgrade, and then new /boot/grub/grub.cfg
> will be generated from it.
> 
> Also note that I only was able to reproduce that GRUB bug in Qemu only.
> And I was not able to reproduce it on real hardware.
[...]

But why does that matter?  There are a lot of Debian systems running in
VMs and some fraction of those do have people looking at their graphical
output.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

[toc] | [prev] | [next] | [standalone]

#92460

> - Plymouth prefers not to use SimpleDRM devices.  This is because they

I just installed debian forky KDE using latest daily d-i from here:

https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso

I installed it to Qemu. I picked default answers to all questions asked by d-i (except for one: I chose kde).

In resulting system Plymouth was enabled, but it didn't show any actual animation.

I know that it is enabled, because early boot messages shown in cyan as
opposed to gray.

So, why we enable Plymouth and deal with all plymouth pain if it doesn't
show any actual animation? (I don't see any value in cyan [as opposed to
gray] boot messages.)

I think that for forky plymouth should be either disabled by default
(this will free us from a lot of plymouth-related problems), either
plymouth should show some real animation. (Personally I like first
option more, because I don't see a lot of value in boot animation.)

==
Askar Safin

[toc] | [prev] | [next] | [standalone]

#92462

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2026-05-11 at 19:06 +0300, Askar Safin wrote:
> > - Plymouth prefers not to use SimpleDRM devices.  This is because they
> 
> I just installed debian forky KDE using latest daily d-i from here:
> 
> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
> 
> I installed it to Qemu. I picked default answers to all questions asked by d-i (except for one: I chose kde).
> 
> In resulting system Plymouth was enabled, but it didn't show any actual animation.

I know, our default theme is "text" for some reason.

> I know that it is enabled, because early boot messages shown in cyan as
> opposed to gray.
> 
> So, why we enable Plymouth and deal with all plymouth pain if it doesn't
> show any actual animation? (I don't see any value in cyan [as opposed to
> gray] boot messages.)
> 
> I think that for forky plymouth should be either disabled by default
> (this will free us from a lot of plymouth-related problems), either
> plymouth should show some real animation. (Personally I like first
> option more, because I don't see a lot of value in boot animation.)

My understanding is that Plymouth is needed for e.g. inputting the disk
encryption password.  But I never looked that deeply at how it's being
used.

In my opinion, when the desktop task is installed, Plymouth should be
installed and configured to use the current release's theme, like GRUB
and the desktop itself.  But I think any change to that is separate from
the SimpleDRM issue.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

[toc] | [prev] | [next] | [standalone]

#93127

Ben Hutchings <benh@debian.org>:
> ## Goals
> 
> On systems where UEFI (or other platform firmware or boot loader) sets
> up a usable framebuffer, the default behaviour should be that:
> 
> - SimpleDRM a.k.a. `drm_simple` is:
>   - included in either the kernel image or the initramfs

We got no objections to this letter, so I think we can proceed
with your plan. :)

Askar

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web