BBit's not just a PR in akmods, since i'll need to make sure the hwe nvidia images use the proper repos and install the new package set from negativo17
Bhere's the hwe PR, thought it won't build without the akmods building first
https://github.com/ublue-os/hwe/pull/231
https://github.com/ublue-os/hwe/pull/231
B@Noel @Kyle Gospo
Bi added a comment on the akmods PR and pulled it out of merge queue since it seems pretty clear we are now suffering "repo skew"
BBmain building on same versions as that, so we can then do HWE merge
Battempting merge queue for https://github.com/ublue-os/hwe/pull/231
BBBugh, well
Bthis change resulted in wayland being disabled, so i'm reverting
<https://github.com/ublue-os/akmods/pull/172
<https://github.com/ublue-os/akmods/pull/172
GitHub
This reverts commit b64843b.
I found that this akmods+hwe change was disabling Wayland.
Needs more testing before merging again.
I found that this akmods+hwe change was disabling Wayland.
Needs more testing before merging again.
BGitHub
This reverts the two PRs which were made to support the swap to negativo17 nvidia driver.
This reverts commits:
6c4a80a
ed30173
I found that this akmods+hwe change was disabling Wayland.
Needs mo...
This reverts commits:
6c4a80a
ed30173
I found that this akmods+hwe change was disabling Wayland.
Needs mo...
Bi'm probably too tired to make sense of whats going on but the last rebuilds of HWE SHOULD have had the rpmfusion nvidia not negativo17, but they didn't?
Bi just tried another rebuild
Bok, i can at least confim the last HWE rebuild seems to be using the correct akdmods and branch... it's trying to build rpmfusion based nvidia
MWill read through.
Bso, the PRs actually "worked"
i'm actually pretty sure the akmods changes were 100% fine... nvidia module loaded, etc
Xorg worked well
the problem was in the GDM udev rules
rather something about the negativo17 packages triggered a rule which created
i'm actually pretty sure the akmods changes were 100% fine... nvidia module loaded, etc
Xorg worked well
the problem was in the GDM udev rules
/usr/lib/udev/rules.d/61-gdm.rules which weren't changed, sorather something about the negativo17 packages triggered a rule which created
/run/gdm/custom.conf with WaylandEnable=falseBincidentally, this
61-gdm.rules and /run/gdm/custom.conf sounds VERY much like what may be causing my observed "no wayland" in VMs as mentioned: https://discord.com/channels/1072614816579063828/1087140903031943178/1228874350434848889Bone helpful thread was https://discussion.fedoraproject.org/t/no-longer-able-to-select-wayland-when-logging-in/92787
but last night, I did not find "why" the udev rule was triggering... i was too tired to dig deep
but last night, I did not find "why" the udev rule was triggering... i was too tired to dig deep
Mwe can test it by copying to /etc/udev/rules.d/ as same name and add some writes for each disable_wayland
Bmmm.. yeah
Bi like that
Bi will build custom images in a clone of the akmods/hwe repos so we can test those images without breaking our official builds again
MI think fedora patched 61-gdm over the default provided. Arch has had the recommendation to mask the rule with a symlink to /dev/null in /etc/udev/rules.d
Here is the GDM rules from gnome: https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in
Here is the GDM rules from gnome: https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in
Binteresting
Mhere is the spce file.
https://src.fedoraproject.org/rpms/gdm/blob/rawhide/f/gdm.spec and it has a few patches concerning wayland
https://src.fedoraproject.org/rpms/gdm/blob/rawhide/f/gdm.spec and it has a few patches concerning wayland
Mhttps://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec
In negativo17's spec file I don't see anything that should touch either of these
In negativo17's spec file I don't see anything that should touch either of these
Mand nothing in the rpmfusion one either https://github.com/rpmfusion/nvidia-kmod/blob/master/nvidia-kmod.spec
Bright, i don't think either the rpmfusion/negativo nvidia stuff modify the gdm udev rules, but maybe they do seem to install/configure something slightly different which yields different results from the udev rules
Bthus, my plan, get a build of silverblue with negativo17 nvidia as I was planning, and we can test the udev rules on that vs current "official" ublue-os/silverblue-nvidia
Bhowever, i don't have as much time during week usually, so... I may be able to get images built/pushed somewhere, but i probably won't have more time for this issue at least until weekend
i think the metadata build stuff is higher priority, so any time i have will go there (after pushing images)
i think the metadata build stuff is higher priority, so any time i have will go there (after pushing images)
B@M2 i'm working on getting test images published
Bbuilding our images in other repos/orgs is a PITA
Bok... so, here's some images built/building in test repos/registry locations:
Bonly F39 seems to be building right now... no cosigning and the secure boot signing key used is the test key, so don't run secure boot with these images
Bbut they have negativo17 nvidia and we should be able to test out nvidia + GDM udev on them
B@M2 i invited you to that test org and will give you rights to the repos in case we need to test something
BBi think you should have write privs on repos, let me know if you need something with that
MI'm out for the night. Will take a look in the morning
B@M2 i never got back to testing this... did you? at this point, i'm not thinking we swap before 40... but still think we can shortly after.. .
MI have not. Was wrapping up loose ends in bluefin this weekend
Byeah, no worries
