[ SOLVED ] Plymouth can't start SDDM?

bobert_2728 · 2024-02-10 09:26:22

Hello! I am new to this Linux distribution. And I really love how it is so customizable. But here is the issue, I am getting black screen instead of login screen if I enable Plymouth. I don't know if I have done something bad, I followed in this wiki: https://wiki.archlinux.org/title/Plymouth

What I have done

- At first, after installed, and make new image, reboot, I got grey screen and 3 dots, from reddit, it is called: Fallback mode/Text mode
- After figuring out it's due to Graphic issues, I added i915 to module line of mkinitcpio.conf and make image
- Yay! Plymouth is working with incredible resolution. But, after interrupted by complete boot, the spinner ends, but remain splash. after time out, what I got is blank screen (signal still there, but nothing on display, just black)
- Disabling `splash` will fix this issue
- After doing more research on forums, and reddit, I installed vf86-intel gpu package or something
- Installed 2 AUR packages: plymouth-git sddm-git
- It still doesn't work, downgrade, and decided to try systemd-git (this is why on boot.log you can see some failed messages, but it can boot.)
- After systemd upgrade, it still doesn't work.
Edit:
+ Even when press Esc to show log, it just stuck at Starting SDDM or User Permit thing, I don't remember.

Some information

Bootloader: rEFInd
Secure boot: disabled
DE: Plasma 6 (kde-unstable)
GPU: Intel iGPU
CPU: Intel i3 Gen 7
Disk: HDD - WD

Some pastebin log

$ journalctl
$ lastlog
/var/log/boot.log
/var/log/plymouth-debug.log
Hope these help. If I am missing any information, sorry, and please tell me.

Last edited by bobert_2728 (2024-03-20 04:44:58)

seth · 2024-02-10 10:02:52

Plymouth doesn't start anything.
SDDM starts however, but

Feb 10 00:51:12 GL-Workspace systemd[1]: /etc/systemd/system/sddm.service.d/override.conf:1: Unknown section 'General'. Ignoring.

there's a bogus override that might be relevant.

I installed vf86-intel gpu package or something

"or something"?
remove xf86-video-intel again, you don't want that at all

- Installed 2 AUR packages: plymouth-git sddm-git
- It still doesn't work, downgrade, and decided to try systemd-git (this is why on boot.log you can see some failed messages, but it can boot.)

And you probably stand a better chance when undoing that, too.

On a wild guess, add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel … mmand_line
Then post an updated journal and your Xorg log, https://wiki.archlinux.org/title/Xorg#General

c00ter · 2024-02-10 12:05:01

OP, you're running KDE Unstable. Why isn't this posted to [kde-unstable]?

bobert_2728 · 2024-02-10 13:05:49

seth wrote:

Plymouth doesn't start anything.
SDDM starts however, but
Feb 10 00:51:12 GL-Workspace systemd[1]: /etc/systemd/system/sddm.service.d/override.conf:1: Unknown section 'General'. Ignoring.
there's a bogus override that might be relevant.
I installed vf86-intel gpu package or something
"or something"?
remove xf86-video-intel again, you don't want that at all
- Installed 2 AUR packages: plymouth-git sddm-git
- It still doesn't work, downgrade, and decided to try systemd-git (this is why on boot.log you can see some failed messages, but it can boot.)
And you probably stand a better chance when undoing that, too.
On a wild guess, add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel … mmand_line
Then post an updated journal and your Xorg log, https://wiki.archlinux.org/title/Xorg#General

1. does that mean I'll have to use this command?

sudo systemctl revert display-manager

I'll do it.

2. Sure

3. Undoing systemd-git? ok

4. Right away! EDIT: just a clue, if I perform your provided Kernel Commandline with splash, it still doing same thing, but without splash, it booted!
$ journalctl
$ journalctl -b
/var/log/xorg.0.log

Last edited by bobert_2728 (2024-02-10 13:09:06)

bobert_2728 · 2024-02-10 13:07:02

c00ter wrote:

OP, you're running KDE Unstable. Why isn't this posted to [kde-unstable]?

Hello there sir, sorry, because I thought Newbie corners can post any issues. Next time, I'll learn from it!

seth · 2024-02-10 15:30:02

[    25.132] (**) |--&gt;Screen "Default Screen Section" (0)
[    25.132] (**) |   |--&gt;Monitor "<default monitor>"

Did you copy and paste that from a browser or so?
Make everyones lifes easier: 1st link below.

[    25.025] Kernel command line: ro root=/dev/sda6 rw initcall_blacklist=simpledrm_platform_driver_init initrd=initramfs-linux.img

