Help with BlackScreen at Login Screen

Hello, I am kind of coming back to Linux and surprised enough I thought Mandriva was dead (well, converted into Mageia which I abandoned many years ago), so I am new all again about it but installed it in my PC to give it a shot instead of Windows, until no I didn’t get really many problems since I didn’t tuch it that much but there is one thing bothering me wich I will explain below to ask for help please

  • OpenMandriva Lx version: 4:0

  • Desktop environment (KDE, LXQT…): KDE Default Plasma from clean install into physical PC

  • Description of the issue (screenshots if relevant): Everytime I boot into Mandriva, after the beautiful Plymouth/Splash screen I should see the login screen but I don’t… I see a black screen and the text cusor blinking in the top left corner of the monitor. At least there is a catch, if I press ALT F3 IIRC I get to see the console asking me for login and after I press some keys in the keyboard or only BlockNum few times the X service seems to resurrect and I see the nice logni screen so I can log in.
    The weird part is… sometimes I don’t get that problem, but when I get it the screen could stay black for HOURS until I press keys and X “reacts”.
    It seems to be a driver config issue but I am not sure so I will post here the Xorg.log

  • Relevant informations (hardware involved, software version, logs or output…): Xorg.0.txt (53,5 KB)

CPU AMD FX 6300 Vishera
RAM DDR3 x 8GB (2x4 GB)
VGA Integrated ATI Radeon™ HD 3000 GPU

If you need something else in order to check it and help me please say the word, I will gladly give as much information as needed to get help here.

Thanks in advance and sorry for bothering you people but I tried as much as I could before with no luck, don’t want to mess with the SO and don’t want to spam BlockNum every time I start the PC.

1 Like

Welcome @Shinusagi to OpenMandriva Forum. Have fun!

Edit: I asked @ #openmandriva-cooker on Freenode IRC for developer help with this. Don’t have anything myself. You are welcome to go there yourself if you wish to do so.

1 Like

Got this from a dev on IRC: Try adding ‘random.trust_cpu=1’ to boot paramaters on grub2 menu page.

On Grub2 menu screen select ‘e’ to edit and go to the line that say ‘linux’ press ‘End’ key to go to end of line and add a space and then ‘random.trust_cpu=1’ then select F10 to boot. Like this:

And try some reboots to test and see if this helps the issue. If this works there is a way to make this permanent by editing the file ‘/etc/default/grub’.

Explanation: My understanding is that this is an issue with systemd where it expects randomness to work correctly all the time. In reality it does for most users but not all. Unknown to me why systemd devs are reluctant to fix this. Edit: Well except that it might be hard to fix OR that they’d have to admit that certain assumptions they make aren’t always true. But this is hypothetical opinion on my part.

1 Like

Another way to test this is add to the line in ‘/boot/grub2/grub.cfg’ like this:

and then run:

$ sudo update-grub2

then do some reboots to test and if it works add it to ‘/etc/default/grub’:

and then run:

$ sudo update-grub2

1 Like

try pass
radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdg

/etc/default/grub in GRUB_CMDLINE_LINUX_DEFAULT


Hello, first of all thanks for answering, now… neither of the options worked

I must say I have both Mandriva AND Ubuntu but I installed first Mandriva and it being installed ALONE with nothing more than Mandriva OS the problem was there, so I thought on testing Ubuntu meanwhile and did’t have any problem with Ubuntu but the last Grub was modified by it.
Still not sure if that could affect Mandriva since like I said, I got this problem even BEFORE instaling Ubuntu

I went directly for updating the grub config in Mandriva, the Konsole command generated he config file again and BTW the commands you gave me must be inside the " " wich I mised the first time because in the picture they are outside

Here I upload the Grub config files so you can check, still nothing changed, spamming BlockNum to get X to show me the login screen.

grub_cfg.txt (14,4 KB)
grub.txt (853 Bytes)

Restarted 6 times already and all of them did the same, the first one was with only the trusted.cpu line added and he other 5 with all together.

I am no sure at this point if it can be solved TBH, maybe trying to install some ATI drivers? It is kind of annoying since it doesn’t happen in Ubuntu and I really want to use only Mandriva mainly

Oh, I must say I tryed the LiveUSB the first 3 times before installing and it NEVER got a problem or I was lucky, I know sometimes this doesn’t happen, the first one I was like “Yay!! It is working” but the again…

