GI'd rather avoid it, especially because I want to use TPM for disk encryption in the future
Byeah, I was mostly joking. I have secure boot, mostly for TPM disk decrypt, too.
Bseriously, the key loading is a problem for anything secureboot which is not trusted by microsoft (basically)
GIMO we should avoid putting kernel modules in main, save for nvidia
AWe should add your script to bluefin
ASome people seemed interested
Bmine? feel free
AI was looking into that setup but using my yubikey
Bor i can
AI think we need to install some package for dracut u2f
BI agree its a gray area. But the community did agree on it in the past, and it fits scope to some degree
https://universal-blue.org/scope/ since it enables hardware that Fedora won't.
I believe it's MUCH worse to face a "broken system" due to not enrolling the Ublue MOK for nvidia than for a game controller... So, I'm not too worried about it for now.
https://universal-blue.org/scope/ since it enables hardware that Fedora won't.
I believe it's MUCH worse to face a "broken system" due to not enrolling the Ublue MOK for nvidia than for a game controller... So, I'm not too worried about it for now.
BIts sadly just the cost of secureboot.
GKernel modules MUST NOT be included, they are added to ublue-os/akmods.?
Bthat meant not built in the repo, but could be clarified
GAh
GYeah, I understand, I'd just rather not have to enroll the key when my controller already works without the modules
BBut yeah, we do have some trouble where either becasue the kmods are signed and not loading, or the controller doesn't like our driver, it causes issues... so, I question the decision, too, even though i was part of it. The bigger issue is I'd want a good plan before REMOVING something.
I do know the akmods repo needs to be better documented... i've filed issues for it so I don't forget, but anyone can help with it.
So one idea would be:
I do know the akmods repo needs to be better documented... i've filed issues for it so I don't forget, but anyone can help with it.
So one idea would be:
- make sure akmods repo is well documented on how users can include any of those individual drivers in their custom repos
- remove the game controller drivers from
(would still leave the v4l driver, i think)*-main - add those game controller drivers to bluefine/bazzite
GMakes sense
BI should be clear, I'm not very sympathetic to the "i don't like enrolling a secure boot MOK" 
but i'm very sympathetic to pre-installing things that can cause trouble, specifically that seems to be the xone/xpad-noone driver compo
but i'm very sympathetic to pre-installing things that can cause trouble, specifically that seems to be the xone/xpad-noone driver compoBand I'm also biased to as few additions to main as possible
Bthat's been a learned bias though, as I more and more see main as the foundation of a toolkit, and... anything added is difficult/impossible to remove downstream
JI wouldn't say it's a bias, that's just how you're supposed to do it. 
WWhat is the status of Forge? I was listening to a podcast yesterday that was talking about Gitea beginning the process of trying to 1:1 github actions and it made me think "huh, I wanna have my ublue running entirely self hosted, maybe this'll work"
Whttps://docs.gitea.com/next/usage/actions/overview I'd love to look into it, and maybe help push forge along if it fits
Starting with Gitea 1.19, Gitea Actions are available as a built-in CI/CD solution.
Jsomeone needs to try it and see if it works.
WI'm down. On the "vision" I won't be doing 4 though
PXE boot the clients, select ublue in the menuso this looks like it'd be deployed via podman cluster?
Wok, so ucore VM
WReally I just want to in house my image creation
Jit should run on any linux with podman or docker iirc
WIs it a single container? Cause if so, I'll just attempt to throw it in the mix on unraid
Wif its orchastrating multiple containers I may throw a VM at it for testing
JGitHub
On-prem Universal Blue. Contribute to ublue-os/forge development by creating an account on GitHub.
Jit's a few
Wyea, I'll just spin up a VM to test it in
Wkeep it contained
BI use gitea for git and their actions with act_runner for CI builds and as a container registry...
i can tell you that the buildah actions we use today don't work on act_runner, but could almost certainly be swapped out for docker's builder action (and still probably run against podman, if you like)
i can tell you that the buildah actions we use today don't work on act_runner, but could almost certainly be swapped out for docker's builder action (and still probably run against podman, if you like)
WHonestly if Forge does what it advertises (and if it doesn't, I bet its way further along than me starting from scratch) I think its probably the better starting point than trying to slam gitea in
W¯\_(ツ)_/¯
Wbut that conversation made me really curious to get it all building locally
WEspecially since I'll have multiple machines on the same image, save internet bandwidth
Whave it build locally then distribute to the entire house
Byea, i'd like to build locally too... i'd kinda like to get the workflows setup so theyd run on either github or gitea if possible
Bthis is related
BI saw an interesting post by Walters today: https://github.com/coreos/fedora-coreos-tracker/issues/1263#issuecomment-1680999863
The important line is:
Got me thinking, having frequent upgrades of ucore/ublue is great, but the best way to gate them is to install from a local mirror, and then I choose when I want to sync the mirror with ghcr... it not only provides a buffer between build and install, but saves bandwidth for those are are running ublue/ucore on multiple systems.
The important line is:
[Users can] mirror the OS update containers on their own to a registry and update it on their own timeframe and schedule. Which is what they already need to know how to do for application containers!the context is replacing zincati/simplifying its function and instead of having complexity, managing things in a better way.
Got me thinking, having frequent upgrades of ucore/ublue is great, but the best way to gate them is to install from a local mirror, and then I choose when I want to sync the mirror with ghcr... it not only provides a buffer between build and install, but saves bandwidth for those are are running ublue/ucore on multiple systems.
Wyea, read that
Bso, even if building in github, could just mirror to a local container registry
WMy inclination, at least with some of this, is to get it off of github
WPersonally I don't love the idea of "hey, my entire system configuration is in a public repo"
Wthe tradeoffs right now are totally in the "worth it" camp, but if I can help get it to where its entirely onprem I'll happily be a guinea pig.
