[Solved] Enabling GDM yields instant-crash due to overloadeded systemd

Syxal · 2023-06-12 18:42:00

PS, solution:
Make sure your journalctl actually works by checking if those three are systemctl enabled: "systemd-journald.socket", "systemd-journald-dev-log.socket" and "systemd-journald-audit.socket"

Adding "pcie_aspm=off" to the /etc/default/grub in the line "GRUB_CMDLINE_LINUX="here" fixes the issue, that is if the problem is PCIe corrected errors spam
Apparently, systemd is not very good at handling high frequency messages

Hiya folks,

I'm a neophyte to Archlinux, and Linux altogether actually. I installed Archlinux a first time on a virtual machine with the help of a friend, and then mostly by myself on my computer, using the Official Guide and noting commands in a text document because I don't understand everything yet, and it's easy to forget stuff. The installation runs fine, the partitions are good, drivers are ok and essential packages are installed (I'm not sure if the list is exhaustive, but here is what I can recall by head: iwd, dhcpcd, efibootmgr, grub, pbus, systemd, intel-ucode, nvidia, nvidia-utils, sudo)

I happen to run into an issue where "systemctl enable gdm" (gnome display manager) yields an instant-crash on startup.
Albeit, when it is disabled, I can run it manually and it launches fine, though it inexorably connects me as root

I have appended to the ~/.xinitrc file the manual Xorg sessions as shown in the Gnome wiki page at chapter 2.2.1, and I updated the grub boot file using the following command:

grub-mkconfig -o /boot/grub/grub.cfg

I have tried to unlink /etc/system/display-manager.service and enabling it again as shown here, thinking that perhaps the directory was broken. It hasn't solved the issue, unfortunately

I also tried remaking the initramfs by using the following command:

mkinitcpio -P

Maybe the root cause could be an erroneous boot order, where gdm starts before archlinux is actually fully booted.
I looked at this thread, although the file is a bit too cryptic to understand for my unknowledged brain

Honestly, I'm not sure where to look at anymore, I feel brain damages.

Does anyone have a clue to what is happening and/or what I may have done wrong? I'm not too familiar yet with acronyms, if you use them it would be lovely if you can postpend the retroacronyms please, for instance: DE (desktop environment)

Many thanks to whom have read through my thread-post and I wish thou a great day

Last edited by Syxal (2023-06-15 12:15:00)

jl2 · 2023-06-12 19:19:18

1. enable gdm
2 reboot
3 try changing to a different tty: ctrl+alt+f2. if it works skip to 6.
4 disable gdm
5 reboot
6 post the output of

journalctl -b gdm_failed_boot | curl -F 'file=@-' 0x0.st

replace gdm_failed_boot with a negativ number; 0 is the current boot, -1 last boot, -2 before last boot etc.

This is post-initramfs, so no need for mkinitcpio of grub-mkconfig. gdm does NOT get booted... it starts from within Arch.

does the whole system crash or is there only a freeze? I expect later.

Last edited by jl2 (2023-06-12 19:20:23)

Syxal · 2023-06-12 19:47:25

Hi JL2,

I thought so hard that I had developed more about the instant-crash, that I believed I did.
Unfortunately, I think it is a full crash as I am unable to change tty and the light of cap lock doesn't switch

journalctl -b gdm_failed_boot | curl -F 'file=@-' 0x0.st

Yields (the same happens with lower values)

Data from the specified boot (-1) is not available: No such boot ID in journal
451 Unavailable For Legal Reasons

I'm not sure but I think the journalctl doesn't actually start up. During the installation process, this error was getting printed regularly:

systemd[1]: Failed to start Journal Service

I looked at this comment of Antoine stating a solution, but despite my search in the wiki and forum, I don't actually quite understand it
I'm sorry, I didn't think this through, I should maybe have talked about this issue in the thread-post

JL2 wrote:

... it starts from within Arch.

Okay, I understand. Now that I know that, I see that it wouldn't make sense to remake the initramfs or rewrite grub-mkconfig. Thanks for explaining

Last edited by Syxal (2023-06-12 19:58:42)

jl2 · 2023-06-13 06:00:01

lets take a look t that, first.
post

systemctl status journald.service

you don't need to enable gdm.
Just for checking it isn't a graphics driver issue, try sddm (simple desktop display manager)

Last edited by jl2 (2023-06-13 06:08:09)

Syxal · 2023-06-13 10:04:43

SDDM seems to run fine, albeit not surprisingly because GDM also runs if launched manually
Though SDDM starts automatically well, where GDM would crash

Syxal wrote:

Albeit, when it is disabled, I can run it manually and it launches fine, though it inexorably connects me as root

Unfortunately, the command you indicated me yields the result:

Unit journald.service could not be found.

jl2 · 2023-06-13 10:15:22

try

pacman -Syu systemd
ls /{etc,usr/lib}/systemd/system/systemd-journald.service
pacman -Qo /{usr/lib,etc}/systemd/system/systemd-journald.service

Last edited by jl2 (2023-06-13 10:46:22)

Syxal · 2023-06-13 11:47:42

I looked at the link there was on your reply,
I updated systemd as you told me to, about 20 megabytes of installation were added

This command

ls /{usr/lib,etc}/systemd/system/systemd

yields

ls: cannot access '/usr/lib/systemd/system/systemd': No such file or directory
ls: cannot access '/etc/systemd/system/systemd': No such file or directory

and this one

pacman -Qo /{usr/lib,etc}/systemd/system/

returns a whole list of

/usr/lib/systemd/system/ is owned by [insert name]

and this

/etc/systemd/system/ is owned by systemd 253.5-1

Though this one

pacman -Qo /{usr/lib,etc}/systemd/system/{systemd,journald}

returns

erorr: No package owns /usr/lib/systemd/system/systemd
erorr: No package owns /usr/lib/systemd/system/journald
erorr: No package owns /etc/systemd/system/systemd
erorr: No package owns /etc/systemd/system/journald

which corroborates with the ls command yielding an absence of file or directory

I'm not too sure what to do with those informations, maybe I have to create the file/directory myself?

If I do journalctl I get this output in perpetual repetition

[Month] [Date] [hh:mm:ss] syxal systemd-journald[1558] Missed [number] Kernel messages
[Month] [Date] [hh:mm:ss] syxal kernel: pcieport 0000:00:1c.6:    device [8086:a116] error status/mask=00000001/00002000
[Month] [Date] [hh:mm:ss] syxal systemd-journald[1558] Missed [number between 30 & 350'000] Kernel messages
[Month] [Date] [hh:mm:ss] syxal kernel: pcieport 0000:00:1c.6: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)

I think I'm missing something obvious here, but I can't pinpoint what

jl2 · 2023-06-13 13:29:05

you managed to type it wrong every time.
lets stay with this one:

pacman -Qo /{usr/lib,etc}/systemd/system/systemd-journald.service

don't write something with

{systemd,journald}

Last edited by jl2 (2023-06-13 13:40:47)

Syxal · 2023-06-13 15:34:23

pacman -Qo /{usr/lib,etc}/systemd/system/systemd-journald.service

returns

/usr/lib/systemd/system/systemd-journald.service is owned by systemd 253.5-1
error: No package owns /etc/systemd/system/systemd-journald.service

I took the liberty to redo this one but correctly:

ls /{etc,usr/lib}/systemd/system/systemd-journald.service

returns

ls: cannot access '/etc/systemd/system/systemd-journald.service': No such file or directory
/usr/lib/systemd/system/systemd-journald.service

seth · 2023-06-13 16:02:37

systemctl status systemd-journald.service

and post every file that shows up w/

ls /etc/systemd/journald.conf*

Also, since SDDM works, GDM likely crashes and leaves a coredump, https://wiki.archlinux.org/title/Core_d … _core_dump
=> Post that.

Edit, just to be sure, you did not *literally* issue "journalctl -b gdm_failed_boot", did you? But you replaced gdm_failed_boot w/ a number?

Last edited by seth (2023-06-13 16:04:00)

Syxal · 2023-06-13 17:20:44

Hi Seth,

Systemctl:

systemctl status systemd-journald.service

outputs:

 systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: activating (start) since Tue 2023-06-13 16:04:12 UTC; 54s ago
TriggeredBy: ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
             ○ systemd-journald-audit.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 2287 (systemd-journal)
      Tasks: 2 (limit: 19075)
     Memory: 194.0M
        CPU: 52.170s
     CGroup: /system.slice/systemd-journald.service
             └─2287 /usr/lib/systemd/systemd-journald

