AWe should try composefs
Nyou mean local layering?
KYeah
Bi dont think layering on client side is in plan for bootc at least every time i read it wasnt
Kdnf is supposed to provide it client side eventually
AIt is
ECan take a closer look later today but this sounds interesting and would love to help get things over the line
RIt is planned, but to start with, will just forward requests to rpm-ostree
KBut I don't think we can support it until that happens
KAt least not in Bazzite
Nnot to my knowledge no. The meeting you Antheas and I are having is to discuss rechunk with Red Hat.
AActivating a usroverlay might be a way to get fast layering
Nwe can. rpm-ostree and bootc can run side by side.
Nif any local layering is happening, it just needs to be done through rpm-ostree.
Bthats new then
KThat's doable today, but from that point on bootc can't do anything.
Nright, bootc would be vestigial until we can build the images using it and DNF features catch up.
Nit at least would be there.
KI feel like that complicates our updater then, I almost rather just not ship it until it's ready
Ntopgrade doesn't support bootc anyway.
NEither way, I'm not pushing us to use bootc right away in Bazzite, I'm more so trying to see if we can get some help upstream to make this stuff move along more quickly.
RThe idea is the RedHat folks need help working on the issues Noel shared so they can start tackling the more important things like local layering. It seems like there's a lack of headcount available
RAt the moment, they are working on bringing the existing images (FCOS, Atomic Desktops etc) as closely inline with the bootc base images as possible, without rebasing on the bootc images, hence the composefs changes
AWhat does the image have to do with composefs
GBefore we switch images to composefs we'll need to remove bind mounts
AWhat bind mounta
RBootc requires composefs (i believe).
Current atomic desktop images do not use composefs.
They are trying to make the atomic desktop images to look as much like bootc images as possible to minimize the number of changes when the final switch happens
Current atomic desktop images do not use composefs.
They are trying to make the atomic desktop images to look as much like bootc images as possible to minimize the number of changes when the final switch happens
GGitHub
Bazzite is a custom image built upon Fedora Atomic Desktops that brings the best of Linux gaming to all of your devices - including your favorite handheld. - ublue-os/bazzite
NI could be wrong on this, but composefs isn't required for bootc, it's more a nice to have? They want it for it's ability to help verify files on disk
GThis is just one of them
GThere's a couple others in bluefin and bazzite
RIt's enabled in the base image builds
https://gitlab.com/fedora/bootc/base-images/-/blob/main/tier-0/ostree.yaml#L13-14
https://gitlab.com/fedora/bootc/base-images/-/blob/main/tier-0/ostree.yaml#L13-14
AIf it takes 20s off the update size
AI'm up for it
AQueue the 200 proton bugs
AAfter rechunk this shouldn't be rewuired
APlz check gamescope has the correct perms
ACaps
AAt least it has the cap before it enters rechunk
AAnd every other file with caps works after rechunk
NI'd be curious if it still works even without composefs
Nwhat I was told by Dan Walsh was composefs is primarily used with a feature in the kernel to verify files on the disk to ensure they have not changed.
GI think bootc works without yes
GWe had it for a period of time on uBlue images
NOK, that's what I figured.
AYeah it enables verity on the base image
ASo the whole image is signed
Nit was. I'm not sure what happened there. @M2 and I enabled it and then we had to disable it for some reason. Then I kinda went on hiatus for a bit.
AThe iso broke
RGuys I installed bazzite os gnome on my msi claw and my controls and not working