System doesn't boot up after nvidia dkms installation

Xerx0 · 2024-12-08 15:47:01

I don't know what you saw or think you saw, but backtraces will contain that: stack positions of function calls, sometimes (if the binary was dwarf-enabled) of variables and even their values (but that's rare)
That's it.
If some unencrypted truely sensitive data (your background color is not) shows up in a backtrace, ever, file a bug against that software.

Its a "should" not contain sensitive data. So why publish it without thinking about it?

Highly sensitive data should not even be kept in memory unscrambled (luckily that's a super-duper rare condition to take care of itfp)

"Should"

And there're only to kernel backtraces, the wl module triggers a warning twice.

Yes. I've seen that.

File a bug against whatever that is - this is insane.
However:
You're using mullvad and the address you redacted fits with 45.83.223.x:443 and is one of their servers and tells nothing about you, your VPN, your network, your location or anything else.

Yes, thats my VPN provider. They have more than one server so you guessed wrong. But: When and where I connect to, is nothing of importance to the problem.

No. (No routing or IP tables)
But even if: so what?

It's a local address which is not reachable from the outside. But again: Has nothing to do with the problem.

It only says what lease *you* get - that's not a structure nor a network.
Here, mine is 192.168.11.2 - now hack me.

It's just the address I was assigned via DHCP locally. But now I'm coming after you!

Do you have access to such database?
Do you use a very unique SSID? Why?
If you're worried about that, I'd rather change that…

Wigle.net
Why should I change things when I can redact them before I publish things?

You don't have to defend anything, I'm suggesting that you drastically overestimate the sensitivity of anything in those logs.
You see "number I don't understand" and assue "It's probably encoding my penis length!"
You're free to disagree but if you care about privacy I'd invite you to try to figure what all these things are and mean and tell so you're not scared out of your mind.

I'm not scared at all. I just think that people should be aware of things before posting them. So yes, I disagree.

Last edited by Xerx0 (2024-12-08 16:24:30)

seth · 2024-12-08 15:50:16

Come back when you're interested in the topic and not your paranoia.

Xerx0 · 2024-12-08 16:20:40

Haha just because I have a different opinion on those things? Interesting. The whole conversation could have been avoided in the first place. Theres no need to criticize people as being "paranoid"! EOD

Calling people names and allegations that they are stupid does NOT prove your point.
Why did you feel the need to publish information about the services I use? Pointless and unnecessary.

Last edited by Xerx0 (2024-12-08 18:49:50)

dakota · 2024-12-08 18:46:05

seth wrote:

For now you're running into the simplydumb device, why have you not updated the system to get a kernel where the nvidia_drm.modeset=1 hack has been restored.
It would probably have spared use a lot of time spent

So... did seth's suggestion to update your system fix the problem?

Xerx0 · 2024-12-08 20:16:32

I just updated the system (kernel 6.12.3-arch1-1 now), but the problem remains the same.

Is it possible that as soon as the kernel takes over and tries to utilize the nvidia card instead of the CPU integrated one (Intel i915) that this fails? Does the kernel "enforce" the switch or should there be some kind of failsafe if the switch fails?
The nvidia driver for this dual GPU system is called Optimus. I will read the documentation again and see if I have missed something.

Xerx0 · 2024-12-14 15:07:06

Havent had much time to look into the issue any further except one thing:

The system has two video cards but only the Nvidia card is enabled at the moment (lspci only lists the Nvidia) so this shouldn't be a problem.

As soon as I pass the kernel parameter nvidia-drm.modeset=1 the system freezes directly after the bootloader as described earlier.

I have found this information about the parameter but can't figure out why the problem occurs:

"Setting modeset=1 doesn’t actually install a framebuffer console. All it really does is enable the DRIVER_MODESET capability flag in the nvidia-drm devices so that DRM clients can use the various modesetting APIs. In addition to allowing clients that talk to the low-level DRM interface to work, it’s also necessary for some PRIME-related interoperability features.
The downside, if you want to call it that, is that loading nvidia-drm with modeset=1 causes it to configure and initialize all GPUs immediately rather than waiting for a client to open the /dev/nvidia* device files. This means that some options that require a userspace application to configure them before the GPUs are initialized won’t work if they were already configured by nvidia-drm."

https://forums.developer.nvidia.com/t/u … g/204068/2

But the whole issue seems to be system related and not AUR?

V1del · 2024-12-14 22:40:30

A good side effect of the modeset parameter on 6.12.3 and newer as well as older kernels it that it will disable an in kernel framebuffer that will otherwise steal your device. If you haven't yet updated to the newer kernel then a conflict with this parameter and said in kernel driver is to be expected, so make sure you're up to date, the module got built properly and then... it would really help you and all of us to have a journal if that doesn't fix it.

Also sanity check... you did install the resulting {lib32-}nvidia-470xx-utils packages as well? If you "just" installed the dkms package that's just the kernel module lacking the userspace libs.

Last edited by V1del (2024-12-14 22:41:46)

seth · 2024-12-15 15:43:57

As soon as I pass the kernel parameter nvidia-drm.modeset=1 the system freezes directly after the bootloader as described earlier.

Try to only boot the multi-user.target, 2nd link below - and if that also doesn't work, reboot the system using the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) and post the journal of such boot.

Xerx0 · 2024-12-17 18:50:41

V1del wrote:

Also sanity check... you did install the resulting {lib32-}nvidia-470xx-utils packages as well? If you "just" installed the dkms package that's just the kernel module lacking the userspace libs.

Yes, packages installed. Kernel 6.12.4 now.

What I tried:
I started via a live system and added the following parameters to the kernel:

nvidia-drm.modeset=1 nvidia-drm.fbdev=1 sysrq_always_enabled=1 systemd.unit=multi-user.target

(most where already present)

and restarted the system. The screen became distorted immediately after the bootloader (like expected), but I saw that the system still responded to commands. I entered the passphrase for the LUKS volume, let the system boot, and then logged in and redirected the output of `journalctl -b` to a file. Then I rebooted again, this time with the LTS kernel and

nvidia-drm.modeset=0

, and saved this log as well.

I then rebooted again to my fallback bootloader entry which doesn't have additional kernel parameters.
The first bootlog file was empty? The second one is this (http://0x0.st/XC8L.txt) but I doubt that it's even worth looking at it.

Following a reboot attempt to obtain a log with modeset enabled, system boot failure occurred. Despite multiple attempts, progress beyond the displayed screen (https://imgur.com/a/gkFVYuc) was not achieved. While the system successfully booted and allowed login once, this result is not reproducible. Currently, the only action possible upon screen display is a reboot initiated via Ctrl+Alt+Backspace.

The boot log, generated with modeset=0, is this: (http://0x0.st/XC8f.txt). The log indicates issues with the wl module, font settings, and the absence of modeset, I don't see anything else of significance. So this log may not be particularly useful. Nothing has changed to the log I previously posted, except the kernel version.

Anything else I should try?

seth · 2024-12-17 20:23:33

You're supposed to disable "nvidia-drm.fbdev=0", but that parameter is inert on the 470xx drivers anyway.

Dec 17 17:41:28 archlinux kernel: nvidia_drm: unknown parameter 'fbdev' ignored

splash quiet

Remove those!

I started via a live system and added the following parameters to the kernel:

What does that mean? What makes you believe the "live system" is relevant or even has the nvidia driver?
Where did you save the journal from the live system? Did you chroot or something like that?

reboot initiated via Ctrl+Alt+Backspace

Out of what context?
Ctrl+At+Backspace will zap X11, but not initiate a reboot??

Xerx0 · 2024-12-17 21:57:34

seth wrote:

You're supposed to disable "nvidia-drm.fbdev=0", but that parameter is inert on the 470xx drivers anyway.
Dec 17 17:41:28 archlinux kernel: nvidia_drm: unknown parameter 'fbdev' ignored

Will do.

seth wrote:

Remove those!

Ok.

seth wrote:

What does that mean? What makes you believe the "live system" is relevant or even has the nvidia driver?
Where did you save the journal from the live system? Did you chroot or something like that?

Haven't saved the log of the boot. If it helps I will get it.

My sentence wasn't well phrased: I just used it to boot and modify the the bootloader. Beside that it was unnecessary information.

seth wrote:

Out of what context?
Ctrl+At+Backspace will zap X11, but not initiate a reboot??

It does on the MacBook. fn key needed as well, so it's fn+Ctrl+Alt+Backspace

seth · 2024-12-17 22:06:08

fn+Ctrl+Alt+Backspace

Ah, ok.
The main thing is the splash part, one thing that might help would be to define some lower framebuffer resolution (XGA)
https://www.kernel.org/doc/Documentation/fb/modedb.rst
Something like "video=1024x768M@60"

Or to completely disable the framebuffer console, https://wiki.archlinux.org/title/GRUB/T … ramebuffer - but I'm not sure this works w/ any other bootloader.

Xerx0 · 2024-12-18 00:16:09

I removed quiet, fbdev, and splash parameters and rebooted. This time, I was lucky and able to boot, log in, and save the log http://0x0.st/XCNo.txt.

After a new reboot, I am stuck at the same position again (before I am even able to unlock the LUKS volume). No changes were made between boots.

The things you mentioned are probably not directly related to the problem, or are they? I will look into them tomorrow.

seth · 2024-12-18 08:40:04

Disabling the framebuffer or changing the resolution might get you reliable access to the system despite KMS and no simpledrm.
But you also seem to use systemd-boot.

no kms:

Dec 17 17:41:27 archlinux kernel: fbcon: Deferring console take-over
Dec 17 17:41:29 archlinux kernel: fbcon: Taking over console

succesful kms:

Dec 17 23:14:09 archlinux kernel: fbcon: Taking over console
Dec 17 23:14:10 archlinux kernel: efifb: probing for efifb
Dec 17 23:14:10 archlinux kernel: efifb: No BGRT, not showing boot graphics
Dec 17 23:14:10 archlinux kernel: efifb: framebuffer at 0x80020000, using 28800k, total 28800k
Dec 17 23:14:10 archlinux kernel: efifb: mode is 2880x1800x32, linelength=16384, pages=1
Dec 17 23:14:10 archlinux kernel: efifb: scrolling: redraw
Dec 17 23:14:10 archlinux kernel: efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

LTS, no kms

Dec 17 16:29:26 archlinux kernel: pci 0000:01:00.0: BAR 1: assigned to efifb
Dec 17 16:29:26 archlinux kernel: fbcon: Deferring console take-over
Dec 17 16:29:29 archlinux kernel: fbcon: Taking over console

Now we'd need to see the failing boot.
But try the video=1024x768M@60 kernel parameter regardless, resp. maybe also just "video=1024x768"

Xerx0 · 2024-12-19 15:35:14

Just so we are on the same page:

What is your definition of a failed boot? The last boot log I uploaded was from a boot that failed (at least in my opinion). The screen became distorted and stuck.

I added the video parameter to set the specified resolution, but shouldn't there be a noticeable difference (at least visually)? See: https://imgur.com/a/mHMkXWz, and this is the log (http://0x0.st/XC2X.txt). But, as I said, besides the video parameter I added, there is no difference from the previous boot log.

When does the KMS switch actually happen?

It is a UEFI system, so the bootloader resides on the ESP partition. It then checks for entries defining the kernel, parameters, and initial ramdisk. The kernel is moved to RAM, and the ramdisk, containing necessary modules (such as NVIDIA modules and those for the encrypted volume), is loaded. The next step is to unlock the root partition.

Kernel starts, inits and loads other modules.

After that, systemd would take over, but that would be far behind the point where the system already gets stuck. Visually, it is before the unlock for the root partition, so I think it happens when loading the RAM disk or loading modules included in the RAM disk?

What I have tried: Adding `nofb` as a parameter and `nomodeset` (which probably doesn't even make sense). Hmm...
Would it be worth trying to switch to GRUB?

seth · 2024-12-19 19:27:29

This one?

I removed quiet, fbdev, and splash parameters and rebooted. This time, I was lucky and able to boot, log in, and save the log http://0x0.st/XCNo.txt.

KMS kicks in whe you load a modesetting driver, in this case

Dec 19 12:39:22 archlinux systemd-modules-load[137]: Inserted module 'nvidia_modeset'

This can happen in the initramfs, afterwards and the simpledrm driver is compiled into the kernel.

Dec 19 12:39:23 archlinux kernel: nvidia 0000:01:00.0: [drm] User-defined mode not supported: "1024x768": 60 64127 1024 1080 1184 1344 768 769 772 795 0x20 0x6

Does it like "vga=792" or "gfxpayload=1024x768x24,1024x768"?

Sanity check: "acpi_rev_override=5", why is that there?

Xerx0 · 2024-12-20 03:18:39

seth wrote:

This one?
I removed quiet, fbdev, and splash parameters and rebooted. This time, I was lucky and able to boot, log in, and save the log http://0x0.st/XCNo.txt.

Yes, thats the one.

Does it like "vga=792" or "gfxpayload=1024x768x24,1024x768"?

It's the same. There should be a difference, but I can't figure out why there isn't.

Sanity check: "acpi_rev_override=5", why is that there?

I kept that setting in mind because of old Linux suspend/hibernate issues on the system (years ago). I removed it to rule that out as well. Nope.

seth · 2024-12-20 08:48:57

Is the "User-defined mode not supported" warning still there w/ "vga=792" ?
Do you btw. have an external output you could plug in?

Xerx0 · 2024-12-22 00:08:49

Unfortunately I have no external display available at the moment to try.

I have read a bit more about the topic, and the vga parameter only applies to systems with a BIOS. The correct one for UEFI systems and GRUB seems to be gfxpayload.

 Unknown kernel command line parameters "vga=792", will be passed to user space.

When systemd is used the parameter video= should be used. That one is accepted and not unknown but still doesn't solve the problem. Is there something important I might have missed with this parameter?

In the log there is one line:
nvidia_drm: unknown parameter 'fbdev' ignored

which occurs after the modules are inserted. Where does this parameter come from? Probably not related to the problem, so I'm just curious.

I'm thinking about enabling the Intel graphics card and using the Nvidia card only for certain tasks. But everything I've read about that topic indicates it requires custom firmware and additional software. The software hasn't been updated since 2017, so I'm unsure if the solution is still valid. Apple hasn't modified the firmware in recent years, so it might still work. (Source: https://gist.github.com/stefanocoding/c … d655c9fbbf)

seth · 2024-12-22 09:28:39

VGA is legacy, we're throwing some stuff at the wall because
1. nvidia
2. macbook

Where does this parameter come from?

modprobe -c | grep fbdev

likely you added this to some modprobe.d config at some point, maybe there's a residual in the initramfs (if you removed the config, but didn't regenerate the initramfs)
The parameter isn't supported < the 525xx drivers.

I'm thinking about enabling the Intel graphics card and using the Nvidia card only for certain tasks. But everything I've read about that topic indicates it requires custom firmware and additional software.

I'd just try - running a prime configuration should also drastically increase battery time.

Arch Linux

#26 2024-12-08 15:47:01

Re: System doesn't boot up after nvidia dkms installation

#27 2024-12-08 15:50:16

Re: System doesn't boot up after nvidia dkms installation

#28 2024-12-08 16:20:40

Re: System doesn't boot up after nvidia dkms installation

#29 2024-12-08 18:46:05

Re: System doesn't boot up after nvidia dkms installation

#30 2024-12-08 20:16:32

Re: System doesn't boot up after nvidia dkms installation

#31 2024-12-14 15:07:06

Re: System doesn't boot up after nvidia dkms installation

#32 2024-12-14 22:40:30

Re: System doesn't boot up after nvidia dkms installation

#33 2024-12-15 15:43:57

Re: System doesn't boot up after nvidia dkms installation

#34 2024-12-17 18:50:41

Re: System doesn't boot up after nvidia dkms installation

#35 2024-12-17 20:23:33

Re: System doesn't boot up after nvidia dkms installation

#36 2024-12-17 21:57:34

Re: System doesn't boot up after nvidia dkms installation

#37 2024-12-17 22:06:08

Re: System doesn't boot up after nvidia dkms installation

#38 2024-12-18 00:16:09

Re: System doesn't boot up after nvidia dkms installation

#39 2024-12-18 08:40:04

Re: System doesn't boot up after nvidia dkms installation

#40 2024-12-19 15:35:14

Re: System doesn't boot up after nvidia dkms installation

#41 2024-12-19 19:27:29

Re: System doesn't boot up after nvidia dkms installation

#42 2024-12-20 03:18:39

Re: System doesn't boot up after nvidia dkms installation

#43 2024-12-20 08:48:57

Re: System doesn't boot up after nvidia dkms installation

#44 2024-12-22 00:08:49

Re: System doesn't boot up after nvidia dkms installation

#45 2024-12-22 09:28:39

Re: System doesn't boot up after nvidia dkms installation

Board footer