I went and did "systemctl enable systemd-journald-audit.socket" and the same but substituting "enable" with "start"
To test if now the journalctl works, I grepped gnome-shell and got this as the result:

-- Boot 8c23c7a6b1bb48b2b81caa0486b8b35c --
-- Boot ba7d3a1694c248698cc75977e91db6c5 --

I think but I'm not sure that journalctl is fixed, I will try to get the crash log in the third section
PS: After recreating a crash and redoing the command shown in the third section, it loads nothing (I tried 0, -1 and -2), even after a few minutes. Though I guess it's somewhat an amelioration? The error "451 Unavailable for Legal Reasons" is no longer outputed

Core dump:
I went on the link, did "coredumpctl list" and got "No coredumps found.". I looked a bit higher and downloaded gdb package as stated, purposely crashed my instance by enabling gdm and rebooting (went through arch-chroot to disable it again), still no core dump, so I executed "pgrep -f gdm" and.. still no core dump
I went into "(gdb) bt" and found nothing either
I looked with "ls /var/lib/systemd/coredump/ and found all of this stuff: (I have shifted with 5 "-" the two lines that are interesting)

core.Discord.0.2f4255be05c54e38b205810f8832c5d2.1737.1686508630000000.zst
core.Discord.0.2f4255be05c54e38b205810f8832c5d2.1806.1686508718000000.zst
core.Discord.0.736c7258454b4074b4523a22c99eb532.7837.1686441139000000.zst
core.Discord.0.736c7258454b4074b4523a22c99eb532.7846.1686441155000000.zst
core.Discord.0.736c7258454b4074b4523a22c99eb532.7887.1686441189000000.zst
core.Discord.0.736c7258454b4074b4523a22c99eb532.8129.1686441347000000.zst
core.Discord.0.736c7258454b4074b4523a22c99eb532.8159.1686441364000000.zst
core.Discord.0.736c7258454b4074b4523a22c99eb532.8526.1686441637000000.zst
core.Discord.0.cbf4bc7ef28e403b881c870a2f4ffe81.1363.1686506290000000.zst
core.epiphany.0.280f154ee8c340b1bbb5deef1c4fa7d6.1231.1686521424000000.zst
core.epiphany.0.736c7258454b4074b4523a22c99eb532.8193.1686441518000000.zst
core.epiphany.0.9f3bd50af6c6495b8a2c7e72c9fd28b3.1376.1686587695000000.zst
core.epiphany.0.9f3bd50af6c6495b8a2c7e72c9fd28b3.1659.1686587700000000.zst
core.epiphany.0.9f3bd50af6c6495b8a2c7e72c9fd28b3.1731.1686587703000000.zst
core.epiphany.0.9f3bd50af6c6495b8a2c7e72c9fd28b3.1803.1686587706000000.zst
----- core.gnome-shell.0.9f3bd50af6c6495b8a2c7e72c9fd28b3.666.1686590041000000.zst
----- core.gnome-shell.1000.11b64041e3e048c08167b344bbf96dc9.791.1686650723000000.zst
core.systemd-journal.0.03b00cfaca994d2fa339ef44bb8bbe17.234.1686610929000000.zst
core.systemd-journal.0.07acc68eb6714144a5406ffc7868d595.254.1686444060000000.zst
core.systemd-journal.0.11b64041e3e048c08167b344bbf96dc9.238.1686650378000000.zst
core.systemd-journal.0.1f794a2e5e2141388f51caf438d7047e.244.1686489167000000.zst
core.systemd-journal.0.280f154ee8c340b1bbb5deef1c4fa7d6.241.1686520647000000.zst
core.systemd-journal.0.292431ef778343858bb5f4b4b8ec7731.226.1686656129000000.zst
core.systemd-journal.0.2f4255be05c54e38b205810f8832c5d2.244.1686507888000000.zst
core.systemd-journal.0.406a2f43316c49fd8981e2b58bb480bc.242.1686486880000000.zst
core.systemd-journal.0.4ece728785b8454b8a59ad47d4f2a0d0.236.1686483391000000.zst
core.systemd-journal.0.641acbd8ee614ba9a8b301579f3bbde9.229.1686490080000000.zst
core.systemd-journal.0.6756917304e6405da7ddb69e3565e56e.229.1686673206000000.zst
core.systemd-journal.0.6ce7688eea134a67b6d1f3356707ebe0.241.1686436686000000.zst
core.systemd-journal.0.736c7258454b4074b4523a22c99eb532.253.1686440586000000.zst
core.systemd-journal.0.75fbb2fd37114166a66286761110ea39.242.1686669393000000.zst
core.systemd-journal.0.7b8b7ced67074bfeab4e72466cec6e39.239.1686651007000000.zst
core.systemd-journal.0.7c93cc207ed941b084d99fc8dcd4c2c9.229.1686583183000000.zst
core.systemd-journal.0.7e4bc89874d14c669382e24eaa33ef1d.237.1686611708000000.zst
core.systemd-journal.0.9c891910e461452889f964a616d20bed.247.1686484648000000.zst
core.systemd-journal.0.9f3bd50af6c6495b8a2c7e72c9fd28b3.242.1686587509000000.zst
core.systemd-journal.0.a7a973cd8d2f4d0aa5f86c6b5e746b25.256.1686491225000000.zst
core.systemd-journal.0.ad6b8aaf93054fb3b4d01fbd3f9249da.235.1686655118000000.zst
core.systemd-journal.0.ade6abae1a934517a9c90713225c24aa.252.1686485863000000.zst
core.systemd-journal.0.afe13fb7507b471b969bbd0d8fabfc6d.238.1686565343000000.zst
core.systemd-journal.0.cbf4bc7ef28e403b881c870a2f4ffe81.229.1686505836000000.zst
core.systemd-journal.0.d7cf5210ffd44e97b876ef5ef72d6b16.243.1686433518000000.zst
core.systemd-journal.0.dbb0f9968f504570ab136a45f1a670e4.238.1686649955000000.zst
core.systemd-journal.0.ec763bd0086a4ac5acb719c3be8db6a1.240.1686670137000000.zst
core.systemd-journal.0.ecc6f174e75e467cad92001a06eca237.239.1686434645000000.zst
core.systemd-journal.0.fb5e2b7e35f14d229d3b6db947b6043e.236.1686651254000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.10170.1686513668000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.10197.1686513619000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.12511.1686515087000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.13431.1686515172000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.3810.1686509951000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.4096.1686510010000000.zst
core.WebKitWebProces.0.2f4255be05c54e38b205810f8832c5d2.9788.1686513102000000.zst

