[SOLVED] My KDE/x-server refuses to start automatically

mean_booty · 2019-10-29 02:49:33

I was looking at xorg logs because I couldn't get xserver to start with KDE. I found out a few fonts and xterm were not installed. I installed all of them and rebooted, and I successfully booted and it auto logged in sddm to get to the kde desktop (I already have steam and games installed as I did a complete Xorg/KDE reinstall because of this same problem.

my .xinitrc only contains "exec startplasma-x11" which was made AFTER the successful boot.

Now, the system boot gets stuck and I have to alt+F2 to get into the TTY and then I can startx and KDE works perfectly past that.

Here is the journalctl log of the full boot, but I can't find where the actual problem is:

https://pastebin.com/nuz94VaU

Does anyone know what this could be caused from?

Thank you!

Last edited by mean_booty (2019-11-01 11:52:38)

Lone_Wolf · 2019-10-29 11:45:12

Are you using early KMS for amdgpu kernel module ?

Some things that stand out[1]

-----

Oct 28 21:09:42 Lappland kernel: too many entries; ignoring [mem 0xda462000-0xda464fff]
Oct 28 21:09:42 Lappland kernel: too many entries; ignoring [mem 0xda465000-0xda467fff]
<many similar lines>

consider removing add_efi_memmap from command line[2]

-----

Oct 28 21:09:44 Lappland mtp-probe[575]: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-2"
Oct 28 21:09:44 Lappland mtp-probe[578]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-1"
Oct 28 21:09:44 Lappland mtp-probe[576]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6"
Oct 28 21:09:44 Lappland mtp-probe[577]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-5"
Oct 28 21:09:44 Lappland mtp-probe[575]: bus: 1, device: 3 was not an MTP device
Oct 28 21:09:44 Lappland mtp-probe[578]: bus: 1, device: 2 was not an MTP device
Oct 28 21:09:44 Lappland mtp-probe[577]: bus: 1, device: 4 was not an MTP device
Oct 28 21:09:44 Lappland mtp-probe[576]: bus: 1, device: 5 was not an MTP device

I've seen these messages before and they usually have nothing to do with mtp-probe but indicated some usb devices don't work well together.
In one case a new keyboard with an older mouse from the same brand very often got the mouse stuck.
With a keyboard of another brand the mouse worked fine.
Putting them on different usb controllers also solved the problem.

----

Oct 28 21:09:42 Lappland systemd-random-seed[391]: Kernel entropy pool is not initialized yet, waiting until it is.

https://wiki.archlinux.org/index.php/Ra … generation
This may also be caused by a bug in microcode of some recent processors.

Are you using latest firmware foir your motherboard ?
Do you have microcode early loading enabled ?

-----

my .xinitrc only contains "exec startplasma-x11

that's tooo minimal, see https://wiki.archlinux.org/index.php/Xinit

[1] These may or may not be related to the boot issue, but should be looked at to reduce the chance of future problems.

[2] https://unix.stackexchange.com/question … oot#254538

Last edited by Lone_Wolf (2019-10-29 11:47:10)

mean_booty · 2019-10-29 12:52:00

Thank you for the detailed reply!

I did not have have amd-microcode, so I installed it and attempted to load it, but ended up getting kernal panic, so that was probably not the way to go. If I disable "add_efi_memmmap" the entire boot hangs and I have to hard restart.

Also I found a very weird thing. If I boot into "single user mode" everything loads just fine after hitting the "Ctrl+D" to continue while with the exact same options, standard boot doesn't. I tried all of this with this this xinitrc:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then







    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then







    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

twm &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
#exec xterm -geometry 80x66+0+0 -name login
exec startplasma-x11

V1del · 2019-10-29 13:13:53

Comment the twm line as well, all of this points to the race condition issue. You did not mention anything in regards to enabling early KMS as pointed out in the first sentence of lone_wolf's reply, nor what you did to resolve the entropy issue, both of which are commonly associated with the issues you are seeing and both of which lone_wolf provided links to further information for

Last edited by V1del (2019-10-29 13:14:24)

mean_booty · 2019-10-29 13:46:04

I will try that when I have access to my system again tonight.

I did test the early microcode loading which is what gave me kernal panic, and my motherboard bios (MSI B450I Gaming Plus AC) is loaded with the latest bios running a Ryzen 3600X.

I also did enable the earlyKMS for amgpu by means of modifying no entry for modules to:

 MODULES=(amdgpu)

as the only early loading module in my mkinitcpio.conf. This did not seem to fix the problem.

For the USB issue, I have had ko problems with any USB device besides automounting USB drives in KDE, so I'm not sure if that is an issue. Maybe I am understanding where the issue comes into play incorrectly. He mentioned that it can cause USB devices to not play well together but I have not experienced this.

As far as the entropy issue, I'm not sure I understand steps to take well from the wiki page. It says "do ensure that /dev/urandom is initialized properly" but doesn't give a link on how to do so. Maybe I am just missing something crucial. Is calling getrandom() just the way to do this?

In my additional testing quick before I went to work, I found out that trying to manually launch sddm via the "sddm" command left me with an error, I can debug that later tonight if it could be the issue worth pursuing.

Edit:

I actually came across this article on my Google fees:
https://arstechnica.com/gadgets/2019/10 … y-weekend/ this may be the bug that is causing the random number problem, but I don't know if I can fix it or if it. However, since I can boot with single user, I don't think it is. I may check later.

