Customazing my Debian: GRUB, LUKS and SSDM

Posted Sep 28, 2025

By Jesús Adolfo Parra Parra

14 min read

Today I decided to give a more personal touch to my desktop starting from the beginning, the boot process.

Using a GRUB theme

I discovered some weeks ago this page with very good looking GRUB themes https://github.com/Jacksaur/Gorgeous-GRUB/tree/main.

I tried two of them, the Cyberpunk 2077 and the Fallout one.

Original look

After I updated to debian 13, my GRUB looked like this:

Grub is only shown in one screen

The text is really small but it has my Debian and UEFI options

I am not sure why my Windows didn’t appear as an option.

Installing a theme

The instructions are pretty easy https://github.com/Jacksaur/Gorgeous-GRUB/blob/main/Installation.md Basically the steps are:

Download the theme
Put the files in /boot/grub/themes
Modify /etc/default/grub file:
- GRUB_THEME= line should point to our new theme’s theme.txt
- GRUB_GFXMODE= we can modify this line to change the resolution (this step is optional)
Finally run sudo update-grub.

Cyberpunk 2077 theme

The github page took me to its pling.com page, there I found the Files tab and downloaded the main.zip file.

To unzip I just ran:

unzip Cyberpunk-GRUB-Theme-main.zipCyberpunk-GRUB-Theme-main.zip

That will upzip the folder we need.

As I didn’t have the theme folder I created before moving, then I moved it.

sudo mkdir /boot/grub/themes
sudo mv Cyberpunk-GRUB-Theme-main /boot/grub/themes/.

After that I modify my /etc/default/grub file I added this line

GRUB_THEME="/boot/grub/themes/Cyberpunk-GRUB-Theme-main/Cyberpunk/theme.txt"

Finally

sudo update-grub

Result:

Grub still in only one screen

Details of my new GRUB

After that I decide to reduce the resolution to make the letter bigger. I did some quick tests and chose GRUB_GFXMODE=1024x768 was good enough. I just added that line below the theme line in /etc/grub/default and that’s it.

This is the final result.

Now I can read easily

Fallout theme

I steps I did are exaclty the same (in fact easier as everything is ready), so there is no necessary to write them again.

However, this is the result:

Nice, it looks very nice

Improving LUKS prompt

After GRUB the first thing was a prompt asking me for a passphrase to unlock LUKS. Something like this:

The prompt is in both monitors, but that is another issue.

Before the prompt there is more information about the boot process.

To solve this issue, I used Plymouth ¹ which is a program that allow us to have a graphical boot experience² (basically it shows a boot screen).

Installing Plymouth

In Debian was really easy as it is in the official repository. I ran:

sudo aptitude install plymouth kde-config-plymouth plymouth-themes

And it installed them and any dependency.

kde-config-plymouth: It’s a package that allow us to customize plymouth graphically, in the KDE settings.
plymouth-themes: Just a bunch of themes that Debian provides.

Choosing a theme

Now I could chose one of the themes I just installed. These are the steps:

Go to System Settings
In the Appareance & Style section, click Color and Themes
Click in Boot Splash Screen
Click in any of the available theme and then click Apply (It will ask for your password)

A visual reference of the steps.

After that I was ready for the test.

I restarted my PC and nothing happened. I went to the Debian’s wiki and noticed that I forgot to change the GRUB_CMDLINE_LINUX_DEFAULT in my /etc/default/grub.

I added splash to the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

And ran sudo update-grub to apply the changes.

Result:

New splash boot

Well it did show me an image when prompted for LUKS password, it wasn’t the theme I chose. So, I went to the Debian wiki again and they recommend to change the Theme line in /usr/share/plymouth/plymouthd.defaults

I also ran:

sudo update-initramfs -u -k all

But it didn’t work, in fact made everything worse. Plymouth started crashing.

Plymouth crashed but the booting process continued

The stackdump can be seen in both monitors

I went to the Arch’s wiki I noticed that maybe the error was because Plymouth (or the theme) is not handling well my weird monitor setup.

I started to search again I lucky enough I found this comment in the Arch’s forums. Basically, we can disable any monitor using Kernel Mode Setting.

I decided to give it a chance.

I modify my GRUB file again, to this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=HDMI-A-2:d"

And finally I got:

Solar splash boot

Additionally I solved the issue of having the LUKS prompt in two monitors, however, the KMS setting disabled completely my second monitor, I couldn’t enable it in KDE.

In the next section I talk about some workaround for that.

A Better SDDM

So the my first step was to undo the changes I did before, I enabled my second monitor and disabled Plymouth (I removed the video and splash from the GRUB_CMDLINE_LINUX_DEFAULT).

Don’t forget to run sudo update-grub after modifying any GRUB file

Now I have a base where I can start experimenting.

