[SOLVED] boot problem with Arch 2.4.3.0-1

atsol · 2019-09-24 06:45:22

I am running ArchLinux version 2.4.3.0-1 (I think this is the latest) on a Thinkpad lenovo X61.
Kernel is 5.2.14-arch2-1-ARCH

All was fine until I upgraded to this latest version. Now the laptop does not start GDM. It only reaches consoles.

However, what is strange is that if I edit the grub screen and remove the quiet parameter
everything works fine and GDM starts normally.

By the way in both cases there is an error "Failed to rotate log files" but I guess this is not important.

If no-one knows about this kind of bug, how can I permanently remove the quiet parameter so that I do not have to edit the grub screen at every boot?

Last edited by atsol (2019-10-28 18:36:58)

WorMzy · 2019-09-24 08:42:18

Arch doesn't have versions, I'm curious how you come by "2.4.3.0-1". How did you install Arch?

Please post a journal from a successful boot, and one from an unsuccessful boot. Use a pastebin to host them.

atsol · 2019-09-24 09:40:00

I installed it with the image arch provides, with dd to a USB stick, about a year ago. Of course it has versions. When it boots one of the messages is "booting version <number>" And this number has been changing during several pacman -Syu commands through out this year.

What is a journal? dmesg? Something else?

schard · 2019-09-24 09:41:35

This is the version of systemd and it's 243, release 1.
You'll get the relevant journal via

# journalctl -b

(# indicates to run this as root or at least as a member of systemd-journal)

Last edited by schard (2019-09-24 09:44:19)

Atari · 2019-09-24 09:49:14

atsol wrote:

If no-one knows about this kind of bug, how can I permanently remove the quiet parameter so that I do not have to edit the grub screen at every boot?

You can edit /etc/default/grub and remove the key `quiet' from GRUB_CMDLINE_LINUX_DEFAULT. IRC you'll also need to regenerate the config with grub-mkconfig -o /boot/grub/grub.cfg

atsol · 2019-09-24 14:23:34

OK, thanks. Here are the journals (sorry i do not know about pastebin)
boot-worked.txt

boot-failed.txt

The successful log is about double the size (in lines with wc -l) of the failed one. So they are different.

loqs · 2019-09-24 14:47:30

Sep 24 17:16:56 thinkpad gnome-shell[413]: Failed to open gpu '/dev/dri/card0': GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Operation not permitted

Possibly related to https://bbs.archlinux.org/viewtopic.php?id=249036

atsol · 2019-09-24 17:45:56

Maybe. Looks quite similar. But I do not see a solution in that link. In any case it seems that every time I edit the grub screen and remove the quiet parameter the system boots correctly. Something broke after the update to 243.0-1 systemd.

loqs · 2019-09-24 17:51:43

If you install and enable haveged does boot then work with the quiet option still present?
Edit:
If that fails try early KMS.

Last edited by loqs (2019-09-24 19:11:42)

atsol · 2019-09-29 14:25:49

I could not solve the problem otherwise, so I removed "quiet" from the configuration of grub. Now it works. Thanks a lot for the help.

2ManyDogs · 2019-09-29 14:31:13

Please remember to mark your thread [SOLVED] (edit the title of your first post).

loqs · 2019-09-29 14:39:02

Please consider bisecting systemd 2.4.2 to 2.4.3 or reporting the issue upstream as it appears to be an unintended change.

Last edited by loqs (2019-09-29 14:39:16)

atsol · 2019-10-01 15:43:46

2ManyDogs wrote:

Please remember to mark your thread [SOLVED] (edit the title of your first post).

Why do you say it is solved? It is not solved. It is bypassed. There is definitely some unidentified bug in systemd 243.0-1
I did not have this problem with the previous version. If I downgraded would you consider it solved?

This version has introduced bugs. For example, the lock screen does not work properly after suspend.
The session comes back from suspend as locked but no password window appears to type the password to unlock.

I will have to wait for the next version of systemd. Maybe it gets solved there.

atsol · 2019-10-10 05:09:24

More info: I did thought that it might be a hardware problem but it seems it is not. By deleting the quiet parameter eventually did not solve the problem. I discovered that the reason it was working so far was that I was entering the boot edit screen to delete "quiet" and then pressed F10 to boot. I was doing so to see the messages.

So the status is as follows: If I let the system boot on itself it will not reach GDM. Sometimes it will. Most times it will fail. The only messages I see on the boot screen is that the logrotate service fails, and when I press Alt+Control+Del to reboot, it will complain that watchdog0 did not stop (something crashes there).

But If I enter the grub edit screen (pressing e) and then F10 (without doing any change) it will ALWAYS
boot into GDM.

So what is the difference of booting on itself and booting after the user enters the grub edit screen?

V1del · 2019-10-10 07:49:18

Did you enable early KMS as linked by loqs already? This sounds precisely like the kind of issue caused and fixed by that.

Last edited by V1del (2019-10-10 07:49:34)

atsol · 2019-10-13 20:42:15

I do not understand. I did not do anything in purpose. The problem started after a pacman -Syu command as root.
Since this is a newbie corner can you please write what needs to be done?

V1del · 2019-10-13 21:06:50

https://bbs.archlinux.org/viewtopic.php … 6#p1865206 follow the linked instructions

atsol · 2019-10-28 08:32:39

Yes, problem solved with the early KMS. Thank you very much. But why should this be needed?

atsol · 2019-10-28 08:34:24

Now it can be marked as SOLVED. But how to do this?

V1del · 2019-10-28 08:44:45

Edit the subject line in your first post and prepend the [SOLVED] as for why this can be needed, on newer kernels/systemd it seems that the system might boot to a graphical target before the graphics hardware is actually ready. From what we know this is actually a regression in systemd 243 but it can be worked around by forcing the graphics driver to be loaded early. Apparently so far no one affected has decided to dig in and try to identify the regression, so you can either live with that workaround or try to actively identify the cause.

Arch Linux

#1 2019-09-24 06:45:22

[SOLVED] boot problem with Arch 2.4.3.0-1

#2 2019-09-24 08:42:18

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#3 2019-09-24 09:40:00

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#4 2019-09-24 09:41:35

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#5 2019-09-24 09:49:14

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#6 2019-09-24 14:23:34

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#7 2019-09-24 14:47:30

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#8 2019-09-24 17:45:56

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#9 2019-09-24 17:51:43

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#10 2019-09-29 14:25:49

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#11 2019-09-29 14:31:13

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#12 2019-09-29 14:39:02

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#13 2019-10-01 15:43:46

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#14 2019-10-10 05:09:24

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#15 2019-10-10 07:49:18

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#16 2019-10-13 20:42:15

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#17 2019-10-13 21:06:50

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#18 2019-10-28 08:32:39

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#19 2019-10-28 08:34:24

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

#20 2019-10-28 08:44:45

Re: [SOLVED] boot problem with Arch 2.4.3.0-1

Board footer