Thanks a lot for he help, I will try whatever you throw at me lol, I want to fix this, or well… BlockNum spam every start.

1 Like

I see that you have both my suggestion and @fedya’s suggestion in ‘/etc/default/grub’ and ‘/boot/grub2/grub.cfg’. If you haven’t already you want to try each suggestion separately.

For instance instead of:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=ef4c277c-c1f3-4c64-921b-8ae720676e34 logo.nologo acpi_osi=Linux acpi_osi='!Windows 2012' acpi_backlight=vendor audit=0 rd.timeout=120 scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 rd.systemd.show_status=0 systemd.show_status=0 random.trust_cpu=1 radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1"


GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=ef4c277c-c1f3-4c64-921b-8ae720676e34 logo.nologo acpi_osi=Linux acpi_osi='!Windows 2012' acpi_backlight=vendor audit=0 rd.timeout=120 scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 rd.systemd.show_status=0 systemd.show_status=0 radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1"

If you haven’t already. If you have tried both individually then it probably is time for a bug report.

We do appreciate you reporting this issue and regret any inconvenience you may have encountered.

OK this is for information and I hope I’m illuminating and not confusing. Also will matter if there is a bug report.

Linux multi-booting gets things a bit more complicated. If you look in directory ‘/boot/efi/EFI’ now you should see a folder for OpenMandriva and another folder for Ubuntu. Basically you’ll know by the graphics. If you are seeing Ubuntu graphics on grub2 menu page when you first boot then you are using the Ubuntu folder and files in Ubuntu which we can’t fix. Don’t worry this is very easy to work around. The only real point is that if you file a bug report we’ll need to get you using the ‘openmandriva’ file.

Edit: Also if we had the Ubuntu ‘grub.cfg’ and/or ‘/ect/default/grub’ to see what they are doing that might tell our devs where to look for cause and repair. Maybe, they do some things so different that it may or may not help.

  • I tried separately only 1 of the options
  • I haveonly Mandriva folder into EFI directory
  • Sorry, deleting Ubuntu now, installing Mint… the GRUB is almost the same, so after the install I will calmly check again tomorrow the behavior from Mandriva

Thanks A LOT for your help, cheers, I will update the thread as soon as I have checked with patience.

1 Like

No worries whatsoever. And thanks for your patience and willingness to work towards a solution which will help OM Lx be better.

I’m doing best I can to help but I’m a user myself and this problem is going to need developers involved. I’m pretty darn sure of that. And we will get that help, sometimes it takes time, but we’ll get it.

Don’ worry, it is not a big problem anyway, I can use the OS. BTW I installed Mint just now and checked what will GRUB try to do when I chose Mandriva, here is the “Grub Customizer” code if has some use for you people, going to reboot later with Mandriva few times and test again but right now I am trying to finish Mint useful.

insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  32f789ee-6536-4a88-bd13-d7bb3792e86d
  search --no-floppy --fs-uuid --set=root 32f789ee-6536-4a88-bd13-d7bb3792e86d
linux /boot/vmlinuz-5.1.21-desktop-1omv4000 root=UUID=32f789ee-6536-4a88-bd13-d7bb3792e86d ro quiet splash resume=UUID=ef4c277c-c1f3-4c64-921b-8ae720676e34 logo.nologo acpi_osi=Linux acpi_osi='!Windows 2012' acpi_backlight=vendor audit=0 rd.timeout=120 scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 rd.systemd.show_status=0 systemd.show_status=0 random.trust_cpu=1 radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1
initrd /boot/initrd-5.1.21-desktop-1omv4000.img

And about making Mandriva better I must say I still have and am using the wallpapers and loading screens from 2001 lol, I am really happy Mandiva is still alive, since I was a standard user never heard again except from Mageia, so as much as I can to report a bug or something I will do it for sure.