That's the splash-less log, I'm afraid that doesn't really help.

Feb 10 19:26:19 GL-Workspace sddm[430]: Display server starting...
Feb 10 19:26:19 GL-Workspace sddm[430]: Writing cookie to "/run/sddm/xauth_gbaiNp"
Feb 10 19:26:19 GL-Workspace sddm[430]: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_gbaiNp -noreset -displayfd 16
Feb 10 19:26:24 GL-Workspace NetworkManager[371]: <info>  [1707567984.0864] manager: startup complete
Feb 10 19:26:27 GL-Workspace systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Feb 10 19:26:47 GL-Workspace systemd[1]: systemd-hostnamed.service: Deactivated successfully.
--- journal ends here

When you're booting with the splash parameter and itdoesntwork™, do you hard reboot with the power button?
Don't.
- try to switch to a different TTY
- ssh into the system if you've the opportunity and reboot from there
- frenetically press ctrl+alt+del until systemd reboots
- https://wiki.archlinux.org/title/Keyboa … el_(SysRq)

Not sure whether qt6 might be dropping the ball here, but please try the behavior w/ at least the SDDM version from the extra repo (doesn't look like it's linking other KDE stuff)

bobert_2728 · 2024-02-10 15:57:21

seth wrote:

[    25.132] (**) |--&gt;Screen "Default Screen Section" (0)
[    25.132] (**) |   |--&gt;Monitor "<default monitor>"
Did you copy and paste that from a browser or so?
Make everyones lifes easier: 1st link below.
[    25.025] Kernel command line: ro root=/dev/sda6 rw initcall_blacklist=simpledrm_platform_driver_init initrd=initramfs-linux.img
That's the splash-less log, I'm afraid that doesn't really help.
Feb 10 19:26:19 GL-Workspace sddm[430]: Display server starting...
Feb 10 19:26:19 GL-Workspace sddm[430]: Writing cookie to "/run/sddm/xauth_gbaiNp"
Feb 10 19:26:19 GL-Workspace sddm[430]: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_gbaiNp -noreset -displayfd 16
Feb 10 19:26:24 GL-Workspace NetworkManager[371]: <info>  [1707567984.0864] manager: startup complete
Feb 10 19:26:27 GL-Workspace systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Feb 10 19:26:47 GL-Workspace systemd[1]: systemd-hostnamed.service: Deactivated successfully.
--- journal ends here
When you're booting with the splash parameter and itdoesntwork™, do you hard reboot with the power button?
Don't.
- try to switch to a different TTY
- ssh into the system if you've the opportunity and reboot from there
- frenetically press ctrl+alt+del until systemd reboots
- https://wiki.archlinux.org/title/Keyboa … el_(SysRq)
Not sure whether qt6 might be dropping the ball here, but please try the behavior w/ at least the SDDM version from the extra repo (doesn't look like it's linking other KDE stuff)

1. Yes! And I'll follow the instructions from the provided link below.
2. Splashless? Well if I add splash parameter then it still stuck and freeze. I have posted a log which is interrupted. Check journalctl link (not journalctl -b)
3. Noted. But on switching TTY, I have tried spamming Ctrl+Alt+F[2-8] and it doesn't even switch, plymouth screen is there, I also have pressed Esc.
And also, Ctrl+Alt+Del doesn't work on blank screen, I have tried spamming, the HDD indicator just spin until I release all keys.
4. Well I think maybe due to bad installation on me, I don't think it's because of kde-unstable because it also happens on KDE 5

Is there anyway now? Or just simply use another display manager or clean install with another choice?
edit: do i need dmesg?

Last edited by bobert_2728 (2024-02-10 16:02:52)

seth · 2024-02-10 16:05:25

We'll first and foremost need a usable journal and xorg log.
If you can't get systemd to reboot and you cannot login via ssh, use the sysrq+REISUB and on the next boot only boot the multi-user.target (2nd link below) to not override the xorg logs.

Or just simply use another display manager or clean install with another choice?

You most certainly do not have to re-install to switch the DM, but I'd not hold my breath for other DMs either.
Can you boot the multi-user.target w/ plymouth/splash?
B/c of the previously botched sddm drop-in, are you attempting https://wiki.archlinux.org/title/Plymou … transition ?
Deos it work w/o?

bobert_2728 · 2024-02-10 16:14:15

seth wrote:

