its something in-image, the action doesnt do anything special
its something in-image, the action doesnt do anything special
RWe didn't need to do any tricking or anything - it "just worked".
Perhaps you're changing something we're not?
Perhaps you're changing something we're not?
Rif anything we're doing less branding
Rhmm
Ryeah i thought it was os-release
Ri may have to read the image builder code smh
Tits kinda crazy we actually made this work LOL
TheliumOS also ran into that issue
Rlike.. our /etc/os-release modifications were "stolen" directly from bluefin, it should be identical 
Tman i think its /usr/lib/os-release?
R
Tthat absolutely looks like it
Rthey're identical
Rhmm
Tnvm we edited that on bluefin:lts too
Rmaybe it's because there's no def for fedora 41
Rbut there is for centos
R:thonk:
RRThis is where those defs are matched against
Ryeah, so bluefin should have the same issue
Ri think
Rsince osrelease id is "bluefin" for which there is no def
R
Tliterally that
JI just add a manifest on my fork of image builder lol. Seems crazy to have a list per OS in the public version of bib
R
I just add a manifest on my fork of image builder lol.
why didn't i think of this lmao
RI'd open an issue in the osbuild/bootc-image-builder repo. Requiring each distro or image that wants to use BIB to have a file in their repo isn't very scalable
JI did? Or maybe commented. They said they are happy to add more
R
Rsmall world
RCreated this to remind them and start a discussion
https://github.com/osbuild/bootc-image-builder/issues/816
https://github.com/osbuild/bootc-image-builder/issues/816
GitHub
Do we want to add manifests for all custom images? I can imageing the list becoming very long. Or should there be some way to pass it in to the build? Probably a bit of both; I see no real necessit...
JThe base image specifies a bib image it wants to use too, weird that it doesn't specify what OS it is https://gitlab.com/fedora/bootc/base-images/-/blob/main/fedora-bootc-config.json?ref_type=heads
AI ended up just making copies of the manifests locally and bind-mounting them into the container 
but yeah, it's a wild choice. even just being able to pass an option to specify "use this manifest" vs letting it try to auto-detect would be nice
but yeah, it's a wild choice. even just being able to pass an option to specify "use this manifest" vs letting it try to auto-detect would be nice
Othe UTF-8 error is fixed by rechunking with hhd-dev/rechunk
Owhy
Tprobably something changed
Tit does not get fixed specifically because of that tho, bluefin rechunks and it still got that issue
OI mean
Oit fixed it in the case of my image
Oif I remove the rechunk step, ostree deploys will always fail
Tits something in
ublue-os/main that is fucking it upOreally my image is just ublue base kinoite with some regular fedora packages added
OI know, I discussed this yesterday
Owith some of the other folks in here
Othat was when I came up with the hypothesis that the rechunking was the reason why aurora and bluefin weren't building failing isos
Obut like I had no real evidence for that at all
Oexcept, rechunking is the only way to make my ublue-os/main derived image work with ostree deploy
Ostrange stuff