Doing "pgrep gnome-shell" gives "672", "727", "866" and "993", I randomly picked one of them which is "727" and issued the command "gdb -p 727", "generate-core-file"

Attaching to process 727
[New LWP 748]
[New LWP 749]
[New LWP 751]
[New LWP 754]
[New LWP 755]
[New LWP 826]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f0d22506c0f in poll () from /usr/lib/libc.so.6
(gdb) generate-core-file
warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000.
Saved corefile core.727
(gdb) bt
#0  0x00007f0d22506c0f in poll () at /usr/lib/libc.so.6
#1  0x00007f0d22909a9f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f0d228abf3f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x000056210c8022f8 in main ()
A debugging session is active.

	Inferior 1 [process 727] will be detached.

Quit anyway? (y or n) Quit

I can't quit without the coredump detaching, and in the help menu I can't find a save or write command. It renders the coredump creation useless as I cannot execute "coredumpctl list" or "info 727"

journalctl
Nah I haven't literally issued "journalctl -b gdm_failed_boot | curl -F 'file=@-' 0x0.st ", I substituted the red text by 0, -1 & -2

Last edited by Syxal (2023-06-13 17:21:39)

seth · 2023-06-13 19:38:28

PS: After recreating a crash and redoing the command shown in the third section, it loads nothing (I tried 0, -1 and -2), even after a few minutes. Though I guess it's somewhat an amelioration? The error "451 Unavailable for Legal Reasons" is no longer outputed

You're supposed to get a URL from that command.

Does

sudo journalctl -b

print anything atm?
If so, try to start GDM and post the journal, "somehow" (you can redirect it into a file "sudo journalctl -b > /tmp/journal.txt")

The amount of "systemd-journal" entries in /var/lib/systemd/coredump/ suggest that there's something massively fucked up about the system, but we'll need some data on the situation.
While at it:

