Noh I see, yours is a netinstall as well.
INo, actually. The isos are upstream AlmaLinux boot isos, with some configuration swapped out
NOH ok, so you're just editing the ISO and using a kickstart.
Nthis would make it a netinstaller here.
INSo one challenge you might find is that with a netinstall if your image gets any bigger, you will have install failures from users.
Nwe ran into that problem and ended up moving to: https://github.com/JasonN3/build-container-installer/
GitHub
Creates an ISO for installing a container image as an OS - JasonN3/build-container-installer
Nmakes your ISO quite a bit bigger, but it is fully offline.
Nyou can also declare your flatpaks as part of install.
Nrather than bundling them into the image itself.
IThat's very powerful
NIt's really helped us a TON.
NI really would love the netinstall option to have retries, but good luck with getting the Anaconda team to implement any features right now.
Nthey are BURIED.
IMy main concern with that approach is that the infrastructure will expand beyond mkksiso and podman, but I'm reaching the limits of that as is
NI love what you are doing here though, very cool stuff with bundling flatpaks as part of the image.
NI don't believe anyone had solved that problem (up to this point) yet that I was aware of.
Nyeah, I totally get that.
IIt might not be solved yet, I'm now finding that GNOME Software doesn't play nice with read only Flatpak installations 
Nworking on flatpaks themselves make me want to crawl into a hole and cry.
Ndocumentation is...
Nlackluster lol
Iflatpak-builder 
Nbut yeah man, as far as the Alma Linux or CentOS based images, it would just be cool to have that option with all the ublue sauce on them.
NNot exactly sure what @j0rge or anyone else had in mind though.
NWe don't do a ton of marketing around our main images like we used to just because they are really more build infrastructure than anything else.
NAt any rate, really glad to have you here @imbev. Always glad to see more folks in the space doing cool stuff!
IGlad to be here with you and the rest of this community! 
IFortunately the problem is a simple fix: Don't let GNOME Software or Flatpak be aware of the custom Flatpak installation
Bwell main images should be represented as images to base on not images to use anyway
J@imbev welcome!
Jyeah I'd love to have centos as a tag option in the main images. Like we have :latest, :40: 39, it's be nice to do :el10 or whatever so people can just use centos derived images downstream
Jbasically I also want to make a bluefin:lts that's bluefin but on centos.
Jyour stuff looks super cool, I wish more people were making images heh
IThat's certainly possible
IIs ublue infrastructure compatible with bootc yet?
Xublue actually shipped bootc for a moment a while back, but i believe it caused some issue and had to be reverted
Xin my own testing, though, it worked perfectly
ABroke the ISOs
AAnaconda moment
Jyeah we can move to bootc, the biggest issue is waiting for fedora bootc images but looks like the EL folks got those rolling faster than fedora
IThe main obstacle that I see right now is the lack of integration with GNOME Software and the rest of the GUI package managers
Kwe remove rpm-ostree integration from GNOME software today
Knot really an obstacle
Kit slows it down to a crawl and makes it into a terrible experience when it's present
IIn that case, I don't see why it wouldn't work
IThe Fedora images are being produced, however the F40 image is not regularly built IIRC. There are a few projects building personal Fedora bootc images
IIf you take a look at https://github.com/AlmaLinux/bootc-images, it's not too difficult to build a base image
Atheres no such thing as a "bootc" base image yet, if you look under those images you can see theres a little ostree commit in there made by rpm-ostree