The first thing is to notice that even if KDE is running Wayland, SDDM is not. SDDM launch an X server.

        
      
systemctl status
...
           │ ├─sddm.service
           │ │ ├─1497 /usr/bin/sddm
           │ │ └─1521 /usr/lib/xorg/Xorg -dpi 120 -background none -seat seat0 vt2 -auth /run/sddm/xauth_ztxQgn -noreset -displayfd 16
...

KDE has an option to apply its monitor settings to SDDM, but it works only if SDDM is running Wayland.

Changing SDDM from X11 to Wayland

Once again, Arch’s wiki to the rescue.

I created the file /etc/sddm.conf.d/10-wayland.conf and put the lines they specify:

        
      
[General]
DisplayServer=wayland
GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell

[Wayland]
CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1

And tried.

Success!, SSDM didn’t launch a X11 server.

        
      
systemctl status
...
           │ ├─sddm.service
           │ │ └─1478 /usr/bin/sddm
...

Making SDDM use only one monitor

For this step I found this reddit thread

It says that we can disable one monitor in the KDE settings, apply the monitor settings to SDDM, enable it again and then SDDM will only show in one monitor.

To disable a monitor, I went to Display & Monitor in the Input & Output section of KDE System Settings. I only need to uncheck the Enabled box.

My settings with only 1 monitor enabled.

I followed by applying the KDE settings to SDDM

Go to System Settings
In the Appareance & Style section, click Color and Themes
Click in Login Screen (SDDM)
Click in Apply Plasma Settings… (it is in the top). And write your password.

SDDM settings

Finally I enabled again the second monitor and it worked as expected.

Final result:

SDDM is only in one monitor

But KDE is has the two monitors active

Enabling second monitor after boot

With the KMS trick (basically disabling the second monitor), if fixed several of my issues:

SDDM is shown only in one monitor.
The LUKS password prompt is shown in one monitor too.
Plymouth shows the animation correctly.

But it didn’t allow me to use both monitors at the same time, what I needed is to have 1 monitor at boot and 2 after booting (or after login).

I found this another reddit thread with exactly what I need but for X11. So I decided to do something similar but in Wayland.

The Hard Way to solve it

I had to do a bunch of things so I decided to called The Hard Way. This method involves getting the EDID of the second monitor, override it and trigger a connection and disconnection from the kernel.

There is already an Arch’s wiki page with that information and I found this post with related information

Steps:

I need to enable both monitors again so I removed video=HDMI-A-2:d from my /etc/default/grub.

Make a copy of the EDID

sudo mkdir /usr/lib/firmware/edid 
sudo cp /sys/class/drm/card0-HDMI-A-2/edid /usr/lib/firmware/edid/viewsonic.bin

I didn’t have any problem with the resolution so the EDID file was fine. I could just copy it.

Make an script to load the EDID file and simulate the hotplug of the monitor.

Before doing step 3, I had a hunch so I decided to test the hotplug part.
1 2 echo 1 > /sys/kernel/debug/dri/0/HDMI-A-2/trigger_hotplug -bash: /sys/kernel/debug/dri/0/HDMI-A-2/trigger_hotplug: Operation not permitted
I wasn’t sure why something seemesly simple could fail, but checking dmesg I found this
1 [ 1010.803098] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7
Checking that man page, I learnt that the lockdown forbids the use of some kernel features (for example giving access to some subsystems, like debugfs I which I needed), also this:

On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode.

I looked how to disable the lockdown to no avail, until I found this thread in the RedHat site

Contact hardware vendor to disable Secure Boot in the server BIOS. There is no other way to disable the feature.

The only way to avoid the lockdown is to disable the Secure Boot. I disabled the Secure Boot in my PC to proceed with my experiments.

I didn’t want to add so much detail about how to disable Secure Boot as each motherboard will be different.

On my PC, I went to the UEFI Settings, select the Boot tab, select Secure Boot, and then disable it.

After disabling Secure Boot, echo 1 > /sys/kernel/debug/dri/0/HDMI-A-2/trigger_hotplug was working.

Disabling Secure Boot is not the most secure thing you can do to your PC. Make sure you understand the implications.
Making the script for real

As I needed to run the script always after boot I thought that it would be better to use a systemd service.

These two links provide all the information I needed:

        
      
[Unit]
Description=Enable the second monitor
Wants=sddm.service
After=sddm.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c "cat /usr/lib/firmware/edid/viewsonic.bin > /sys/kernel/debug/dri/0/HDMI-A-2/edid_override"
ExecStart=/bin/bash -c "echo on > /sys/kernel/debug/dri/0/HDMI-A-2/force"
ExecStart=/bin/bash -c "echo 1 > /sys/kernel/debug/dri/0/HDMI-A-2/trigger_hotplug"

[Install]
WantedBy=graphical.target