sudo LC_ALL=C pacman -Qkk | grep -v ', 0 altered files' | curl -F 'f:1=<-' ix.io

Syxal · 2023-06-13 20:22:14

Unfortunately, this command

journalctl -b

still prints this in perpetual repetition:

[Month] [Date] [hh:mm:ss] syxal systemd-journald[1558] Missed [number] Kernel messages
[Month] [Date] [hh:mm:ss] syxal kernel: pcieport 0000:00:1c.6:    device [8086:a116] error status/mask=00000001/00002000
[Month] [Date] [hh:mm:ss] syxal systemd-journald[1558] Missed [number between 30 & 350'000] Kernel messages
[Month] [Date] [hh:mm:ss] syxal kernel: pcieport 0000:00:1c.6: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)

And in this case, I'm not persuaded of how useful is redirecting my beloved Kernel's missed messages errors into another directory

I can try to re-install Arch-linux, I have nothing important on it. Although, I have to be certain to what I have done wrong, otherwisely I will end up with the same error and that would not be constructive
I think that maybe I should have done the systemctl chapter stated my previous reply, albeit, during the installation. Does this sound like a possible causality to why journalctl is still messed up?

Important PS: I thought that the command

sudo LC_ALL=C pacman -Qkk | grep -v ', 0 altered files' | curl -F 'f:1=<-' ix.io

didn't do anything, but actually got this in the console whist I wasn't looking: http://ix.io/4yao

I will try the other command again and hope it eventually gets me a link

Spoiler: It didn't. And even better, the ghastling and dreaded error 451 is back, to haunt me. I have no clue how it came back

Last edited by Syxal (2023-06-13 20:29:44)

seth · 2023-06-13 20:29:25

Do you get any errors in "sudo dmesg"?

Assuming the device on 0000:00:1c.6 is the cuplrit

lspci -nn

otherwisely I will end up with the same error and that would not be constructive

It's good (and rare) to hear that someone (you) understood that part

Syxal · 2023-06-13 20:32:53

"sudo dmesg" prints those three lines repeatedly:

[12246.563110] pcieport 0000:00:1c.6:   device [8086:a116] error status/mask=00000001/00002000
[12246.563128] pcieport 0000:00:1c.6: AER: can't find device of ID00e6
[12246.563133] pcieport 0000:00:1c.6: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)

lspci -nn

gives

00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:191f] (rev 07)
00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07)
00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31)
00:16.0 Communication controller [0780]: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31)
00:17.0 RAID bus controller [0104]: Intel Corporation SATA Controller [RAID mode] [8086:2822] (rev 31)
00:1c.0 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #5 [8086:a114] (rev f1)
00:1c.6 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #7 [8086:a116] (rev f1)
00:1d.0 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #9 [8086:a118] (rev f1)
00:1f.0 ISA bridge [0601]: Intel Corporation H170 Chipset LPC/eSPI Controller [8086:a144] (rev 31)
00:1f.2 Memory controller [0580]: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller [8086:a121] (rev 31)
00:1f.3 Audio device [0403]: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller [8086:a170] (rev 31)
00:1f.4 SMBus [0c05]: Intel Corporation 100 Series/C230 Series Chipset Family SMBus [8086:a123] (rev 31)
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-V [8086:15b8] (rev 31)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1)
02:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller [1b21:1242]
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8821AE 802.11ac PCIe Wireless Network Adapter [10ec:8821]

Funnily enough there is a Xeon driver when.. I don't have an Intel Xeon CPU

Last edited by Syxal (2023-06-13 20:38:51)

seth · 2023-06-13 20:54:01

There're no drivers in that output, that's your host bridge.
However, the device that keeps acting up is

00:1c.6 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #7 [8086:a116] (rev f1)

Since the errors are corrected, let's first silence the system and see whether you get a more useful behavior.
Pass "pci=noaer" to the kernel commandline, https://wiki.archlinux.org/title/Kernel_parameters

Edit: google points towards your storage drive (SSD?)
You can try "pcie_aspm=off" instead of "pci=noaer" (the latter only suppresses the message)

What kind of drive do you have?
SSD? nvme? M.2?

Last edited by seth (2023-06-13 21:01:01)

Syxal · 2023-06-14 00:16:31

