yeah, that would be my next thing. If nvidia-smi is working you should have working cuda
yeah, that would be my next thing. If nvidia-smi is working you should have working cuda
Nfun little update
![[[xenofembutch]]](https://cdn.discordapp.com/avatars/423616003117940747/c812f8002fc4f9134b5fae4b05e815ca.webp?size=40)
[that's what I'd expect...
![[[xenofembutch]]](https://cdn.discordapp.com/avatars/423616003117940747/c812f8002fc4f9134b5fae4b05e815ca.webp?size=16)
[but I'd also really like to actually get this working in regular containers, because I want to be able to use an OS of my choice, and also continue with my "all in one development container" lifestyle
[where is the code for the nvidia enablement systemd service that's supposed to inject the nvidia libraries into distroboxes?
[just so I can see what it's (supposed) to be doing
[also, where are the libraries supposed to be installed, so i can manually check on that
NUpgrading the Download Page a bit
MFor brew, it's highly likely that the user will be UID/GID 1000, we could install it out on image or have a systemd oneshot that sets it up on first boot
Jkyle tried a oneshot but we never got it working right
MInteresting. I'll spin up a VM at some point to try something.
Djust curious, but why aren't there instructions to rebase to the signed image there or on the other main download pages?
Tyou can't rebase to a signed ublue image from the regular fedora atomic images
Tand if you're rebasing from another signed ublue image then aurora, bluefin, and bazzite will sign the image anyways
Dyeah, i was just surprised because the way i found out about the signed images was from someone on here and not the website since it wasn't mentioned anywhere
Twell they should auto-sign the images upon first-boot
Doh, so is there not much point to using the pre-signed ones?
KLong gone now, instead the ISOs install images already signed
KAnd then it's an exercise for the user for rebase use cases
KWe had that as a stop gap before we had a proper installer
Toh
K@Emi just means you need to rebase twice
KOnce to your image unsigned, then again signed
Ti can't keep up with the changes anymore 
Dthat much i understand, but i think it would be helpful for that info to be more easily available to new users if it's important
Di don't really understand exactly why it's important, but it seems to be something users are advised to do that wasn't apparent to me through the website or docs
Di might be misunderstanding so correct me if I'm wrong
KYou only need to do something if you're rebasing
KIf you use our installers you are perfectly fine out of the box
KIt's why the rebasing documentation is a little buried, it's not the recommended way
DThat makes sense
DI still think it would make sense if that was mentioned somewhere for people who do rebase, considering the first part of rebasing is listed on the download page but not the second part. Or even if it's just in docs (if it is there I haven't found it). But I won't bug you any more about it.
Jhttps://github.com/ublue-os/config/issues/251 if we do this people wouln't have to remember their image anymore, they can toggle version, nvidia, and dx
Fif there are multiple users, than GID is not 1000, right?
MMultiple users or if a user specifies a different UID/GID at install.
However default is 1000/1000. Just trying to make this more convenient
However default is 1000/1000. Just trying to make this more convenient
DGitHub
Describe the bug Trying to rebase an existing SB39 to SB40 fails to boot showing vmlinuz-6.8.1-300.fc40.x86.x64 has invalid signature. you need to load the kernel first on an Thinkpad T495. I was n...
DI had a doubt , i don't seem to be affected by this even though I'm on the latest kernel and on Silverblue
DI didn't know the bootloader version moves so fast , i thought it stays relatively static and dosent change much
DSo fedora dosent update the bootloader when it does regular updates?
Jwe've been watching this (travier gave us a heads up) but haven't seen anything reported yet for a ublue-image
EThat's a relief. I haven't had anything pop up on my end following a couple rebases to 40
I have a slightly extended weekend - where are things hurting the most?
I have a slightly extended weekend - where are things hurting the most?
JI think mostly just prepping bazzite for 40
JRPMs, etc.
Jhttps://github.com/ublue-os/akmods/pull/168 not sure the status of rpmfusion on this one
EI'll take a look 
BThat PR should just merge, but only after the package is promoted in rpmfusion, thus providing a clean build
EGotcha. I had retriggered the builds but then looking over at RPM Fusion - I'm not seeing it there. I noticed your link points to F39. Did they withdraw it?
Bno, it's never been in F39 updates, only their release... the update will show up when the new version is promoted
EMy bad, thanks for clarifying
Bit's all good
Banother detail, this tag will switch from "f39-free-updates-testing" to just "f39-free-updates" when promote
https://koji.rpmfusion.org/koji/buildinfo?buildID=28538
https://koji.rpmfusion.org/koji/buildinfo?buildID=28538
