Bthanks @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 aLeverage if you can.
makeThe 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
BI 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.
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.
BAdding 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.
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.
MApologies 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.
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
Learn what software is needed to use other OSes and install them
AFedora uses power-profile-daemon
AThe 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
That said there’s nothing stopping anyone from creating a custom System76 image with everything loaded
AThe dkms stuff would need some work
Ddkms is not supported on ostree fedora anyway
AProbably 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
Jis 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?
Jcuz I can go either way, the user wouldn't notice anything
Bthe 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
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
A@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.recipe.yml - 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
./etc/profile.d
AI'm also undecided whether we should install the minimalistic
Pros:
/etc/profile.dPros:
- 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.~/.config/autostart
- 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".
BMy thoughts are pretty similar to @akdev's ... While it would be great to enable provide all the system76 stuff in ublue-os/main ... I think their choice of distribution/tooling doesn't generally mesh well with ublue / Silverblue.
That said, if there was someone with System76 hardware who really wanted to tackle this, I think it could be a great community image, built downstream, even hosted within the ublue-os org, like a sister to
That said, if there was someone with System76 hardware who really wanted to tackle this, I think it could be a great community image, built downstream, even hosted within the ublue-os org, like a sister to
bluefin
Bthis is still scoped to
(btw, did you see my response in discussions?)
startingpoint(btw, did you see my response in discussions?)
MCompletely understand, if I end up getting into ublue, then I'll have to consider it.
AYeah it's the startingpoint repo, which is the only one that auto-starts yafti at the moment. It's super fragile at the moment, so all these changes are necessary. It seems like a solid plan to me but perhaps I'm missing some small change that could make it even better.
AOh you responded to the restructuring discussion? I'll check now
AI read, that sounds great. And yeah don't burn yourself out. We don't need to move everything at once. One small file at a time is enough.
AI'll reply there now though
BI should clarify... when I say "sister to bluefi" I don't even mean as opinionated and stylized as bluefin... though, it could be what you want it to be
I should probably say more like a sister to
The idea in my head, it
Another thought... if we could work with System76 to adjust how they do this (eg, use akmod instead of kmod) and maybe host a repo of RPM packages instead of requiring a lot of local
I should probably say more like a sister to
startingpointnvidiamainThe idea in my head, it
ublue-os/system76Another thought... if we could work with System76 to adjust how they do this (eg, use akmod instead of kmod) and maybe host a repo of RPM packages instead of requiring a lot of local
makemainyeah, nutshell summary of my thoughts... what I see in your proposals is cleanup, standardization, forward looking for automation and subsequent projects to have a good pattern to follow. good stuff.
But also, I'm happy the custom first boot stuff is staying in starting point for the moment.
But also, I'm happy the custom first boot stuff is staying in starting point for the moment.
BIf we (community) want to get more opinionated with
mainmain/nvidiaI think I got ya. If I was going to focus on one, I'd want to work on something for my capture PC first. Needs a driver that doesn't belong in main but that I would need to run ublue on a pc I would use for capturing. Maybe a "creator" edition or something. Time will tell. Long ways to go before I'm anywhere ready to try it haha.
Bif the driver is available as akmod, maybe it could go in main 
we do want some hardware enablement there, it's just a bit vague as still only do that via udev rules and nvidia
we do want some hardware enablement there, it's just a bit vague as still only do that via udev rules and nvidiaMI don't think it is haha. But that may be something I have to look at. I have been installing via dkms. Don't think it would ever be a fit for main haha.
Edit: I believe the source is available at least.
Edit: I believe the source is available at least.
AI totally agree with you on that. Firstboot being the "scriptable/hackable" one, and main + nvidia being the "clean cores" is a great setup.
The way I've been modernizing
The only thing missing is a way to create a
Example:
I dunno if it's worth pursuing such a feature to make it possible to move main + nvidia to the same system as startingpoint though. It'd be nice for users but not sure if there's value for us.
The way I've been modernizing
startingpointThe only thing missing is a way to create a
recipe.ymlExample:
vauxite-recipe.yml: runs scripts/vauxite/*.shI dunno if it's worth pursuing such a feature to make it possible to move main + nvidia to the same system as startingpoint though. It'd be nice for users but not sure if there's value for us.
Bit is in the back of my head to solve the dkms build problem... i started once, but life is busy... there are definitely a few things out there we need...
and I will say, I have built dkms for silverblue OCI, but my roadblock was getting the secure boot signing done... and for ublue specific, we need it to work for all users...
so, priorities... getting akmods done first, then eventually solving the dkms issues.
and I will say, I have built dkms for silverblue OCI, but my roadblock was getting the secure boot signing done... and for ublue specific, we need it to work for all users...
so, priorities... getting akmods done first, then eventually solving the dkms issues.
B
for all but the question at the end LOL. i'm not sure what you mean by moving "main+ nvidia" to the same system as starting point?AIt was created to be flexible but wasn't made with main+nvidia in mind. It could be improved on that front but it would already be really easy to do. Example:
- Every image would run all scripts in
andscripts/pre/*.shscripts/post/*.sh
: Also runsvauxite-recipe.yml
which in turn runsvauxite.sh
, which would cause it to execute every script inautostart.sh vauxite/${SCRIPT_MODE}
andscripts/vauxite/pre/*.sh
at the appropriate stages.scripts/vauxite/post/*.sh
ABut it's such a lofty idea that I didn't even plan it! I am not sure I even like it.
AEverything you've currently automated in main+nvidia could definitely be ported to this.
ABut what's the value of doing that? Beyond having to maintain only 1 system.
A
BI think i'm tracking with you. But I think we definitely just do the cleanup/standardization stuff you've suggested first... and you can make these types of improvements in starting point... and if we then see value after you have it smoothed out there, it could be a discussion/proposal on making the change to main
AYeah. I am just asking your thoughts since I am not sure I like the idea at all. Just saying that it's possible. But yeah, time to focus on smoothing out the standardization first!
But yeah, time to focus on smoothing out the standardization first!
FFI don't think that having tons of variants in 1 ISO is a good idea.
FOh, build system
FNothing, ignore
AHaha yes it's just the build system.