This script could not work in your system as the path would be different.

I called second-monitor.service and moved it to /etc/systemd/system/ and refresh the list of units and finally enabled it.

sudo cp second-monitor.service /etc/systemd/system/.
sudo systemctl daemon-reload
sudo systemctl enable second-monitor.service

Tested it !

And it did work!. But I had to change the Solar theme to ceratopsian (The Debian’s 13 default), for some reason Solar just crashed.

So basically what I did was to disable one monitor using kernel parameters, and enable again with an small systemd service. This allowed to keep only one monitor working during boot and it looked a lot better.

The Easy way

Now, I tested another way to solve my issue, one that doesn’t envolve disabling secure boot or systemd services.

From the Plymouth’s page in the Arch wiki, I noticed that Plymouth can use the UEFI framebuffer³ and to test it I only had to add this plymouth.use-simpledrm parameter to the kernel.

So modified my /etc/default/grub.

After reboot, as I didn’t notice any difference, I added plymouth.debug to the kernel’s parameters to get more information.

After checking /var/log/plymouth-debug.log I saw

00:00:17.165 ../src/plugins/renderers/drm/plugin.c:987:load_driver         : drm driver: amdgpu

Well, it is using the amdgpu driver. Honestly I am not 100% sure of why it is not using the UEFI framebuffer, but the Arch wiki mentions that old UEFI system won’t use SimpleDRM as default because of the low resolution they support. Maybe my motherboard has one of those UEFI systems.

The Middle way

I continued testing stuff just for fun, so after reading the original post I wondered what if I blacklist my amdgpu module too?.

I added modprobe.blacklist=amdgpu to my GRUB_CMDLINE_LINUX_DEFAULT and updated GRUB to test it.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash plymouth.use-simpledrm plymouth.debug modprobe.blacklist=amdgpu"

Plymouth in only 1 monitor and with low resolution

Plymouth logs

With those options, Plymouth shown the splash only in 1 monitor, although in a low resolution (from the logs, it seems 1024x768. So my previous guess was probably right). But to nobody surprise I ended in a text only system.

I got a text console

Pretty easy to fix, I just ran as root:

modprobe amdgpu

And I got my SSDM back.

This made me thought, What about if I mix both solutions, forcing the use of SimpleDRM and systemd service to load the amdgpu module?

And that is exactly what I did (in fact was easier as I could use my previous service as a template).

        
      
[Unit]
Description=Load the amdgpu module
Wants=sddm.service
Before=sddm.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c "modprobe amdgpu"

[Install]
WantedBy=graphical.target

systemd has systemd-modules-load.service which only purpose is to load modules at an early stage of the booting process, however I decided to use my own service because I needed the amdgpu to load much later.

sudo cp amdgpu-loader.service /etc/systemd/system/.
sudo systemctl daemon-reload
sudo systemctl enable amdgpu-loader.service

And finally, Plymouth is being shown only in one monitor (with low resolution) and I get my graphical session without manual intervention.

If you still seeing a lot of text about plymouth during boot, check if you have plymouth.debug in your kernel parameters

Conclusions

This post took me a lot more time than what I expected, at the same time I enjoyed because I felt like I learnt a lot.

I showed you:

How to use a theme in GRUB: fairly easy actually.
Making SDDM to only use one monitor: modifying SDDM to use Wayland instead of X11 worth it and making it to respect my KDE settings it’s really good. Overall I liked what I did but if SDDM is using only one monitor and KDE two. Everytime I start a session there is a sound notification of a “device being plugged-in” (the second monitor). It is not that bad though.
Using Plymouth to beautify the booting process: This was the most challenging and I am not very satisfied with it, but I learnt many things and there is a little improvement. I still wish it was more smooth (there is room for improvement so I think I will keep pushing until I get the results I want or get bored)

It is worth to notice that while I use the Arch wiki a lot, I still using a Debian system. The Arch wiki is always talking about the most up to date software available, which is not the case for Debian. In the case of Plymouth Debian is using the latest tagged release, while Arch is using the development branch basically.

Extra: Adding a background image to GRUB

It seems that specifying a theme doesn’t override the default background image, thus creating some inconsistencies. In my case I see the theme I selected and then I see the Debian’s background image.

Debian comes with the /etc/grub.d/05_debian_theme script, that makes sure there is a background image (and by default it will be Debian’s).

To fix this, I only need to add GRUB_BACKGROUND in /etc/default/grub and point it to the background theme.

For example (using the Fallout theme):

GRUB_BACKGROUND="/boot/grub/themes/fallout-grub-theme-master/background.png"

And then sudo update-grub.

Extra: KDE could replace SDDM in the future

I found this link talking about a new proposal from KDE, replacing SDDM as login manager.

It is really interesting to me as they look to improve the integration between the login manager and KDE itself.

tinkering

debian