This is why all we need to move to federated Gitea/foregjo asap /s
This is why all we need to move to federated Gitea/foregjo asap /s
XI hope Gitea Actions gets some quick development...
Xgood /s there, almost caught me agreeing
NIt sounds really fun in theory, but in practice, administrating your own git server + website + actions runner + whatever else gitea has doesn’t sound fun tbh
Bgitea is great for a homelab, or even a small business, (I use for both) but even finding people committed to maintaining the gitea and related services is not the the biggest problem... its cost and availability of infrastructure...
Its been discussed in discord and other places before, but Jorge covered it pretty well in the Brodie "Tech over Tea" interview yesterday...
Goals for this include "running it responsibly", "like a real OSS project with governance", and being "about the automation before the fancy features". Also, if github has problems, much bigger customers (who are paying top dollar for the service) are having the same issues, with more significant impact to their bottom line and their own customers.
We have the benefit of using microsoft/github for free (nearly free) CI, code hosting, communications, registry downloads, asset downloads. It's pretty amazing really.
Its been discussed in discord and other places before, but Jorge covered it pretty well in the Brodie "Tech over Tea" interview yesterday...
Goals for this include "running it responsibly", "like a real OSS project with governance", and being "about the automation before the fancy features". Also, if github has problems, much bigger customers (who are paying top dollar for the service) are having the same issues, with more significant impact to their bottom line and their own customers.
We have the benefit of using microsoft/github for free (nearly free) CI, code hosting, communications, registry downloads, asset downloads. It's pretty amazing really.
BAnd... I just saw "/s" and have to search what that means...
B"/s" is known as the sarcasm switchGot it.
Xabout the automation before the fancy featuresmfw the automation is the fancy feature
Bregardless, I'm still happy with what I wrote 
JGitHub
I recently moved to a custom image based on silverblue-main. Before that, it was an official ISO installation of Fedora Silverblue 36 updated to 38 and all those time, I had some level of Device Se...
Jnot sure on this one if someone wants to take a look
PI can't say I know much at all about that - but doing a quick check my now ublue laptop passes more of the security checks (if you copy the technical report from that dialog) compared to my plain fedora desktop (the desktop has been upgraded from fedora 35 or 36 compared to the fresh ublue install on my laptop, and the hardware is obviously different so not sure how much that affects thigns)
Bbased on what i just read if you have nvidia drivers you cant pass kernel verification but i could be wrong(quite a lot wrong)
PAlso sigh building extra kernel modules in the container build is not as easy as I was hoping. Or well, the compiling is fine, but getting depmod updated seems to be problematic since it wants to use the kernel of the actual machine running the build (which is whatever kernel the github action is running on, currently some azure 5.15 kernel, very different from the kernel I'm actually trying to deal with in the image)
Pand you can't do the depmod update on boot since /lib/modules isn't writable (though having it be done in the image would be better anyway IMO)
C
POh, may have figured it out. Maybe
PAh ok, yeah got the kernel modules working probably. Now just the issue of the xone firmware downloader which wants to write firmware to /lib/firmware which is obviously read only
Jcan you just extract the firmware and plop it in there?
PWell it would be possible to grab the firmware during image build - which is what I'd like to do in an ideal world - but I'm guessing that the firmware isn't necessarily redistributable as far as licensing goes; I'm assuming that's why xone is distributed with a script to fetch the firmware from MS.
PCurrent solution that I think is working: create a symlink from /lib/firmware/xow_dongle.bin to /usr/local/lib/firmware/xow_dongle.bin during image build, and then modify the download script to put the firmware in the latter location
POk, yep, elite controller on dongle is working! Haven't added the download script changes to my image yet but that should be easy
P@j0rge in case you're interested, my proof of concept of building xone as part of the image build is here: https://github.com/Pythoner6/ublue-custom/commit/705cdf5bc44aaefbc42464246e5dee52de30439e
PProbably a bit hacky and missing some things (like perhaps a better way of consuming the xone source code, or at least doing checksums on it etc). But functional at least for now.
PBeing able to do this IMO is a huge selling point of ublue for me. Now I don't have to worry about setting that up on any new machines, yay!
BHave you seen https://github.com/bsherman/ublue-kmods
GitHub
Vanilla Fedora immutable images with Nvidia and xbox drivers added - GitHub - bsherman/ublue-kmods: Vanilla Fedora immutable images with Nvidia and xbox drivers added
BWe ( ublue-os org ) also have an akmods repo that is prepped to start adding akmods builds.
BI’m definitely interested in other approaches and perspectives though.
Actually the pending changes in ublue-os/akmods aren’t by me but I expect to be working on it in next few days
Actually the pending changes in ublue-os/akmods aren’t by me but I expect to be working on it in next few days
BThe main feedback I have for you with respect to getting that added into ublue-main, we definitely want the akmod rpms rather than files added in ad hoc.
There was even some great work done to push our own ad hoc config files into rpm. Much clearer downstream to know where files come in the base images from when owned by rpm
There was even some great work done to push our own ad hoc config files into rpm. Much clearer downstream to know where files come in the base images from when owned by rpm
AThere is literally a flag for it:
So there is no reason to bring individual files in manually. Just telll it to build module X for kernel Y, and to put the RPMs in the output directory. Then install those RPMs with rpm-ostree. As long as all kernels are installed in the chroot build environment I think it will work.
Also for anyone curious "why not just call
So there is no reason to bring individual files in manually. Just telll it to build module X for kernel Y, and to put the RPMs in the output directory. Then install those RPMs with rpm-ostree.
As long as all kernels are installed in the chroot build environment I think it will work.Also for anyone curious "why not just call
akmodsakmodsakmodsbuildcat "$(which akmods)" | grep akmodsbuild -C10akmodsrpm-ostree install@pythoner6
BRight. Part of the issue is the linked change set doesn’t use akmods unless I overlooked it.
AYea if you mean pythoner's link, it was grabbing final files from some other repository instead of building them with akmods locally.
BYeah. I’m mobile. Harder to interact on phone.
PYes - totally understand that the way I'm doing it is perhaps not right for ublue proper. However I have some thoughts on why I wanted to do it the way I am, but about to head out, will try to put down my thoughts later
BTrying to hotspot. But for some reason discord won’t load messages while on my hotspot 
PNo I am compiling from source, just using the source directly instead of going through the extra layer of akmods
AOh okay. But akmods is the easy way. 
Leverage if you can. The solution you posted was pulling driver files from another image which is fragile.
Leverage if you can. The solution you posted was pulling driver files from another image which is fragile.PWill post my thoughts later when I have time
ALooking forward to hearing.
AIf anyone's interested in pursuing automated kmod RPM building, I added some extra info that helps at the bottom of the post:
💾ublue-dev
Any project that follows the akmod spec should be able to build, but I've only used it for NVIDIA drivers.
💾ublue-dev
Any project that follows the akmod spec should be able to build, but I've only used it for NVIDIA drivers.
BBthanks @j0rge
BAnd... another PR to avoid subshell/cosign from env... this feels like whack-a-mole, but surely this is the last one!
https://github.com/ublue-os/config/pull/37
https://github.com/ublue-os/config/pull/37
Jgotchu
POk so here's why I built the xone kernel module like I did.
First to start, my understanding is that the problems that both akmod and dkms are intended to solve is working with out of tree kernel modules - specifically that because you need to compile against a specific version of the kernel, and because even within a single distro people may be running different kernels, you can't necessarily just have these modules distributed prebuilt, so instead akmod and dkms distribute the source code for the kernel modules, and then when upgrading/switching kernels, they'll automatically recompile any kernel modules so that you always have a matching set of modules for your kernel.
This isn't really a problem with an image based distro if you're building these kernel modules into your image - because the image will have a known kernel version and you can just (when building the image) compile the kernel modules against the correct kernel. Therefore I don't see much benefit to using akmod or dkms in the first place - as long as you can still easily build and install the kernel modules, and at least for xone this is pretty trivial, though installing the files to the right place is slightly more work but only a few lines extra.
So the idea I had was to try building upstream xone directly as part of the image build.
First to start, my understanding is that the problems that both akmod and dkms are intended to solve is working with out of tree kernel modules - specifically that because you need to compile against a specific version of the kernel, and because even within a single distro people may be running different kernels, you can't necessarily just have these modules distributed prebuilt, so instead akmod and dkms distribute the source code for the kernel modules, and then when upgrading/switching kernels, they'll automatically recompile any kernel modules so that you always have a matching set of modules for your kernel.
This isn't really a problem with an image based distro if you're building these kernel modules into your image - because the image will have a known kernel version and you can just (when building the image) compile the kernel modules against the correct kernel. Therefore I don't see much benefit to using akmod or dkms in the first place - as long as you can still easily build and install the kernel modules, and at least for xone this is pretty trivial, though installing the files to the right place is slightly more work but only a few lines extra.
So the idea I had was to try building upstream xone directly as part of the image build.
PRe: @Arcitec
But akmods is the easy way.Tbh, comparing what I did in my build, vs say what bsherman did for his build I'm not convinced either way is that much easier or harder than the other - at least for the case of xone (perhaps some other project would be more than a oneliner to build)
The solution you posted was pulling driver files from another image which is fragile.To be clear about what my way is doing, it is a single Containerfile which uses multi stage build. First there's a
driverAnyway to be clear I do understand if others think it makes more sense to build things differently (esp for ublue proper) I just thought I'd try this way out and pitch in why I think it may have some merit.
BAppreciate the run down on your thoughts!
I completely agree being image-based provides different options that don't exist on a traditional distro. So arguably dkms/akmod wouldn't have been created/required if one was starting from image-based or trying to create a image-based distro.
And certainly, for personal learning, experimentation, or one's own custom downstream build of silverblue, ublue, or whatever... it's very cool to have the option for an alternative method.
I completely agree being image-based provides different options that don't exist on a traditional distro. So arguably dkms/akmod wouldn't have been created/required if one was starting from image-based or trying to create a image-based distro.
And certainly, for personal learning, experimentation, or one's own custom downstream build of silverblue, ublue, or whatever... it's very cool to have the option for an alternative method.
PYeah - I could easily see the dkms/akmod route being easier esp from a ublue perspective since that's more how current kernel modules are intended to be built (afaict) since without an image based distro it's a somewhat necessary solution. But for my custom image where I want that one kernel module, a few lines of bash are easy enough to manage (and fix if it breaks)
BYep