Last edited by mean_booty (2019-10-29 20:28:33)

mean_booty · 2019-10-30 03:02:28

Commenting out twm helped for 1 boot then it stopped working again. I'm not sure what that is about. So it is back to being the same behavior with nothing changed from one boot to another.
.

Lone_Wolf · 2019-10-30 11:34:17

for now, add systemd.unit=multi-user.target as kernel parameter.
That will boot to console mode and ensure X won't be started until you explicitly order it.

mean_booty · 2019-10-30 13:15:03

I actually had one successful boot before failure. Do you think the dmesg or journalctl from those boots could be a useful comparison to see where things went wrong?

Right off the bat I noticed that sddm was successfully initialized in the good boot where it was called but just killed in the bad boot.

loqs · 2019-10-30 13:34:29

To test if it is a lack of entropy add the boot parameter random.trust_cpu=on.
How exactly did you add microcode that resulted in a kernel panic?

mean_booty · 2019-10-30 14:28:50

I will test when I get home, but I added

 initrd=/amd-ucode.img

to my line in my refind.conf in the standard boot line. I did this because /boot is it's own separate partition, so the /boot/amd-ucode.img path wouldn't find the file. It was also the first initrd entry.

WorMzy · 2019-10-30 15:20:04

Mod note: Not a multimedia/games issue, moving to NC.

mean_booty · 2019-10-31 02:23:34

That random trust command fixes the error with entropy I believe.

So I have been looking at boot up files and these pages:

https://wiki.archlinux.org/index.php/Xi … X_at_login

https://wiki.archlinux.org/index.php/KD … ing_Plasma

https://wiki.archlinux.org/index.php/Xo … _GUI_login

I tried all of these techniques and nothing was able to get it to boot fully.

Lone_Wolf · 2019-10-31 12:14:55

initrd=/amd-ucode.img
to my line in my refind.conf in the standard boot line. I did this because /boot is it's own separate partition, so the /boot/amd-ucode.img path wouldn't find the file.

Your reasoning is wrong, the error lies somewhere else.

post (as root)

# lsblk -f
# fdisk -l

Also your refind.conf and /etc/fstab .
That should give us an idea how you setup your partitions.

Apart from that please stop trying to start X automatically .

Your first goal should be to get your system to boot to console multi-user.target succesfully EVERY time.
Second goal is to get x to start manually successfully every time.

You should only look at automatic starting of X AFTER reaching those two goals.

mean_booty · 2019-10-31 13:29:49

Oh don't get me wrong, if I completely remove Xorg and KDE/Sddm, the system boots perfectly to console every time. I actually did that in my debugging before posting.

It is only once I install Xorg, sddm, and KDE that everything stops booting correctly. It is for sure an Xorg/sddm/KDE issue.

I even just got a good boot by activating "disable Xorg server shortcut" in KDE's input menu. But the following boot was broken again. I grabbed the journalctl logs from those two boots but didn't have time to upload it.

I will post my partition scheme, fstab, and other required configs when I return.

V1del · 2019-10-31 13:39:38

All of this still points to the race, after changing mkinitcpio.conf, did you actually rebuild your initramfs with

mkinitcpio -p linux

? Can you post a /var/log/Xorg.0.log log from a "failing" boot? If it's the issue I'm thinking of xorg should actually attempt to start but fail with a permissions error on drmSet

mean_booty · 2019-11-01 11:52:11

Wow, I really thought I had already remade the mkinicpio but apparently I missed that. with the amdgpu preload it works. Thanks everyone for bearing through my stupidity.

Arch Linux

#1 2019-10-29 02:49:33

[SOLVED] My KDE/x-server refuses to start automatically

#2 2019-10-29 11:45:12

Re: [SOLVED] My KDE/x-server refuses to start automatically

#3 2019-10-29 12:52:00

Re: [SOLVED] My KDE/x-server refuses to start automatically

#4 2019-10-29 13:13:53

Re: [SOLVED] My KDE/x-server refuses to start automatically

#5 2019-10-29 13:46:04

Re: [SOLVED] My KDE/x-server refuses to start automatically

#6 2019-10-30 03:02:28

Re: [SOLVED] My KDE/x-server refuses to start automatically

#7 2019-10-30 11:34:17

Re: [SOLVED] My KDE/x-server refuses to start automatically

#8 2019-10-30 13:15:03

Re: [SOLVED] My KDE/x-server refuses to start automatically

#9 2019-10-30 13:34:29

Re: [SOLVED] My KDE/x-server refuses to start automatically

#10 2019-10-30 14:28:50

Re: [SOLVED] My KDE/x-server refuses to start automatically

#11 2019-10-30 15:20:04

Re: [SOLVED] My KDE/x-server refuses to start automatically

#12 2019-10-31 02:23:34

Re: [SOLVED] My KDE/x-server refuses to start automatically

#13 2019-10-31 12:14:55

Re: [SOLVED] My KDE/x-server refuses to start automatically

#14 2019-10-31 13:29:49

Re: [SOLVED] My KDE/x-server refuses to start automatically

#15 2019-10-31 13:39:38

Re: [SOLVED] My KDE/x-server refuses to start automatically

#16 2019-11-01 11:52:11

Re: [SOLVED] My KDE/x-server refuses to start automatically

Board footer