[SOLVED] With a second monitor plugged in, boot sequence stalls

liglog · 2024-10-13 21:20:49

This stall during boot issue caused many days of frustration for me before I found a workaround. I don't have a solution.

A workaround is this: unplug the secondary monitor from the video card. My system will then continue to boot from the point at which it stalled.

My primary monitor will then not be filled by the TTY. There will be an unused strip (sometimes containing garbled nonsense) along the right and the bottom of the monitor screen. The second monitor will be black. I can log in and startx but at least one strip persists in the X desktop environment.

If I boot with just the primary monitor plugged in to the video card, the system boots normally. The log prompt appears (i don't have a greeter installed), I log in, run startx, and my desktop environment comes up as normal (X/i3/picom). I now plug the second monitor back in, log out (back to tty), run startx again, and both monitors work as expected in the desktop environment.

My primary purpose in posting is to help someone else who is stuck at boot avoid frustration and loss of time investigating other potential causes while their system is unusable. Try unplugging the secondary monitor. It is quick and easy to test.

A secondary reason for the post is maybe someone can explain what causes this condition and whether it can be fixed.

a brief background:

My system is a desktop with two monitors and an Nvidia Quadro P1000 GP107GL video card and had been working fine. I unplugged everything, moved it to another room, reconnected everything and got stuck at boot. The condition is repeatable and it is repeatable using the Nvidia driver or the Nouveau driver. With no driver and no Xorg installed, I believe the system booted normally with the same display duplicated on each monitor.

The secondary monitor is a 10 year old Dell E207WFP and uses a DVI-D connector. The primary monitor is a Samsung S24D300HL. The video card has mini-display ports. I tried the original cable setup for the secondary monitor (DVI-D to Display port, then an adapter to mini-display port) as well as a different cable (DVI-D to mini display port). The condition persisted with each, the only difference being the last boot message displayed might be different (...systemd-networkd completed vs persistent storage completed... vs something else). Assuming those messages had something to do with the problem wasted days. Also a waste was switching back and forth between Nouveau and Nivida drivers and trying many different kernel mode parameters. I didn't find any clues in the journalctl log either.

If someone shows an interest, I'll provide whatever additional information I can.

Last edited by liglog (2024-10-14 19:36:34)

seth · 2024-10-14 07:16:40

Boot the system w/ both outputs attached, get a cup of coffee and another one (ie. generate a visible stall in the boot, 5 minutes or so), detach the second output, continue the boot, immediately login and please post your complete system journal for the boot:

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

This is very most likely related to the 6.11 kernel which has framebuffer related issues IN SPADES.

liglog · 2024-10-14 14:53:23

Thank you for your reply Seth.

The link to the log file is here: http://0x0.st/X6UY.txt

I booted at 10:17. I unplugged the cable at 10:41.

seth · 2024-10-14 15:08:19

Dude, you've a serious caffeine problem

Oct 14 10:17:42 mambu systemd[1]: Started Getty on tty1.
Oct 14 10:17:42 mambu systemd[1]: Reached target Login Prompts.
…
Oct 14 10:17:43 mambu systemd-networkd[821]: eno1: DHCPv4 address 192.168.1.103/24, gateway 192.168.1.1 acquired from 192.168.1.1
Oct 14 10:17:45 mambu systemd[1]: systemd-rfkill.service: Deactivated successfully.
Oct 14 10:18:12 mambu systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Oct 14 10:19:41 mambu systemd-networkd-wait-online[857]: Timeout occurred while waiting for network connectivity.
Oct 14 10:19:41 mambu systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Oct 14 10:19:41 mambu systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Oct 14 10:19:41 mambu systemd[1]: Failed to start Wait for Network to be Configured.
Oct 14 10:19:41 mambu systemd[1]: Reached target Network is Online.
Oct 14 10:19:41 mambu systemd[1]: Starting Refresh Pacman mirrorlist with Reflector....
Oct 14 10:19:42 mambu systemd[1]: reflector.service: Deactivated successfully.
Oct 14 10:19:42 mambu systemd[1]: Finished Refresh Pacman mirrorlist with Reflector..
Oct 14 10:19:42 mambu systemd[1]: Reached target Multi-User System.
Oct 14 10:19:42 mambu systemd[1]: Reached target Graphical Interface.
Oct 14 10:19:42 mambu systemd[1]: Startup finished in 12.251s (firmware) + 3.226s (loader) + 2.339s (kernel) + 17.041s (initrd) + 2min 4.140s (userspace) = 2min 38.999s.
Oct 14 10:33:04 mambu systemd[1]: Starting Cleanup of Temporary Directories...
Oct 14 10:33:04 mambu systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Oct 14 10:33:04 mambu systemd[1]: Finished Cleanup of Temporary Directories.
Oct 14 10:33:04 mambu systemd[1]: run-credentials-systemd\x2dtmpfiles\x2dclean.service.mount: Deactivated successfully.
Oct 14 10:41:08 mambu login[891]: pam_systemd_home(login:auth): New sd-bus connection (system-bus-pam-systemd-home-891) opened.

The system booted fine and was active while you were having like, what, 20 cups of coffee?

There're no obvious problems nor any system response to you yanking the cable, so this is likely just output related.
Try to add

nvidia_drm.modeset=1 nvidia_drm.fbdev=0

to the https://wiki.archlinux.org/title/Kernel_parameters

liglog · 2024-10-14 16:00:41

... I had a snack too.

With those parameters entered at boot time, the system booted to the log in prompt!
log file: http://0x0.st/X60r.txt
I ran startx and both monitors showed output.
The desktop environment is configured to open a terminal and polybar on the primary but the terminal opened on the secondary monitor and polybar on the primary. This is something I can probably fix.

I rebooted and again entered the same parameters and the system booted to the log in prompt.
log file: http://0x0.st/X60Z.txt
I ran startx and everything looks correct. I'll test it out a bit and reboot a few times throughout the day to check things out.

THANK YOU Seth!

I'll do some research on these parameters but would you recommend trying only the nvidia_drm.fbdev=0 parameter? I had tried that one in my prior troubleshooting attempts.

liglog · 2024-10-14 16:12:30

liglog wrote:

I had tried that one ...

I meant to say I hadn't tried that one...

DougRichardson · 2024-10-14 16:12:32

liglog: thanks for posting this. I started experiencing this problem a couple weeks ago after running

sudo pacman -Syu

I also can confirm that seth's fix did the trick. Before this, I had to uninstall the `nvidia` package to be able to get my terminal running (though I was always able to ssh into the box even when the local tty was busted).

liglog · 2024-10-14 16:32:07

I went ahead and tried using only the nvidia_drm.modeset=1 parameter.
The results were identical to post #5.
first boot log: http://0x0.st/X60V.txt
second boot log: http://0x0.st/X603.txt

Doug, no worries. I'm glad it is helping someone. In any case, Seth is the problem solver.

liglog · 2024-10-14 19:31:55

After a few reboots, shutdowns, and using the computer as I normally do, the problem seems solved.

For completeness, some relevant info is listed below:

/boot/loader/entries/arch.conf

.
.
.
options rd.luks.name=my_UUID_here=root root=/dev/mapper/root ipv6.disable=1 nvidia_drm.fbdev=0

this also works

.
.
.
options rd.luks.name=my_UUID_here=root root=/dev/mapper/root ipv6.disable=1 nvidia_drm.modeset=1 nvidia_drm.fbdev=0

/etc/mkinitcpio.conf

.
.
.
HOOKS=(base systemd autodetect microcode modconf keyboard keymap sd-vconsole block sd-encrypt filesystems fsck)

seth · 2024-10-14 20:11:27

I'll do some research on these parameters but would you recommend trying only the nvidia_drm.fbdev=0 parameter? I had tried that one in my prior troubleshooting attempts.

No.
nvidia_drm.modeset=1
1. is mandatory for any wayland if you ever want to try
2. will expose the EDIDs to the drm subsystem
3. blocks the simpledrm device that otherwise might get in the way (only the commandline parameter, not the module option)
It is a good idea to have it enabled regardless of anything else.

I'm not sure whether the last item or fbdev=0 helped you - this used to be the default and only got reversed for anecdotal reports to prevent issues w/ framebuffer issues that pester the 6.11 kernel, but the fbdev setting has always been an inconsistent hit or miss, benefitting some hardware and breaking other.

liglog · 2024-10-14 22:18:28

OK. I'll add nvidia_drm.modeset=1 back in. As you say, it will save me some pain if I try Wayland in the future.

Based on your last comment, I tried removing nvidia_drm.fbdev=0 and keeping nvidia_drm.modeset=1 to see if the system still boots with both monitors plugged in. It didn't. The boot stalled. The log file is here (for what it's worth): https://0x0.st/X6dA.txt
So I'm using both parameters now.

Thanks for your time and expertise Seth.

Last edited by liglog (2024-10-15 03:49:29)

Arch Linux

#1 2024-10-13 21:20:49

[SOLVED] With a second monitor plugged in, boot sequence stalls

#2 2024-10-14 07:16:40

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#3 2024-10-14 14:53:23

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#4 2024-10-14 15:08:19

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#5 2024-10-14 16:00:41

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#6 2024-10-14 16:12:30

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#7 2024-10-14 16:12:32

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#8 2024-10-14 16:32:07

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#9 2024-10-14 19:31:55

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#10 2024-10-14 20:11:27

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

#11 2024-10-14 22:18:28

Re: [SOLVED] With a second monitor plugged in, boot sequence stalls

Board footer