-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ublue-nvctk-cdi.service should be refactored to udev rule #180
Comments
A related concern was reported in Discord ( https://discord.com/channels/1072614816579063828/1072617059265032342/1232829046036103231 ) where if the nvidia GPU has been disabled (for example, BIOS disabled dGPU on a dual GPU laptop), then this fails erroneously. I should finally fix this bug. |
This will also fail if the nvidia card isn't "ready". We've seen internal A4000 also throw this error. |
Hello! I'm the user mentionned by @bsherman
And here is what
As I mentioned on discord, I think disabling the dGPU shouldn't be a source of error, as this has a HUGE impact on battery life, and if I don't plan on doing something that requires the dGPU, I think it's best to just disable it until I need it. In this case, I think displaying warnings at most would be ideal. |
@m2Giles and I were discussing this, and we can replace the service with a udev rule which calls the device gets added.
Something like this? |
Is there an ETA when this change will be visible in the ublue images? I convinced a family member to switch from Win10 to Aurora, but after installation on his old Laptop with nvidia GPU he only gets the service error message displayed on his screen and no desktop loads: I guess there is no fix, which one could manually apply, right? It needs to be an update Aurora image, correct? |
From what I see, while your issue seems related to some extend, I think something else is going on in your case. This error should not prevent display as it occurs in two cases:
|
In the Nvidia images, we have the ublue-nvctk-cdi.service to support containers.
The only dependencies this service has is if the binary exists, is executable, and we are after local-fs.target. This is problematic because it will always run even if the Nvidia modules are not loaded due to an Nvidia card not being present. For eGPUs, the Nvidia card is not present until much later in the boot process. Instead of using a service, this should be handled via udev rule since this script is dependent on the necessary hardware being present. Right now with an eGPU, you have to manually restart the service before entering any containers.
I'll try converting the service to a udev rule to test.
The text was updated successfully, but these errors were encountered: