Jthis would still be very useful for bazzite, bluefin, custom images etc. where having one ISO makes sense
Jstill though, if 19 ISOs come out of an action I'd love to see that just to see it lol
Jand also github has a releases file size limit, so we'd have to find another way to distribute them
ADo like akmods and put the iso inside a container I guess
JI can get donated CDN bandwidth too, but that can come later
Jif we can figure out more reliable ISOs with the new installer it would immediately fix the least reliable part of the project. 
AYeah we need to get off the business of binary patching fedora ISOs...
Gthey are switching to osbuild though
Gat least there's a proposal to switch osbuild on workstation
AYeah
AAll we really need is to generate a boot iso with custom grub and kickstart file
For offline installers we'd have to replicate the fedora process
For offline installers we'd have to replicate the fedora process
Jare you checking out osbuild? it's been on my todo but I'm about to start travelling a bunch for work and my free time is going away
Git looks really easy to make a simple netinstall image
Gthis was the command
ADoes that require an ostree repo?
Goh
Git might
Git shouldn't, since they are switching to OCI in Fedora 39
BI'm looking into https://github.com/ublue-os/config/issues/26 regarding adjusting the timers for both flatpak update timers and rpm-ostreed-automatic timer
BI want to add our own copy of
/usr/lib/systemd/system/rpm-ostreed-automatic.timer but it's owned by the rpm-ostreecurrently we just enable it here https://github.com/ublue-os/main/blob/main/post-install.sh#L5
Bi think i'll add a copy of what we want in our version in the ublue-os-update-services RPM at
/usr/share/ublue-os/update-services/etc/systemd/system/rpm-ostreed-automatic.timer and then copy it into place and enable it just like we already do here https://github.com/ublue-os/main/blob/main/post-install.sh#L5-L10G@j0rge looked at the github issue and found this comment: https://github.com/coreos/fedora-coreos-tracker/issues/1151#issuecomment-1351656773
GitHub
This is touched on in https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md#use-of-coreos-diskboot-images Basically I think our default stance is that admins use our golden images ...
Gtrying the command now
Goh ok
Gso we don't have
coreos-installGinteresting
Gbootc seems like it could also be usedGbut we need to enable a COPR or figure out cargo
G@akdev thoughts on this?
AThere’s probably a copr for bootc would be my guess because the entire dev team runs fedora afaik
ABut that is a whole other can of beans
Gyeah there's a COPR for bootc
Athat’s not compatible with rpm-ostree
Gwe can also use
coreos-installer which is available in the reposGall this is kinda over my head though lol
AAnd it is not clear if it will reach Fedora directly or will just be incorporated into dnf image
Acoreos-installer works only for coreos because it writes ignition configuration into the installer media
Goh
G
Gso basically that just leaves osbuild, lorax, and mksiso, etc
AWe could drop the CD compatibility and just build a raw image
ALorax and osbuild are the only options mkksiso doesn’t work for our purposes
AThe isogenerator script is basically an attempt to replicate what mkksiso is doing
ABut we process an already well formed ISO so we need to do a lot of dancing around to try and not break the bootable parts of the iso
GWdym?
ABasically just create an image that is suitable for usage as USB
ABut not able to flashed to a CD
Ghuh
