Also sigh building extra kernel modules in the container build is not as easy as I was hoping. Or

Also 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)

pythoner6OP•5/11/23, 7:47 PM

and 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)

Cup•5/11/23, 7:58 PM

Ppythoner6 Also *sigh* building extra kernel modules in the container build is not as easy ...

pythoner6OP•5/11/23, 7:59 PM

Oh, may have figured it out. Maybe

pythoner6OP•5/11/23, 8:08 PM

Ah 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

j0rge•5/11/23, 8:25 PM

can you just extract the firmware and plop it in there?

pythoner6OP•5/11/23, 8:32 PM

Well 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.

pythoner6OP•5/11/23, 8:33 PM

Current 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

pythoner6OP•5/11/23, 8:38 PM

Ok, yep, elite controller on dongle is working! Haven't added the download script changes to my image yet but that should be easy

pythoner6OP•5/11/23, 9:00 PM

@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

pythoner6OP•5/11/23, 9:00 PM

Probably 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.

pythoner6OP•5/11/23, 9:02 PM

Being 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!

Ppythoner6 Ah ok, yeah got the kernel modules working probably. Now just the issue of the x...

bsherman•5/11/23, 9:19 PM

Have you seen https://github.com/bsherman/ublue-kmods

GitHub

GitHub - bsherman/ublue-kmods: Vanilla Fedora immutable images with...

Vanilla Fedora immutable images with Nvidia and xbox drivers added - GitHub - bsherman/ublue-kmods: Vanilla Fedora immutable images with Nvidia and xbox drivers added

bsherman•5/11/23, 9:20 PM

We ( ublue-os org ) also have an akmods repo that is prepped to start adding akmods builds.

bsherman•5/11/23, 9:22 PM

I’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

Ppythoner6 @j0rge in case you're interested, my proof of concept of building xone as part o...

bsherman•5/11/23, 9:24 PM

The 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

Bbsherman The main feedback I have for you with respect to getting that added into ublue-m...

Arcitec•5/11/23, 9:41 PM

There 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

akmods

akmods

instead?", because

akmods

akmods

is just a wrapper around which attempts to build and then INSTALL the RPMs which won't work on rpm-ostree. So do to read how

akmods

akmods

runs the build tool, and then install the RPMs manually with

rpm-ostree install

rpm-ostree install

Arcitec•5/11/23, 9:42 PM

@pythoner6