We'll first and foremost need a usable journal and xorg log.
If you can't get systemd to reboot and you cannot login via ssh, use the sysrq+REISUB and on the next boot only boot the multi-user.target (2nd link below) to not override the xorg logs.
Or just simply use another display manager or clean install with another choice?
You most certainly do not have to re-install to switch the DM, but I'd not hold my breath for other DMs either.
Can you boot the multi-user.target w/ plymouth/splash?
B/c of the previously botched sddm drop-in, are you attempting https://wiki.archlinux.org/title/Plymou … transition ?
Deos it work w/o?

1. Noted! I'll try tomorrow, I finished my shift today.
2. For smooth transition, it doesn't even work. Even I disabled it. And earlier I mentioned that I use systemctl to revert sddm unit, that removed every config file, including plymouth file. So, it doesn't work even with/without smooth transition.

WorMzy · 2024-02-10 18:27:20

If you're new to this distro, it's not a great idea to replace large parts of it with unsupported AUR packages OR use the unstable testing repositories. Doing both is asking for trouble.

Mod note: as far as I'm aware, the -git packages have been swapped out for their stable equivalents, so moving to [testing].

Make sure you have read https://wiki.archlinux.org/title/Offici … positories

bobert_2728 · 2024-02-11 01:12:01

WorMzy wrote:

If you're new to this distro, it's not a great idea to replace large parts of it with unsupported AUR packages OR use the unstable testing repositories. Doing both is asking for trouble.
Mod note: as far as I'm aware, the -git packages have been swapped out for their stable equivalents, so moving to [testing].
Make sure you have read https://wiki.archlinux.org/title/Offici … positories

Thanks for notifying! But KDE-Unstable also count as testing, right? I just downgraded these 3 git packages

bobert_2728 · 2024-02-11 02:00:56

seth wrote:

We'll first and foremost need a usable journal and xorg log.
If you can't get systemd to reboot and you cannot login via ssh, use the sysrq+REISUB and on the next boot only boot the multi-user.target (2nd link below) to not override the xorg logs.
Or just simply use another display manager or clean install with another choice?
You most certainly do not have to re-install to switch the DM, but I'd not hold my breath for other DMs either.
Can you boot the multi-user.target w/ plymouth/splash?
B/c of the previously botched sddm drop-in, are you attempting https://wiki.archlinux.org/title/Plymou … transition ?
Deos it work w/o?

Hello there!
1. With splash, I booted to a terminal-like login, logged in and got the log, here it is
journalctl -b
Xorg log

2. For smooth transition, it doesn't even work. Even I disabled it. And earlier I mentioned that I use systemctl to revert sddm unit, that removed every config file, including plymouth file. So, it doesn't work even with/without smooth transition.

seth · 2024-02-11 08:33:55

The xorg log is still from a splash-less boot, meanwhile the journal is from a splash-boot but only starting the multi-user.target.

What you want to do is to
* boot the graphical.target w/ splash (fail)
* reboot as cleanly as possibly (sysrq at least, do not use the power button)
* into the multi-user.target (w/ or w/o splash doesn't matter at this point)
* then post the xorg log (which will still be from the previously failing boot) and the system journal of that previous boot ("-b -1", not "-b")

We want to see what happens when it *doesn't* work.

bobert_2728 · 2024-02-11 12:40:31

seth wrote:

The xorg log is still from a splash-less boot, meanwhile the journal is from a splash-boot but only starting the multi-user.target.
What you want to do is to
* boot the graphical.target w/ splash (fail)
* reboot as cleanly as possibly (sysrq at least, do not use the power button)
* into the multi-user.target (w/ or w/o splash doesn't matter at this point)
* then post the xorg log (which will still be from the previously failing boot) and the system journal of that previous boot ("-b -1", not "-b")
We want to see what happens when it *doesn't* work.

Xorg
journalctl -b -1
This time, I used SysRQ shortcut.
*Just take a look at the xorg log, I saw a lot of warning logs about graphics thing.

seth · 2024-02-11 14:57:44

[    22.235] (EE) Failed to load module "intel" (module does not exist, 0)
[    22.275] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    22.276] (EE) Failed to load module "vesa" (module does not exist, 0)

isn't critical, but the log ends rather early what smells like problems.

Feb 11 19:23:17 GL-Workspace kernel: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
Feb 11 19:23:17 GL-Workspace kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

has returned?
Keep that blacklisted.

There once was https://aur.archlinux.org/cgit/aur.git/ … h=plymouth
Does that service instead of sddm.service work?

bobert_2728 · 2024-02-12 00:49:15

seth wrote:

[    22.235] (EE) Failed to load module "intel" (module does not exist, 0)
[    22.275] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    22.276] (EE) Failed to load module "vesa" (module does not exist, 0)
isn't critical, but the log ends rather early what smells like problems.
Feb 11 19:23:17 GL-Workspace kernel: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
Feb 11 19:23:17 GL-Workspace kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
has returned?
Keep that blacklisted.
There once was https://aur.archlinux.org/cgit/aur.git/ … h=plymouth
Does that service instead of sddm.service work?

