The officially official Devuan Forum!

EDX-0

Member

Registered: 2020-12-12

Posts: 81  

black screen on boot or splash screen stuck [PSA]

this post is more of a Public Sservice Announcement as this is a problem i've encountered and solved quite a while ago but there is not enough mention online of what happens, why, or how to solve it, so this is intended as a short resource that may perhaps be easy to find.

First and foremost the symptoms you may encounter. These are to be expected on rather modern devices like laptops that support uefi options like secure boot, tho it is not related to the secure boot at all but to the other many options available on such boards.

## Symptoms  ##

on boots with splash (plymouth) the screen may simply turn black or get "stuck" on the splash animation and never advance no matter how many time goes by, on non splash boots (text only or quiet) the text either isn't cleared or a black screen is shown around the time the init goes to runlevel S, notice when this happens the sysrq keys do work and you can do the by now "classic" alt+printscr reisub to restart the machine.

the only ways you can get past the black screen or endless splash is by passing the nomodeset flag to the kernel at grub, other flags don't work, if you manage to get a x11 server running (no idea if wayland can even work here) it will be running on software rendering mode with vesa or fbdev with no way to change to accelerated rendering.

if you got all the drivers installed, in this example the packages for amd graphic cards in stable currently:

firmware-linux
firmware-linux-nonfree
firmware-amd-graphics
firmware-misc-nonfree
libglx-mesa0
libegl-mesa0
libgl1-mesa-dri
libdrm-radeon1
libdrm-amdgpu1
libdrm2
libdrm-amdgpu1
libdrm-common
libdrm2
libegl-mesa0
libegl1-mesa
libgbm1
libgl1-mesa-dri
libglapi-mesa
libglx-mesa0
libvulkan1
libx11-xcb1
libxatracker2
mesa-vulkan-drivers
mesa-vdpau-drivers
mesa-va-drivers

then when running glxinfo -B you'll see that you are running in software rendering with Vendor: VMware, Inc. (0xffffffff)

mind you that this last symptom will also occur on unsupported hardware by the kernel and drivers, for example hardware that has come out a year or 2 after the running stable devuan release, in those cases trying testing or unstable may not be a bad idea for hardware support.

## Cause ##

tangent aside, this occurs due to how the kernel gets the information about hardware from the BIOS ROM (or EFI in modern systems), as despite the uefi standarization many manufacturers will provide options that have terrible to downright hacky implementations and break the standar, crucially when it comes to providing boot options such as legacy boot and fast boot, they will expose malformed data and the kernel will fail to properly recognize the hardware.

## Solution ##

on the efi menu options for your device (usually accessed through pressing esc or f12 during boot, if not just get to a grub prompt and type fwsetup) you NEED to disable:

fastboot (name in hp bios) | fast start ("regular" name)  | ultra fast boot | ultra fast start  # this option keeps the device ram powered on, now you don't need to be a genius to figure out why that can bite you on the behind, but the linux kernel tries to resume form ram then from disk, that is the mechanism on which suspend and hybrid sleep rely on, miscrosoft since windows 8 has made their OS not truly shutdown and start cold but rather this unholy mix of sleep and hibernation along resume which causes laptops with windows OSes to discharge as the os may perform automatic updates when it "should" be off so there's no one to attend it and it can run out off battery mid update breaking the OS... truly m$ innovation

legacy boot   # yep, the BIOS mode boot, on boards from 2020 onwards you can be confident the legacy boot will be implemented incorrectly and produce bad data for the kernel to read about the hardware...

that's it, all you have to do is disable fastboot, disable legacy boot and ensure the system can only boot on uefi mode, after that the linux kernel should not have any problem detecting hardware and using it so long as the drivers are installed and support the hardware.

as for secure boot, it has been supported by debian since buster (debian 10, 2019) and it should just work without you needing to disable it, now if you need to disable secure boot to boot a devuan installation image that is a whole different can of worms that is NOT directly related to this.

## sources ##

sources and references for this post:
    amd drivers list:
        https://dev1galaxy.org/viewtopic.php?id=3913    # the one on post is updated for current stable

    bios legacy boot:
        https://bbs.archlinux.org/viewtopic.php?id=237818

    fastboot | fast start:
        there are mutiple sources for this, the brave search ai generated summary is okay enough for the purpose of this post and provides the sources used for it's summary.
        brave search summary:
            https://search.brave.com/search?q=what+ … ee79c60166
        max's tech fast boot video:
            https://www.youtube.com/watch?v=pdi9c1tsRQU

## keywords ##
boot stuck, black screen on boot, stuck on plymouth, plymouth black screen, bios, uefi, uefi legacy boot, uefi fast boot, uefi fast start, uefi fastboot

Last edited by EDX-0 (2024-07-31 21:24:57)

lynch9

Member

Registered: 2024-07-17

Posts: 11  

Re: black screen on boot or splash screen stuck [PSA]

Great PSA on BIOS/UEFI issues. Disabling fast boot and Legacy might help a lot. One should consider updating the BIOS/UEFI firmware or kernel too...

Some years ago I had the same problem, but reinstalling GRUB and forcing the machine to boot from UEFI did it for me :P different root causes too i guess

Thanks for sharing the information.

---

Hey, it's lynchian9.
Feel free to reach out via email.