AArcitec There is literally a flag for it: ```sh akmodsbuild -k <kernels> -o <folder> ...

bsherman•5/11/23, 9:44 PM

Right. Part of the issue is the linked change set doesn’t use akmods unless I overlooked it.

Bbsherman Right. Part of the issue is the linked change set doesn’t use akmods unless I ov...

Arcitec•5/11/23, 9:45 PM

Yea if you mean pythoner's link, it was grabbing final files from some other repository instead of building them with akmods locally.

bsherman•5/11/23, 9:45 PM

Yeah. I’m mobile. Harder to interact on phone.

pythoner6OP•5/11/23, 9:45 PM

Yes - 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

bsherman•5/11/23, 9:45 PM

Trying to hotspot. But for some reason discord won’t load messages while on my hotspot

AArcitec Yea if you mean pythoner's link, it was grabbing final files from some other rep...

pythoner6OP•5/11/23, 9:46 PM

No I am compiling from source, just using the source directly instead of going through the extra layer of akmods

Ppythoner6 No I am compiling from source, just using the source directly instead of going t...

Arcitec•5/11/23, 9:47 PM

Oh 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.

pythoner6OP•5/11/23, 9:47 PM

Will post my thoughts later when I have time

Arcitec•5/11/23, 9:48 PM

Looking forward to hearing.

Arcitec•5/11/23, 9:52 PM

If 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.

bsherman•5/12/23, 12:53 AM

Can I get a PR approve here plz? https://github.com/ublue-os/config/pull/35

Bbsherman Can I get a PR approve here plz? https://github.com/ublue-os/config/pull/35

bsherman•5/12/23, 1:59 AM

thanks @j0rge

bsherman•5/12/23, 2:01 AM

And... 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

GitHub

chore(ci): refactor: avoid subshell, sign image with env. var, rest...

j0rge•5/12/23, 2:03 AM

gotchu

pythoner6OP•5/12/23, 2:04 AM

Ok 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.

pythoner6OP•5/12/23, 2:04 AM

Re: @Arcitec

But akmods is the easy way. Leverage if you can.

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

make

make

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

driver

driver

stage that builds the kernel modules - straight from the upstream source code. This stage is based on ublue main. Then later I install the resulting artifacts into the actual output stage image - this is also based on ublue main and hence should have exactly the same kernel (except perhaps if there's some way for things to have changed during the run, but that would be a solvable problem and as I mentioned this was mostly a proof of concept).

pythoner6OP•5/12/23, 2:08 AM

Anyway 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.

Ppythoner6 Anyway to be clear I do understand if others think it makes more sense to build ...

bsherman•5/12/23, 2:11 AM

Appreciate 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.

pythoner6OP•5/12/23, 2:14 AM

Yeah - 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)

bsherman•5/12/23, 2:14 AM

Yep

bsherman•5/12/23, 2:21 AM

I try to go back and re-read the uBlue scope and values sometimes to see if my ideas fit, or, if i have an idea which doesn't, maybe it's good to challenge the scope.

But keeping that in mind, if uBlue WERE trying to be it's own distro, that's where I see more room for a different approach for kernel mods, etc... but we really don't want to be a full distro, rather Silverblue enablement. Add the stuff Fedora can't or won't to make life better for users, but that maintains a need to stay pretty tight to how a Fedora Silverblue system would typically be used.

I'm pretty sure you already see that, but thats the perspective I'm coming from as I push for akmods. They are the only "accepted" way of adhoc kmod additions on Silverblue officially/semi-officially at the moment. And... for better or worse, given our choice to use RPMFusion for Nvidia, we are very much tied to RPMFusion, and they provide quite a few akmods, too.

bsherman•5/12/23, 2:26 AM

Adding akmods has been a major desire of mine since I first jumped into playing with ublue myself... I had to go look... I think i started building my custom images beginning of February. And pretty quickly I was trying to see how we could get them added to ublue-main... it feels like we hit a bit of a lull in other important stuff which was needing to happen before we could tackle it, so I'm excited to get it done now.

Actually, it's mostly done... @iwantmynumberback put a great start together in March. I think there are few tweaks to get things merged in and we'll at least have the framework, so adding new ones would be easy.

Michael•5/12/23, 12:40 PM

Apologies if this doesn't fit here

I was curious if any of the system 76 stuff was considered for being included:

https://support.system76.com/articles/system76-software/

The power management stuff could be useful though it looks like you'd have to install some drivers for certain hardware. As far as I understand the power management tool works for other hardware.

I have a thelio to setup at some point, not sure if it'll be ublue or not.

I'm am guessing currently this isn't included, but just wanted to point it out.

If this should be posted elsewhere, please let me know where.

System76 Support

System76 Software (Install - Other Operating Systems)

Learn what software is needed to use other OSes and install them

akdev•5/12/23, 1:33 PM

Fedora uses power-profile-daemon

akdev•5/12/23, 1:34 PM

The rest of the stuff there seems very opinionated and not really what we want to do with ublue

That said there’s nothing stopping anyone from creating a custom System76 image with everything loaded

akdev•5/12/23, 1:34 PM

The dkms stuff would need some work

dreamyuki•5/12/23, 1:37 PM

dkms is not supported on ostree fedora anyway

akdev•5/12/23, 1:38 PM

Probably easier to do what the person above did with xone, just build the driver statically from source and ship the drivers in the final image

j0rge•5/12/23, 4:06 PM

is it worth discussing shipping the xone thing that way and then swapping it out later or do we want to err on the side of consistency?

j0rge•5/12/23, 4:07 PM

cuz I can go either way, the user wouldn't notice anything

bsherman•5/12/23, 4:14 PM

the akmods work is basically done in March, the PR was just too big and had extra stuff that caused some heartburn.

I reached out to David last night about it, but if he doesn't respond on it, i'll probably just branch the PR to make corrections

Arcitec•5/12/23, 4:22 PM

@hermmm I am working on the new firstboot system to make the following changes:

Yafti can now be disabled in so that it isn't installed and won't auto-run anymore.
Fixing the bug/issue where the autostart script is never updated again after being installed for a user, thus never updating itself in the future. Users currently have stale scripts.
Making sure the autostart script is immutable so that users cannot mess with it (we will use symlinks to immutable locations).
Minimizing the mutable surface, but I cannot think of any ways to get rid of it entirely. So there will still be a mutable file in .

This is the plan so far. I've implemented plenty of it so far, but am interested in hearing if anyone has other ideas.

Arcitec•5/12/23, 4:27 PM

I'm also undecided whether we should install the minimalistic script even if yafti is disabled.

Pros:

We could make it auto-delete the stale link if yafti is disabled. So if user jumps between ublue versions that disabled yafti, they won't have the leftover link.

Cons:

Someone might not like having a script there at all times even if its only purpose is "if yafti enabled, ensure symlink, else delete symlink".

I think the pros outweigh the cons. Thoughts?

Also *sigh* building extra kernel modules in the container build is not as easy as I was hoping. Or

Also sigh building extra kernel modules in the container build is not as easy as I was hoping. Or