Nvidia 555 you say @j0rge
Nvidia 555 you say @j0rge
https://github.com/ublue-os/akmods/pull/173
https://github.com/ublue-os/hwe/pull/234
NVIDIA
Thank you @Kyle Gospo
308 Replies
and kyle
lets chat here on any cleanup
LET'S GO.
i see an issue on the hwe repo i think i can fix up
but akmods is looking good
Surface doesn't seem to like this on hwe
hwe is very broke
i'm working on it
wait where is NVIDIA_PACKAGE_NAME coming from?
didn't bite me on bazzite, and it's not in that file
i'm digging
very odd, because the main branch builds clean locally
@bsherman I think you're looking at an old build
I re-ran them and it's already past what you were looking at
yep
yeah, i was about to run the builds again and saw you'd started it
the error was in the last merge commit failure
but it's all good
FYI: ublue-os/hwe might need the initramfs build script added to it
there's also a pending change from @EyeCantCU to sign the kernel
is initramfs now a requirement?
i know i'm out of the loop...
but last i knew (month+ ago) we weren't doing initramfs builds for main/hwe
reason: it added weight for downstream bazzite/bluefin
bazzite does it and i know it works there, if you have any issues w/ black screens on KDE we'll know why
GNOME was fine
Bazzite skips the added weight by not pulling anything from HWE
except a script we run against bazzite
bluefin could do the same I suppose
so, we could not do it in main, because, well, it makes little sense
yeah, true
but do it in hwe if required
yep
would we need it for all of hwe or just hwe's nvidia builds?
might as well do all to make sure any kernel changes are in the initramfs
yeah, true, they are all custom kernels in that repo
@Kyle Gospo you mentioned firefox has issues with 555 ... is that both the flatpak and host installed packages? or just host installed?
both
lame
it's a firefox issue, they improperly set the explicit sync frame lock
hah
and then the driver freaks out (as it should)
nice job guys
1898476 - Firefox crashes on Wayland with Explicit Sync on Nvidia
ASSIGNED (stransky) in Core - Widget: Gtk. Last updated 2024-06-26.
Yeah custom initramfs there would make sense. And for Nvidia it will also mean that early loading for them will be set
this was also the issue with gdm @bsherman
i'm rebasiong for testing
loaded too late
well, i love that all i've got to do to fix nvidia is show up and let @Kyle Gospo do it for me
same thing for CoreOS kernel on Bluefin... i show up and @M2 handles it
you guys are the best!
We saved the centos builds for you.
j/k
Ope. looks like i'm traveling again. See ya!
Lol
and I don't even have a nvidia gpu
how about that
So CentOS could be killer for a unix lab.
But we would probably need to make sure nfs/smb home mounts work
i remember RedHat Linux 8 desktops in a lab at school... gee... I think we had NFS mount home dirs on 100Mbit
i think that was all brand new my senior year... we had HP and SGI unix workstations before
Here we go!!!!
it's wayland!
weee
and i don't think it has your custom initramfs yet?
rebasing to kinoite
i mean... this works
@j0rge may have merged bazzite testing into main
😉
what?
are you serious?
yeah, next build will get 555 stable
dude's going for it
LET'S GOOOOOOOOOOOOOOOOO
hahaha
F Firefox ? LOL
he's handled that
the fix is a half fix, xwayland firefox is buggy for different reasons
but Mozilla is working to merge the real fix
so we'll see what happens, I just won't let main build until then
is there an issue handy?
1898476 - Firefox crashes on Wayland with Explicit Sync on Nvidia
ASSIGNED (stransky) in Core - Widget: Gtk. Last updated 2024-06-26.
hey what's the tldr on this, will this autoslurp into bluefin?
yep, next build
like do we need to pin bluefin's nvidia images?
since it's in HWE
yeah if you don't want 555 you'll ned to
though it's "stable" (thanks nvidia)
so your call on that
yeah can we do that? Crashing firefox sucks, especially for gts
well, you're shipping GNOME which still ships the x11 session
so you can just tell nvidia users to use x11
firefox only crashes under wayland
OH
cc @M2
sorry just needed the backstory, doing a work livestream so I'm a mess rn
chrome people should be fine?
yes
yes they're fine
that's what I'm doing on bazzite
so we may wanna post + build to get it outta the way?
understood
turn off our builds
disable everything until mozilla is out
this is a pain since we don't decouple nvidia builds in our workflows
yeah but if it's crashing only in wayland
and that was already broken
fair
it'd be no change for nvidia users right?
Is this a new issue with 555? Or was it present in older versions?
well, it didn't crash
but nvidia prior to 555 was complete luck of the draw if it worked or not
for wayland in general
yeah and if we pin, we'd need to wait for a firefox release
and those happen like every few weeks?
new, 555 adds explicit sync and the bug is firefox under explicit sync crashes
Ah. Was going to suggest Nvidia users already are on X11, so don't bother. But since it's new, we might care
ok so I'll post the message after work, then that'll be a heads up and then in the middle of the night when they update, it's kinda the best we can do?
if they're on x11, no bug
no problem
Wayland was previously broken for different reasons
now only firefox is broken under wayland
and that's on mozilla to patch
so for nvidia users, we go from broken to broken + firefox broken. So either way they need to be on X11.
from broken to working but firefox broken
yeah
Yeah. That's why I'm thinking don't worry about it. It's still less broken
fine, I think let's just roll with it, this is Jensen's mess, not ours. 😄
like if someone complains sorry that a 3 Trillion dollar company was unable to give us a better upgrade experience. 😄
Working on the announcement here in a minute
@Kyle Gospo am I mentioning bazzite or leaving that up to you and nick?
can leave it up to us
well... damn, i'm on xorg, not by choice
Universal Blue
Nvidia 555 drivers incoming, important information!
Congratulations Nvidia users, say goodbye to a ton of old bugs and I"m sure some new ones! Nvidia 555 drivers are landing and will be available in the next image build. This post applies to Bluefin/Aurora, Bazzite users stand by for further info. IMPORTANT INFORMATION FOR FIREFOX USERS Firefox is crashing in the Wayland session: That means ...
how's this?
https://github.com/ublue-os/hwe/commit/98b6f7f2b40e9440279a04a4af872f82f6470e51#diff-3fe462d074377f0dee636ff5c561bfc772d9c3838f72611e7dd1242dfb6141d1R57-R59
this was the fix... i thought... and i base my custom images off hwe (for nvidia) so shouldn't i inherit this fix?
GitHub
feat: swap to negativo17 as nvidia driver source (#234) · ublue-os/...
* feat: swap to negativo17 as nvidia driver source
This reworks all the bits in akmods for nvidia:
- removes nvidia driver version as only latest is supported
- uses negativo17 nvidia driver a...
i think i did inherit it
but... still forced to xorg on nvidia
@Kyle Gospo do you remember what dr. kleiner said in the beginning of hl2?
"It's a red letter day Gordon!"
did you regenerate initramfs on your build?
no
this is needed @bsherman
so my confusion here...
am i missing that hwe - nvidia already does an initramfs rebuild at image build time?
no
we need to add that in hwe
ok, so if i enable initramfs rebuild on my host... do i need the kargs, too?
or are they now handled by the initramfs
this
ok, thank you 🙂 i shall tinker
for hwe, we should just grab our initramfs script in bluefin/bazzite and use that for all of the images.
and make sure to have the necessary initramfs files
hhmm...
rebuilt initramfs locally... i no longer get a black screen on tty0 at boot ... but... still GDM is xorg only... next tinkering step
make sure there is nvidia.modeset=1 in your modprobe
i'm just going to try this since y'all swear by it 🙂
https://github.com/bsherman/ublue-custom/commit/8cadf609ba93a9ca3e4ba77ba428e54897fc0459
GitHub
feat: updates for build-time initramfs generation · bsherman/ublue-...
includes nvidia and tpm unlock capability in the initramfs
also adds support for some older AMD GPUsin modprobe.
that's the spirit!
https://discord.com/channels/1072614816579063828/1074422586894712912/1255979158320840775
Looks like someone ran into the same thing
hmmmm
/usr/libexec/rpm-ostree/wrapped/dracut: No such file or directory
cliwrap need
ed
ah, i'm not running it all in
rpm-ostree cliwrap install-to-root / && \
bash -c ". /tmp/build/build-base.sh" && \
i need to learn more about this cliwrap modeYou will now have dnf and dracut.... It will wrap the rpm-ostree commands with the more familiar names
ahhhhh, cool
welp... after fixing all the little details in the script... initramfs WORKS
i guess that's what we have to do? 🤷♂️ i mean, it IS a better experience than rebuilding on the machine
That's how it starts
and the next thing you know
First hit from Kyle is always free lol
you've got steam and VR and LLMs layered into your image
This should only be done in hwe
only?
don't bluefin/bazzite skip hwe and do their own thing?
No as in don't do this main
100% agree
We do this also for some branding
yep
This is only helpful for some issues
well, it's helpful for pre-building tpm and nvidia support
and branding
not sure what else
Also surface needs its modules as well
right
i can toss this into hwe
are we doing it only for hwe-nvidia or also for surface ?
Might as well do all of our hwe images.
👍
We already have file tree for the different images
hmmm
well, the way i see it... it makes sense for surface and nvidia, but not asus or main
and... this would JUST be enabling nvidia and surface because adding tpm, etc is arguably another feature
reading the context here though https://github.com/ublue-os/hwe/issues/250
GitHub
Surface: Include kernel modules into initramfs in build-time, inste...
This should make things more reliable for Surface users. We can change surface-hardware-setup script to exclude initramfs-etc argument that would be leftover from this transition for some time, whi...
There is the argument that tpm and stuff is hwe
i agree ... i just think it's a distinct task, but heh maybe not
and... i see a fun new problem 🙂 maybe Firefox isn't the only thing with issues on this nvidia?
Chrome flatpak is NOT liking "Use graphics acceleration when available" enabled
stable tho
hahahah
man
i'm so glad we didn't release this a month ago
So, should we just nuke the gdm udev rule?
That will make sure that nvidia never runs into the no wayland situation
What blew up here?
Gnome not liking negativo17 555 drivers
Yeah, it seems like a vestigial rule anyway
If we are going to nuke that rule, I would propose we do it in main, so even that would benefit when running on VM’s
For the uninitiated, which is "the gdm udev rule", what does it do and how would removing it benefit us?
Sorry if it's obvious
/usr/lib/udev/rules.d/61-gdm.rules
GDM has a udev rules script that will block wayland given certain conditions. They are bizarre but make sense given thta gnome has been wayland first officially for years.
Honestly might want to hop on to gnome channels to see if there is any reason the rule is still therewisdom
Honestly I'm open to just deleting that
I mean they're going to remove the X11 session in 41, might as well take the Band-Aid off
If taking that away breaks someone's hardware it was going to break regardless
That's the spirit, our whole schtick is be the first to drop legacy tech asap. F1.
Yeah now people who are single GPU are also running into it.
The fact it blocks Wayland in multi-gpu circumstances is also bizarre
But even some bluefin users which have the initramfs built are also running into the issue
Welp. I think I've earned the award for the most Wayland + 555 issues.
X11 no longer an option in Gnome, GDM crashes when I try to reorder monitors Scrap that. I cannot use Wayland. These problems are on X11 with 555 🤦
X11 no longer an option in Gnome, GDM crashes when I try to reorder monitors Scrap that. I cannot use Wayland. These problems are on X11 with 555 🤦
Try removing the udev rule in the build.
I'm about to do a PR for that in main
Plasma doesn't have the same checks
I have a 30ish minute feedback loop. Would the rules be overwritten if I simply add an empty
/etc/udev/rules.d/61-gdm.rules? Thinking we can try this before waiting for all builds
It did something. But made things 100x worse. Saw you recommend a symlink to /dev/null. That might be better.Yeah. Basically the same idea
The empty file changed my display to what looks like 480p. Trying a symlink
😳
any luck?
Hold off on removing the udev rules. It breaks gdm
Back to 1024x768 after removing the file. Apps are opening on the wrong display too (which is blank), so difficult to debug
okay.
Here is the PR
https://github.com/ublue-os/main/pull/592
GitHub
fix: disable gdm's wayland checks by m2Giles · Pull Request #592 · ...
Thank you for contributing to the Universal Blue project!
Please read the Contributor's Guide before submitting a pull request.
Let me know if there's any information you want to help debug. But I can't copy and paste
oh wow
What nvidia card are you on?
3080
interesting. Optimus or desktop?
Desktop
Ah, so removing the file did fix the Wayland not appearing in GDM issue. X11 is the same with and without the udev rules - still can't change desktop order
Wayland is causing the 1024x768 single monitor resolution
Any requests for information before I revert my changes back to rpmfusion?
apparently you can't symlink to /dev/null in build time
so this solution won't work.
Robert, can you try the tmpfiles method before reverting your image?
Sorry, please could you elaborate?
GitHub
fix: disable gdm's wayland checks by m2Giles · Pull Request #592 · ...
For some nvidia users, gdm's udev rules prevent the wayland session from starting.
This provides an override to the file by symlinking the /etc location to /dev/null.
Note, @p5 has experien...
Instead of removing it, making the /dev/null symlink with tmpfiles.d
https://discord.com/channels/1072614816579063828/1087140903031943178/1256238611393806498
Seemed to work for these two
Will creating it in /etc/tmpfiles.d at runtime be a good enough test?
yepp
just make sure that the /usr/lib/udev/rules.d/61-gdm.rules is still on disk
since part of this is making sure the override works
Rebooting now. Rolled back and pinned to a deployment with that file still present, and created the tmpfiles.d entry in /etc/
Will let you know 🤞
Highly stupid question, how do I check the symlink worked? I can still cat the file and see the regular contents
ls -la /etc/udev/rules.d/
Ah, got it. I
catted the /usr/lib file 🤦
1 sec, testing WaylandNope. Still no Wayland option
WTF
can you try a reboot. I wonder if udev rules ran before the symlink was placed
I did reboot after adding the tmpfiles entry, but trying again
as in you did the entry. Then udev rules happened, and then tmpfiles service ran
Back to the terrible resolution. Maybe this is somehow expected? Do I just need to figure out how to change resolution without a gui, and I'm good?
maybe?
you can do
gnome-randrthat doesn't seem to exist. Only thing close is _xrandr but it seems pretty useless
Or is there a way to open gnome settings on a specific monitor?
if gnome-randr isn't there thats a must add to bluefin
what's happening with it opening on wrong monitor?
The other monitor is blank and my mouse cannot seem to find it on any edges
interesting.
can you go single head easily?
My WiFi now works though. For the first time in over a year
lol
Got settings open. Cannot change the resolution 😕
it's almost like it's VGA
WAIT
Graphics: Software Rendering
Windowing System: X11
???
What is happening?
nvidia-smi works and shows gnome processes
This makes zero sense
Is modeset set?
what image?
Custom and latest Bluefin 40. Tried both
Sorry, how can I check?
cat /sys/module/nvidia_drm/parameters/modeset
You should get a Y (will need root privs)
if it's set
the other parameter to check if /sys/module/nvidia_drm/parameters/fbdev which should also be a YBoth N on custom image. Rebooting to Bluefin again to check
modeset is a requirement for wayland
doing a 61-gdm.rules diff between bazzite testing and bluefin stable I get the exact same file. It was updated between 39 and 40
Ok.. will stay on Bluefin for the remainder of the testing.
Should be faster than switching
Both Y and no difference
Honestly, probably something wrong with my install and needs a reinstall.
Shouldn't be anything with secureboot being disabled on my machine? That's the only thing I can think of that's not normal
no secureboot if enabled and not having MOK enrolled would reject the kmods we build
if off, the kernel will load any .ko
There is nothing different in 61-gdm rules between bluefin-nvidia:stable and bazzite-gnome:testing
so it's likely another thing changed by rpmfusion
I'm half way through a clean install on a 1060 desktop. Since I'm the only one this happened to, I must have messed something up in my install
GitHub
GitHub - rpmfusion/nvidia-kmod: nvidia-kmod - nonfree
nvidia-kmod - nonfree. Contribute to rpmfusion/nvidia-kmod development by creating an account on GitHub.
rpm-fusion updated the kmod.spec to 555.58 release
https://github.com/rpmfusion/xorg-x11-drv-nvidia/blob/master/xorg-x11-drv-nvidia.spec
https://github.com/negativo17/nvidia-driver
GitHub
xorg-x11-drv-nvidia/xorg-x11-drv-nvidia.spec at master · rpmfusion/...
xorg-x11-drv-nvidia - nonfree. Contribute to rpmfusion/xorg-x11-drv-nvidia development by creating an account on GitHub.
GitHub
GitHub - negativo17/nvidia-driver: NVIDIA's proprietary display dri...
NVIDIA's proprietary display driver for NVIDIA graphic cards - negativo17/nvidia-driver
@Kyle Gospo @bsherman I'm leaning towards not moving to negativo17. We are clearly missing something on why it's working with RPMFusion Testing but Negativo17 is falling back to Xorg
this is why i wanted to test before merging 🙂
but yeah
Slightly unrelated, reverting the custom image to RPMFusion 550 has the correct modeset and other value
Installed Bluefin on a clean machine and running an update to get 555 now
yeah, RPMFusion is patching one of the header files in the rpmspec
https://github.com/rpmfusion/nvidia-kmod/blob/master/make_modeset_default.patch
While negativo is doing it via a conf file
https://github.com/negativo17/nvidia-kmod-common/blob/master/nvidia-modeset.conf
That config file looks like how we're already doing it in our images.
Ah, we're copying a nvidia-modeset.conf file from /etc/modprobe.d to /usr/lib/modprobe.d in the hwe install script
So was that file already present anyway in RPMFusion?
Bazzite isn't having this issue
as long as it's loaded in initramfs it works great
Thought there were some reports of missing X or Wayland? Or is that only main/bluefin
main/bluefin
We had them until I moved the modeset file to /usr
I believe bluefin has initramfs building? Is it not doing it for the nvidia builds?
pretty sure modeset is in bluefin
must be in /usr and must be wrapped up into initramfs so it loads early enough
the changes I made in the nvidia install script get everything in a good state for that
GitHub
hwe/nvidia-install.sh at main · ublue-os/hwe
Fedora variants with support for ASUS devices, Nvidia devices, and Surface laptops - ublue-os/hwe
yea that's wrong, don't do that
this whole section can be dropped
probably the issue
okay. Going to look in hwe
and then as long as line 58 above is present
and the initramfs is rebuilt after that script is run
you should be good
yeah, initramfs is one of the last things we do
main things for wayland on gnome were:
1: nvidia driver is loaded early
2: modeset is enabled (again, early)
as long as both were true it worked fine
load too late (ie, via the original location in /etc) and gdm won't do anything with it
okay.
Looking in bazzite, i see that there is still something for nouveau
https://github.com/ublue-os/bazzite/blob/main/system_files/desktop/shared/usr/lib/modprobe.d/nvidia.conf
This can be removed actually, I will do that now
this still needed?
only if you don't use fsync
only way to have amdgpu vulkan on those old gpus
This was my old nvidia.conf in /usr/lib
that's done by nvidia-modeset in negativo
GitHub
nvidia-kmod-common/nvidia-modeset.conf at master · negativo17/nvidi...
NVIDIA's proprietary driver kernel module common files - negativo17/nvidia-kmod-common
and then this one:
GitHub
nvidia-kmod-common/99-nvidia.conf at master · negativo17/nvidia-kmo...
NVIDIA's proprietary driver kernel module common files - negativo17/nvidia-kmod-common
is changed to instead add the drivers to initramfs
by the script in hwe
okay.
@M2 now you've gone full Kyle
but this should square us away?
you can drop the amd-legacy deletion too
it won't hurt nvidia users
okay
will delete that as well then
ok so you want me to hold off on review?
<--- red 5 standing by
https://discord.com/channels/1072614816579063828/1253638858940092500
^ bazzite testing thread for 555
lot of the same conversation here about GDM and black screens in KDE
Alright it's there
Confused on why our stuff was conflicting
since it was setting the same things
@j0rge
ok ready?
yeah
looking at script order, I feel like bootc should come before initramfs
just in case
okay nvidia-modeset is not in bluefin-nvidia but our nvidia.conf is
and the 99-nvidia-dracut.conf has omit drivers
GitHub
fix: remove conflicting nvidia initramfs files (#1458) · ublue-os/b...
The next generation Linux workstation, designed for reliability, performance, and sustainability. - fix: remove conflicting nvidia initramfs files (#1458) · ublue-os/bluefin@97c56f2
once this builds i'll look at it's contents
maybe we do hwe images for coreos since damn.... installing nvidia using the script pulls in a bunch of unneeded stuff.... guess I could just uninstall it
but this will definitely mean we will have to sort out HWE for for nvidia build
s
Would it not be easier doing CoreOS main images? Then we do not need the logic to install the correct kernel or install Nvidia in multiple places
What stuff?
akmods signing key
Ah
actually that stuff would be there no matter what
That stuff appears to be there in the image
I see nvidia-modeset.conf and 99-nvidia.conf with the correct items from hwe
nvidia-modeset.conf is in the initramfs
and the kernel modules are there as well. I see nvidia-drm, modeset, uvm, peermem, and nvidia
SUCCESS! Both Wayland and X11 sessions are working on the latest Bluefin
Plus my WiFi is working too! No idea how Wayland affects WiFi drivers
:happy_green_trees:
YEAH!!!!!
okay. So guessing we had conflicts in the files and since no one actually used wayland nvidia we didn't know
Now, what to do with HWE?
Or did it not matter since RPMFusion changed the defaults values anyway?
that one
hwe should just be + initramfs
and we're done w/ it
@Kyle Gospo @j0rge
thanks for staying on this, M2... I didn't have as much time as hoped.
Entrepreneurship.org
YouTube
The Importance of Execution - Jensen Huang (NVIDIA)
"Execution is critically important; it is better to have a simple idea that can be easily implemented rather than a complicated idea that has implementation challenges. Drastic changes do not have to be made overnight; it is a long road to success and each change need only take the company to the next step."
Thanks Jensen!
we live again to fight another day. 😄
ok to post the link to the thread in announcements?
figure I would link to the forum post
It hasn't merged for some reason
Grr
It's in the stupid stuck state.
Going to make a fresh PR. It's using the pre Nvidia swap over for some reason now
ack
Same issue as the kernel signer pr
but you likely saw this?
Yepp
yeah, bad state
the PR is clean, it's testing against the wrong branch i think
Yepp
just going to make a new PR
or merge main into the PR branch manually
i'm fine with this and will comment on PR to that effect
commented
Yeah, merge main into it didn't unstick it
and a fresh PR also isn't running
There is something funky going on. The synchronization just hit for the previous PR but failed
Okay.... it's just super delayed for some reason
but the checks are now running
closed duplicate PR
lazurite is busted
lazrurite 39 nvidia. Everything else was spurious errors
Asus 40 has kernel skew
@M2 yeah, seems both lazurite and asus-nvidia basically have kernel skew... i'm ok with a force merge
want me to push the button?
I'll take the heat for being the 🤠
force merged https://github.com/ublue-os/hwe/pull/258 and building hwe 40 & 39
ok, so with all these changes... now, i can test these images and make sure they work, but also... my downstream image should be able to use the same build-initramfs.sh script with no further custom file additions except to add tpm, and I'd be good... OR... we add tpm here, and we'll be good
Very nice
well, really, adding tpm to main and building the initramfs there would give us a reason to do it... and that would trickle down into this image, too
at that point, the only reason bluefin (and maybe bazzite) would need to rebuild their initramfs is for branding, right?
Right
But we also don't build from HWE
I just borrow the Nvidia script from it
bazzite doesn't, but i thought bluefin did
I believe so, that would be a trivial change if they want to match what I'm doing though
Then they're not wasting any storage space
Obviously they can't do that for anything but Nvidia though
ok, so i'll check and if we don't have it, create an issue to add the tpm dracut.conf file that you have in bazzite, to main.
But if we get fsync CoreOS the other hardware layers can disappear like they did in bazzite
If we do fsync coreOS that would replace a lot of images for us
let's start a new thread
for tpm?
for fsync kernels
k, go for it,
Both honestly
I am having a philosophical anxiety crisis over it
this sucks @M2 @Kyle Gospo
Wtf
Okay so it's not just stable
rpm -qa | grep nvidia
ahhh... akmods was slightly older
because we didn't rebuild before building hwe
Ohhhh
that's brutal
and i'm sorry, but family calls and I gotta step away
for about 4 hours maybe
pushed "go" on akmods rebuilds....
will probably need "main" and "hwe" rebuilds also/maybe
Yeah
And my coreOS one
ugh, this really makes me think again how much we just need our own yum/dnf repo
we still need
/rebuild world chatops too, hehBluefin for stable button press, hwe button press
Akmods good except for f39 coreos
I don’t know how to run new builds (other than reruns) from mobile app
I can click, what am I pushing
And I have bad signal. It’s up to y’all 🫡
GOT IT
WE'LL TAKE IT FROM HERE.
To be safe. I’d rebuild main.
And then hwe
wow, 36 minute run, we failed that builder lotto lol
bluefin-nividia:stable working
kicking off hwe, main is done
that 39 coreos runner is messed up, so we'll have to wait for that thing to time out, not sweating it, rebuilding everything else anyway
Not sure if this is the place but Firefox Wayland is already working.
yeah not 100% is back at crashing ...
The stable builds for bluefin should be green.
I'm strongly thinking we should turn off on push updates to stable/gts
And just button press if we need a rebuild off schedule
agree 100%, jfdi!
Yeah. That will be inbound this weekend
i'm home and can test something if helpful?
We're good. Got confirmation on bluefin and Aurora
Stable and latest
awesome!
i'll test for giggles and to get my own image working next 🙂
Thank you for the excellent effort!
But I'm strongly considering putting bluefin stable and GTS to weekly and making sure they are lined up with akmods/hwe.
And turning off on push builds. Scheduled builds and button presses
I'll post that on the forum after I'm done shootin
Universal Blue
Nvidia 555 drivers incoming, important information!
In case anyone is facing slow performance after updating, you need to disable the GSP firmware. You can check and see if your system is using the GSP firmware by doing nvidia-smi -q | grep -i gsp. If the output shows N/A you aren’t using the GSP firmware. If it does show a version you need to disable it by setting nvidia.NVreg_EnableGpuFirmware=...