Hello there! It doesn't work, I replaced sddm to sddm-plymouth, and also the init is blacklisted. Do you need Xorg log?

Last edited by bobert_2728 (2024-02-12 06:05:30)

seth · 2024-02-12 14:39:52

Probably not, you could try to enable plymouth debugging, https://wiki.archlinux.org/title/Plymouth#Debugging and ideally find a way to ssh into the stalled system for an online analysis.

bobert_2728 · 2024-02-16 08:44:36

seth wrote:

Probably not, you could try to enable plymouth debugging, https://wiki.archlinux.org/title/Plymouth#Debugging and ideally find a way to ssh into the stalled system for an online analysis.

Couldn't find anymore way. I have tried reading debug log, nothing's wrong. Here's the file
http://0x0.st/Hnbk.txt
Also, sorry for being inactive, I was busy.

seth · 2024-02-17 10:00:08

00:00:19.614 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: device subsystem is drm
00:00:19.614 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: found DRM device /dev/dri/renderD128
00:00:19.614 ../plymouth-24.004.60/src/libply-splash-core/ply-renderer.c:23: trying to open renderer plugin /usr/lib/plymouth/renderers/drm.so
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:894:c: creating renderer backend for device /dev/dri/renderD128
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:977:l: Opening '/dev/dri/renderD128'
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:987:l: drm driver: i915
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:1576:: Could not get card resources
00:00:19.615 ../plymouth-24.004.60/src/libply-splash-core/ply-renderer.c:24: could not query rendering device for plugin /usr/lib/plymouth/renderers/drm.so
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:1052:: closing device
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:1007:: unloading backend
00:00:19.615 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:920:d: destroying renderer backend for device /dev/dri/renderD128
…
00:00:20.125 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: creating objects for drm devices
00:00:20.125 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: found device /sys/devices/pci0000:00/0000:00:02.0/drm/card0
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: device subsystem is drm
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: found DRM device /dev/dri/card0
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: found device /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: found device /sys/devices/pci0000:00/0000:00:02.0/drm/renderD128
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: device subsystem is drm
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: found DRM device /dev/dri/renderD128
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-renderer.c:23: trying to open renderer plugin /usr/lib/plymouth/renderers/drm.so
00:00:20.126 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:894:c: creating renderer backend for device /dev/dri/renderD128
00:00:20.126 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:977:l: Opening '/dev/dri/renderD128'
00:00:20.126 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:987:l: drm driver: i915
00:00:20.126 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:1576:: Could not get card resources
00:00:20.126 ../plymouth-24.004.60/src/libply-splash-core/ply-renderer.c:24: could not query rendering device for plugin /usr/lib/plymouth/renderers/drm.so
00:00:20.126 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:1052:: closing device
00:00:20.126 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:1007:: unloading backend
00:00:20.127 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:920:d: destroying renderer backend for device /dev/dri/renderD128
00:00:20.127 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: trying to find associated drm node for fb device (path: pci-0000:00:02.0)
00:00:20.129 ../plymouth-24.004.60/src/libply-splash-core/ply-device-manage: ignoring, since there's a DRM device associated with it
…
00:00:26.092 ../plymouth-24.004.60/src/plugins/renderers/drm/plugin.c:954:d: dropping master

This at least looks bad, but other than the simpledrm device, I'd not know what could cause this.

bobert_2728 · 2024-03-17 15:38:48

Hello there, it's been some months since I'm busy for works. Well, thanks everyone that subscribed/interested in this post, answered the question. I've managed to make it work by doing a clean install of Arch. I'll mark the post as solved.

[ SOLVED ]
- Reinstall Arch Linux.!

Last edited by bobert_2728 (2024-03-20 04:58:14)

bobert_2728 · 2024-03-20 05:02:25

Sorry for the bad information, by the way, I've finally found the issue! It's coming from SDDM, it hasn't supported smooth transition yet!
To everyone using smooth transition with SDDM and having same issue like me, just do this

# systemctl revert sddm.service

Thanks for everyone who helped me.

Arch Linux

#1 2024-02-10 09:26:22