So I went into the boot menu and executed the command "pcie_aspm=off", I made it permanent by writing it in /etc/default/grub
Now "journalctl -d" is far more interesting, a bunch of lines that looks overwhelmingly normal, so I don't think any of the showed elements are relevant here
I've tried again to get the core dumps, without any luck

Although, I got great news: the command afore mentioned by JL2 for the crash-log now works. I think this Crash-log shows a startup where gdm is enabled. I don't quite understand why the crash log still has the looping PCIe messages, when they're proving a complete absenteism in the "journalctl -b"
In all honesty, I haven't took a deep look into it yet, I'm a bit tired. I'll read it tomorrow for sure

My archlinux is on a HDD (I absolutely adore HDD noises [I don't])

seth · 2023-06-14 06:40:54

I made it permanent by writing it in /etc/default/grub

Editing /etc/default/grub in and by itself does nothing, you'll have to run grub-mkconfig again, https://wiki.archlinux.org/title/GRUB#G … d_grub.cfg

Warning: http://0x0.st/HckM.txt is 24MB

I don't quite understand why the crash log still has the looping PCIe messages, when they're proving a complete absenteism in the "journalctl -b"

Because it's from the previous boot, before you disabled aspm

Jun 13 23:27:28 syxal kernel: ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
Jun 13 23:27:28 syxal kernel: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
Jun 13 23:27:28 syxal kernel: acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
Jun 13 23:27:28 syxal kernel: pci 0000:00:01.0: ASPM: current common clock configuration is inconsistent, reconfiguring

There's no nvme, but
* TOSHIBA DT01ACA1 A7L0 (hdd)
* HFS128G32MND-2200A (ssd)
* HL-DT-ST DVDRAM GUC0N (dvd)

Is there a disc in the optical drive?

Does GDM now work as expected?
It seems systemd simply got knocked out by the onslaught of AERs (journald isn't very good and sucks at handling high frequency messages, I figured that when a bug in a printer config knocked one of my systems out … errrr, can't be /that/ long ago. I'm still young!

Syxal · 2023-06-14 10:55:43

I overlooked the grub-mkconfig step, kinda inattentive of me considering the kernel page reminded me of it

About the link, is it forbidden to post links to pages like this one that contains logs/long texts, or is exceeding a certain weight prohibited? I have read the rules again but I can't find the section, I don't want to make the same mistake again though

Now my Arch launches with gdm enabled, insane. Thank you very much Seth & JL2 for your precious help and time. I would have never figured that the system doesn't know what to do with being too wealthy of errors, I find it quite weird and unsettling

I'll edit the title to be more accurate to the issue, mark it as solved and edit my first post to TLDR the solution, so people looking for it don't have to go through the whole thread

Edit: Does the title look right?

Last edited by Syxal (2023-06-14 11:04:25)

seth · 2023-06-14 12:52:04

About the link

Everything's fine w/ that, just that browsers tend to suck w/ displaying files this large, so I warned others who might want to click that.

The title is maybe slightly inaccurate (GDM will fail because it heavily relies on systemd and for all we know ultimately systemd-journald went down under the message pressure), but that's fine.

Journald always had this problem, you'll likely also have experienced high CPU usage.
It's possible to forward the messages to rsyslog or syslog-ng which should do much better w/ such extreme situations, but "as long as there's no problem, systemd works fine"

Arch Linux

#1 2023-06-12 18:42:00

[Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#2 2023-06-12 19:19:18

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#3 2023-06-12 19:47:25

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#4 2023-06-13 06:00:01

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#5 2023-06-13 10:04:43

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#6 2023-06-13 10:15:22

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#7 2023-06-13 11:47:42

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#8 2023-06-13 13:29:05

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#9 2023-06-13 15:34:23

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#10 2023-06-13 16:02:37

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#11 2023-06-13 17:20:44

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#12 2023-06-13 19:38:28

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#13 2023-06-13 20:22:14

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#14 2023-06-13 20:29:25

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#15 2023-06-13 20:32:53

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#16 2023-06-13 20:54:01

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#17 2023-06-14 00:16:31

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#18 2023-06-14 06:40:54

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#19 2023-06-14 10:55:43

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

#20 2023-06-14 12:52:04

Re: [Solved] Enabling GDM yields instant-crash due to overloadeded systemd

Board footer