Little Update, tried to boot 3 more times, 1 was instantly (I thought again it was fixed and screamed of happiness, then the next 2 the black screen again BUT didn’t last really long, like took 20 seconds and showed the Graphic Login Screen, will keep rebooting later.

Tested several times, seems to be working better I think… random delay sometimes but at least I felt better until I screwed it and changed the Login Screen, now I can’t startx… stupid “Simple” login screen manager I installed from the menu.

How can I from Console change the Login Screen Manager? Since I can log in and access the console but not startx to the graphic interface.

Link to screenshot

Link to theme

There, I get the console at least to try something but I am kind of lost, maybe the login theme wasn’t compatible since it is the only thing I can think about, and that is the one but downloaded from the preferences by Mandriva Panel, NOT the web itself, so at leat wasn’t 100% my fault this time /heh

Sorry, this is because I didn’t want to modify stuff but never thought a simple install login manager from the preferences itself would brake this now.

startx /usr/bin/startkde

Thanks for the reply, giving me the same:

(Sorry, I can’t post pictures or links so I put them in code)

BTW I can enter to Mandriva partition via LinuxMint (Thank god I finished installing and configuring it) so if I need to check folders or modify files I think I could maybe do it from the Mint GUI)

Sorry for not being of any help :unamused:

It’s perfectly ok.

BTW try now, or next time you need to.

1 Like

Don’t worry, it is not fault, I feel terrible tho but I know someone will tell me to remove or modify some file to fix it (I hope =S )

I found many possible solutions but they are for Ubuntu and the folders/files doesn’t match, I don’t want to screw it even further, I am gonna sleep soonish, so I will check tomorrow, thanks a lot to all of you for your patience and help.<3

1 Like

Uhm wait… it’s a sddm-theme not a different login manager (different from sddm I mean).
Postedit: ^^^ that’s my fault: read too quickly and misundestood =)

Then try
sudo nano /etc/sddm.conf

guess the line to edit is

Current=breeze <---

Here it is line #11

Not sure of the steps you did in order to install the new theme, but I think you’ll have to revert all of them if possible.

1 Like

Hind sight is 20/20. But when you see an error like an an xauth error that should be first thing you mention. Error messages are generated to tell us what is wrong.

Hint: You basically copy and paste the error message to a search bar and do internet search. Sometimes you need to preface the error with the word Linux.

First you can try to delete in /home/uname all .serverauth and .Xauthority files and reboot. Don’t worry these are files created (if needed) when you boot.

It that works great if not you could try to edit the file ‘/usr/bin/startx’ and change the line (line 28):




and reboot. If those don’t work it is bug report time.

1 Like

Yay! Thanks a lot, so i basically started Ubuntu and navigated into the Mandriva partition to canghe the sddm.conf line from “simple” to “breeze” and now al is working, I even changed for an SDDM different later and it now realy worked as expected even with an old Mandiva 2001 walpaper.

Sorry but I thought SDDM is the Login Screen, isn’t it? You have GRUB2 to boot, then Plymouthg/Splash to loading the SO, then you see the Login Screen (where you also define the Desktop Enviroment to launch at login) and then the Loading Screen wich can be confusing with the Login Screen but are 2 different things.
Please correct me if I am mistaken !

About the orignal problem, seems to be KIND OF SOLVED since now it delays the Login Screen appearence like 20 seconds or so but shows up without me hitting BlockNum or other things as long as I tested al these later reboots.

I did nothing more after the previous fixes so if you want me to later to delete them and try again to check if that was the solution or no, or you need more info from Mint GRUB Config file tell me please and I will post it here.

I have other issues with different configuration stuff lbut I should open a new thread for it, right? Anyway I am going to search in google first.

Oh BTW thanks ben79, I did wha you suggest of searching last night but were afraid to delete files and screw it even more, also not all the solutions were the same and involved files/folders I didn’t have because were mainly based on Ubuntu and Gnome so I got lost.

Again thanks a lot guys! Cheers and have a nice day!

1 Like

@Shinusagi you mean this starting problem?

If so it probably an upstream issue with how systemd handles entropy (randomness) on boot.

If this is it then when boot stalls the first workaround is to create some entropy yourself by simply typing any random keys on kbd.

If that works then the next standard fix all over the internet is to add ‘random.trust_cpu=on’ to the line ‘GRUB_CMDLINE_LINUX_DEFAULT’ in ‘/etc/default/grub’ and then run as root the command ‘update-grub2’. I’ll post a screen-shot. But add that and only that. When you get multiple suggestions to a problem always try them one at the time not all at once. That last sentence is very important.

There are bug reports about this all over the internet. Some distros may have found workarounds that work for them whereas it seems OM has not yet. This is somewhat related to one’s CPU hardware also. (My Intel i5-4590 CPU seems vulnerable from time to time. This workaround seems to be working for me.)