Composefs-native backend #1314

Johan-Liebert1 · 2025-05-13T07:47:00Z

A draft for installing and booting using composefs-rs.

Works with install to-disk with --composefs-native option
Works with install to-filesystem with --composefs-native option
Implementation for bootc status
Implementation for bootc switch, bootc upgrade and bootc rollback. Some edge cases need handling, such as rolling back while a deployment is staged. Currently staged deployment WILL be booted on the next reboot regardless of rolling back.

TODO

Service similar to ostree-finalize, say composefs-native-finalize which will be responsible for atomically swapping staged and current boot entries among other things.
/etc merge
systemd-boot integration

Issues:

Issue with transport type continers-storage, viz, #117. Needs some ironing out. Done
Bootc images need rebuilding with composfs-rs components, namely composfs-setup-root

I have a few logs being logged as warning, just for visibility. Will remove them when it's ready.
Same with composefs-rs patch in cargo.toml

cgwalters

Thanks for working on this!!

cgwalters · 2025-05-13T10:23:04Z

lib/src/install.rs

+        .create_dir_all("composefs")
+        .context("Creating dir 'composefs'")?;
+
+    tracing::warn!("STATE: {state:#?}");


I'd recommend dbg! for this type of stuff; it will build locally but not pass CI so it can't be accidentally merged.

I intend to remove all these logs. They were only for debugging purposes

Yep that makes sense, what I meant is that use dbg! locally. (Or use tracing::debug! and keep the tracing in there and just use the tracing selector to ensure you see what you want...we are really chatty with a big env RUST_LOG=debug unfortunately today, mostly in container fetches)

cgwalters · 2025-05-13T10:23:21Z

lib/src/cli.rs

@@ -1199,7 +1199,7 @@ async fn run_from_opt(opt: Opt) -> Result<()> {
                    let fd =
                        std::fs::File::open(&path).with_context(|| format!("Reading {path}"))?;
                    let digest: fsverity::Sha256HashValue = fsverity::measure_verity(&fd)?;
-                    let digest = hex::encode(digest);
+                    let digest = digest.to_hex();


I think this should be squashed with the previous commit, and it may make sense to have a "bump composefs-rs" prep PR split out right?

Right, that makes sense. I'll put this in a separate PR

Done in #1403

cgwalters · 2025-05-13T10:24:46Z

lib/src/install.rs

 async fn install_to_filesystem_impl(
    state: &State,
    rootfs: &mut RootSetup,
    cleanup: Cleanup,
+    composefs: bool,


I think this would make sense as part of state

I was conflicted on where to put this. Thanks for the review. I'll add this to State

cgwalters · 2025-05-13T11:14:46Z

lib/src/install.rs

-            &imgstore,
-        )
-        .await?;
+        tracing::warn!(


Same comment re dbg! or this one could also make sense as a tracing::debug! that gets left in right?

Ah, yes. We can keep this one as debug

cgwalters · 2025-05-13T13:07:15Z

bootc install to-disk --composefs

The branding here is a bit confusing because of course, bootc already uses composefs. Just the https://github.com/composefs/composefs/ version, and that is "indirectly" via ostree.

Bigger picture I think what we're trying to aim for here primarily is "sealed" images right? In that case then, one thing I think would make sense is that we don't even have an option to install - we determine what to do by inspecting the container.

It does of course make sense to eventually support unsealed images this way too...which will be extremely important for eventually migrating existing ostree systems. There's an enormous set of details there though.

So my proposal in a nutshell:

Let's call it "composefs native" storage or so (the branding here is again hard, open to other ideas)
Default to (i.e. require) composefs-native storage if we detect the image is a sealed UKI.
Make the opt-in flag called like --composefs-native or so for unsealed cases. That said, it could also make sense to add some sort of flag to the container image to do this instead; because I think most people who want to do this will always want to do it. It's basically similar to what we have with kernel arguments; they can be either baked into the container or applied out of band, and in the general case we need both.

Johan-Liebert1 · 2025-05-15T04:49:31Z

Let's call it "composefs native" storage or so (the branding here is again hard, open to other ideas)

I think this works. Or we could have --composefs-native-experimental or something?

Default to (i.e. require) composefs-native storage if we detect the image is a sealed UKI.

Curious about this. Is there a reason we'd want composfs native storage in this case?

cgwalters · 2025-05-15T13:11:20Z

Curious about this. Is there a reason we'd want composfs native storage in this case?

Isn't the whole idea that we're aiming for the sealed case?

Johan-Liebert1 · 2025-06-05T08:44:24Z

I'll be getting back to this PR next Monday. Been working on a separate issue this week...

cgwalters · 2025-06-16T18:30:04Z

lib/src/install/baseline.rs

@@ -403,6 +409,8 @@ pub(crate) fn install_create_rootfs(
        "root",
        opts.wipe,
        mkfs_options.iter().copied(),
+        // TODO: Add cli option for this
+        Some(uuid::uuid!("6523f8ae-3eb1-4e2a-a05a-18b695ae656f")),


It looks like you chose the alpha architecture uuid; it'd make sense potentially to use the DPS UUIDs by default for to-disk but that will require some work.

cc #448 (comment)

cgwalters · 2025-06-25T15:47:10Z

lib/src/install.rs

+    let esp_devices = [COREOS_ESP_PART_LABEL, ANACONDA_ESP_PART_LABEL]
+        .into_iter()
+        .map(|p| Path::new("/dev/disk/by-partlabel/").join(p));


Two things

We shouldn't use /dev/disk/by-partlabel because that's global state, in the general case we may be creating partitions on a loopback mounted device and don't want to touch any global state

There's a well known UUID for the ESP to use

Combining these, see https://github.com/coreos/bootupd/blob/92a8fe2326e35d893afbe464857408c403d9e7ea/src/blockdev.rs#L41 which perhaps we could move into this codebase and have bootupd use it (because bootupd already uses bootc).

Ah, okay I'll update to not use by-partlabel

perhaps we could move into this codebase and have bootupd use it (because bootupd already uses bootc)

I found this little bit weird, as I feel like this should be the other way around. Is there a reason why bootc uses the bootupctl command rather than the bootup crate?

Is there a reason why bootc uses the bootupctl command rather than the bootup crate?

Well...unless we took over that CLI, that'd mean we duplicate the code.

cgwalters · 2025-06-25T15:47:42Z

lib/src/install.rs

+    create_dir_all(&boot_dir).context("Failed to create boot dir")?;
+
+    // Add the user grug cfg
+    let grub_user_config = format!(


In my ideal world grub related things live in bootupd, not in this project.

And even better if we can make this a static configuration...where grub basically implements the BLS spec and finds things in /EFI/Linux on its own right?

It makes sense to put this in bootupd, but upon discussions with @travier we're still debating on whether we want to push systemd-boot or not, so this is more or less temporary

This part of the GRUB config can not be generated by bootup as it is the deployment boot order in the UKI + GRUB case. See: containers/composefs-rs#38 (comment)

It's not possible to use the BLS spec partial support in GRUB to boot UKI. It does not support the key that we need to do so, thus why we generate GRUB config snippets: ostreedev/ostree#2753 (comment)

cgwalters

Some more comments

cgwalters · 2025-07-16T12:15:11Z

lib/Cargo.toml

@@ -57,6 +57,8 @@ tini = "1.3.0"
 comfy-table = "7.1.1"
 thiserror = { workspace = true }
 canon-json = { workspace = true }
+openat = "0.1.21"


This project is not actively maintained and should not be added here. We use cap-std or rustix directly.

Ah, I see. I took inspiration from bootupd. We should remove it from there as well

cgwalters · 2025-07-16T12:17:08Z

ostree-ext/Cargo.toml

@@ -17,7 +17,9 @@ ostree = { features = ["v2025_2"], version = "0.20" }
 anyhow = { workspace = true }
 bootc-utils = { package = "bootc-internal-utils", path = "../utils", version = "0.0.0" }
 camino = { workspace = true, features = ["serde1"] }
-composefs = { git = "https://github.com/containers/composefs-rs", rev = "59299eb8de6c22410f32213cc57901a7ddd3c134", features = ["rhel9"] }
+composefs = { git = "https://github.com/containers/composefs-rs", rev = "d8e285f14c3c9fa969496fd98e12ffba3079842d", package = "composefs" }
+composefs-boot = { git = "https://github.com/containers/composefs-rs", rev = "d8e285f14c3c9fa969496fd98e12ffba3079842d", package = "composefs-boot" }


We also need to discuss containers/composefs-rs#143 (comment) related to this.

cgwalters · 2025-07-16T12:19:04Z

ostree-ext/src/container_utils.rs

@@ -77,6 +77,13 @@ pub fn ostree_booted() -> io::Result<bool> {
    Path::new(&format!("/{OSTREE_BOOTED}")).try_exists()
 }

+
+/// Returns true if the system appears to have been booted with composefs.


I don't want to belabor this too much but I think it will cause endless confusion if we keep saying "this uses composefs" when again we're already using "composefs".

How about "without ostree"? Or "composefs native" or "pure composefs".

Ah yes, definitely. I'll update these throughout the repo

cgwalters · 2025-07-16T12:20:26Z

ostree-ext/src/container_utils.rs

+
+/// Returns true if the system appears to have been booted with composefs.
+pub fn composefs_booted() -> io::Result<bool> {
+    let cmdline = std::fs::read_to_string("/proc/cmdline")?;


We should use a proper kernel argument parser in general. It's actually a bit complicated because of quoting. systemd has a good version of course, and we have one in C in ostree. It'd probably make sense to make a dedicated one.

We could build our own parser? @travier suggested https://github.com/rust-bakery/nom for parsing Grub menuentries. Maybe we could use it for parsing kernel cmdline as well?

I have written what feels like a million various nom parsers for Advent of Code over the years, I could probably throw something together for kernel cmdline in short order. Seems to be well-documented at https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

Sure, I'm good to make a new small internal crate for this. But I wouldn't try to just greenfield it though, but reference existing parsers. I think https://github.com/ostreedev/ostree/blob/main/src/libostree/ostree-kernel-args.c is correct, as is the systemd version.

Sorry I forgot we already have https://github.com/bootc-dev/bootc/blob/main/lib/src/kernel.rs and to combine with the chat yes let's for now just take the code from https://github.com/containers/composefs-rs/blob/d5455222f282200913902f29c66d5f625ca5661f/crates/composefs-boot/src/cmdline.rs#L9 but what we IMO must do when parsing /proc/cmdline is use to_utf8_lossy or so so we don't bomb out if the kernel commandline somehow has non-UTF8 data.

jeckersb · 2025-07-16T20:06:08Z

lib/src/bls_config.rs

👍 for a first pass, but skimming through the boot loader specification document there's a lot more to this. Probably enough so that it would make sense to spin this off into its own crate, I'm sure others would find it to be useful outside of bootc.

Probably enough so that it would make sense to spin this off into its own crate,

Yes I had the same thought, was one of the motivations for #1413

I'm sure others would find it to be useful outside of bootc.

Probably though I'd say we should probably not at the current time try to go all the way into making it a real published crate unless we had a reason to believe that there was another possible concrete user.

cgwalters

Some more review

cgwalters · 2025-07-16T20:51:10Z

lib/src/install.rs

+pub(crate) fn get_user_config(uki_id: &str) -> String {
+    let s = format!(
+        r#"
+menuentry "Fedora Bootc UKI: ({uki_id})" {{


Should not hardcode Fedora here but instead get this metadata from the UKI

cgwalters · 2025-07-16T20:51:58Z

lib/src/install.rs

+
+    create_dir_all(&entries_path).with_context(|| format!("Creating {:?}", entries_path))?;
+
+    std::fs::write(


I think in general we should use e.g. https://docs.rs/cap-std-ext/latest/cap_std_ext/dirext/trait.CapStdExtDirExt.html#tymethod.atomic_write for things like this

cgwalters · 2025-07-16T20:52:32Z

lib/src/install.rs

+        BootSetupType::Upgrade => (
+            Utf8PathBuf::from("/sysroot"),
+            vec![
+                format!("root=UUID={DPS_UUID}"),


The point of the DPS is that we can avoid the root= karg right?

Yes, but grub still requires it iirc

cgwalters · 2025-07-16T20:53:51Z

lib/src/deploy.rs

+const ROLLBACK_ENTRIES: &str = "entries.staged";
+
+#[context("Getting boot entries")]
+pub(crate) fn get_sorted_boot_entries(ascending: bool) -> Result<Vec<BLSConfig>> {


I think stuff like this would be good to cover via unit tests, we have a pattern of doing so using cap-std elsewhere.

cgwalters · 2025-07-16T20:54:45Z

lib/src/cli.rs

+    //     .digest()
+    //     .context("Getting digest for booted image")?;
+
+    let (repo, entries, id) = pull_composefs_repo(&imgref.transport, &imgref.image).await?;


BTW almost certainly this will need work to set up the image proxy with the same config as we use for the ostree backend, otherwise we won't honor /etc/ostree/auth.json etc.

The image pulling code in composefs-rs definitely needs some improvement. I'm not sure if it's an issue with skopeo or containers-image-proxy but pulling an image from containers-storage sometimes fails with

ERROR Composefs Switching: Pulling composefs repository: Pulling composefs repo: Unable to pull container image containers-storage:localhost/bootc-composefs-bls-upgrade: Failed to pull config Desc riptor { media_type: ImageConfig, digest: Digest { algorithm: Sha256, value: "sha256:3c6248f829437b55cb57355f8fdefc5f4f35c2379c726a0872383e113a4455fa", split: 6 }, size: 12533, urls: None, annotat ions: None, platform: None, artifact_type: None, data: None }: failed to invoke method GetBlob: locating item named "sha256:8570667f03be297afea2c40859006418ec85d4dc6ad2e1258f5412fcdd82ffff" for im age with ID "3c6248f829437b55cb57355f8fdefc5f4f35c2379c726a0872383e113a4455fa" (consider removing the image to resolve the issue): file does not exist

cgwalters · 2025-07-16T21:03:58Z

lib/src/install.rs

+async fn initialize_composefs_repository(
+    state: &State,
+    root_setup: &RootSetup,
+) -> Result<(Sha256Digest, impl FsVerityHashValue)> {


I think we should return the repository object too.

Yeah, I missed it

cgwalters · 2025-07-16T21:04:41Z

lib/src/install.rs

+        BootSetupType::Setup(root_setup) => {
+            // root_setup.kargs has [root=UUID=<UUID>, "rw"]
+            let mut cmdline_options = String::from(root_setup.kargs.join(" "));
+            cmdline_options.push_str(&format!(" composefs={id_hex}"));


We should definitely be centralizing via e.g. const our references to this kernel commandline.

cgwalters · 2025-07-16T21:05:58Z

lib/src/install.rs

+        ComposefsBootEntry::UsrLibModulesUki(..) => todo!(),
+
+        ComposefsBootEntry::UsrLibModulesVmLinuz(usr_lib_modules_vmlinuz) => {
+            // Write the initrd and vmlinuz at /boot/<id>/


And here <id> is the composefs digest? Note that that will mean that we duplicate the kernel/initrd for every userspace change. ostree has this concept of a "bootcsum" to avoid that.

Duplicating it is pretty unavoidable for sealed UKIs of course.

But I wonder if we may run into this for the unsealed case. On this topic xref coreos/fedora-coreos-tracker#1465

You're right about the duplication. We should do it similarly to ostree

cgwalters · 2025-07-16T21:15:30Z

lib/src/install.rs

+#[context("Setting up BLS boot")]
+pub(crate) fn setup_composefs_bls_boot(
+    setup_type: BootSetupType,
+    // TODO: Make this generic


Yeah but you know the problem here is...it will basically infect most of the bootc codebase with a generic - the same way it did in composefs-rs. That's going to be super painful.

We had part of this debate in containers/composefs-rs#105 and I'm still kind of skeptical that generics make sense overall. (The especially important argument here is that we may want to defer until runtime i.e. via some repository configuration or other state which digest we use) and that will mean we basically double 70% (yes number made up) of the code generated.

A potential thing in the future is to support migrating from sha256 to sha512 for example, and then we'd need two instantations of Repository for each.

containers/composefs-rs#159

cgwalters · 2025-07-16T21:16:43Z

lib/src/install.rs

+            .context("Writing vmlinuz to path")?;
+
+            if let Some(initramfs) = &usr_lib_modules_vmlinuz.initramfs {
+                std::fs::write(


Again should use atomic writes - I think we also want to ensure we fsync here for sure.

jeckersb · 2025-07-17T17:31:48Z

lib/src/bls_config.rs

+    }
+}
+
+pub(crate) fn parse_bls_config(input: &str) -> Result<BLSConfig> {


This sort of thing I would normally impl TryFrom<&str> for BLSConfig. I think it makes it more obvious what is going on when you use it like let foo = BLSConfig::try_from(&some_str)?; Plus for free you also get the inverse of let foo: BLSConfig = some_str.try_into()?;

Done to facilitate the installation of a composefs repository to disk Signed-off-by: Pragyan Poudyal <[email protected]>

Signed-off-by: Pragyan Poudyal <[email protected]>

Also exit early if kargs are passed for `--boot=uki` Signed-off-by: Pragyan Poudyal <[email protected]>

Instead of putting the UKI in `/boot` in the root partition, this commit moves it to the ESP. Update grub user.cfg and pass the disk UUID to `--fs-uuid` Signed-off-by: Pragyan Poudyal <[email protected]>

This is currently WIP, as it only shows the currently booted image in use and not any staged or rollback deployments. Signed-off-by: Pragyan Poudyal <[email protected]>

Create a .origin file in /sysroot/state to store image info Signed-off-by: Pragyan Poudyal <[email protected]>

Also create `/var` inside `/state/deploy/<image_id>` as a symlink to `../../fedora/os/var` which is to be the case for every deployment Signed-off-by: Pragyan Poudyal <[email protected]>

Signed-off-by: Pragyan Poudyal <[email protected]>

* Implement `bootc upgrade` command for a composefs-native booted system * Refactor UKI and BLS boot entry writing functions to work for upgrade * Prevent using global `/dev/disk/by-partuuid` to get UUID for ESP * Refactor out code for populating `/sysroot/state` Signed-off-by: Pragyan Poudyal <[email protected]>

Store the staged deployment at `/run/composefs/staged-deployment` similar to how it's done in ostree Signed-off-by: Pragyan Poudyal <[email protected]>

On upgrade/switch write UKI and BLS entries with the suffix .staged This should be atomically renamed by the equivalent of `ostree-finalize.service` for composefs. In case of grub menuentries for UKI case, rewrite the entire file by reading /sysroot/state/deploy/<deployment_id> Signed-off-by: Pragyan Poudyal <[email protected]>

This does not yet "apply" the switch, it only stages a deployment Also refactor pulling of a composefs repository to a separate function Signed-off-by: Pragyan Poudyal <[email protected]>

Store whether the boot type for the deployment is BLS or UKI in the origin file for the deployment, under the `boot` section with `boot_type` key Signed-off-by: Johan-Liebert1 <[email protected]>

Now we get the vmlinuz and initrd from the boot entry and write them to /boot ourselves not relying on composefs lib's provided helper function. Allows more granularity while modifying BLS entries Signed-off-by: Johan-Liebert1 <[email protected]>

Fixes weird issue where BLS boot hangs if root UUID is in all caps Signed-off-by: Johan-Liebert1 <[email protected]>

This commit does not handle the edge cases that arise with rollbacks when there is a staged deployment present. For Grub BLS case, we create a new `loader/entries.staged` directory, write the new boot entries, then atomically swap `loader/entries` and `loader/entries.staged`. For Grub UKI case, we regenerate `grub2/user.cfg` using the images present in `/sysroot/state/deploy/` To distinguish whether the currently booted system is booted with a UKI or BLS, we add an entry to origin file called `boot_type` Signed-off-by: Johan-Liebert1 <[email protected]>

Get exported `read_file` function Use `enable_verity_raw` Signed-off-by: Johan-Liebert1 <[email protected]>

cgwalters · 2025-07-21T12:22:58Z

We had a live chat about this and decided to make a branch in this repo for it so multiple people can collaborate!

cgwalters · 2025-07-21T12:46:59Z

Created in https://github.com/bootc-dev/bootc/tree/composefs-backend
I have also sent an invite to @Johan-Liebert1 to have write access to the repository.

(That said we still need to convert to e.g. https://clowarden.io/ )

github-actions bot added the area/install Issues related to `bootc install` label May 13, 2025

Johan-Liebert1 force-pushed the composefs-backend branch from cd42079 to b3d1952 Compare May 13, 2025 09:08

cgwalters reviewed May 13, 2025

View reviewed changes

cgwalters mentioned this pull request May 13, 2025

examples: add bootc/ directory containers/composefs-rs#116

Draft

travier mentioned this pull request Jun 16, 2025

examples: Add bootc UKI & BLS examples containers/composefs-rs#143

Draft

cgwalters assigned jeckersb Jun 16, 2025

cgwalters requested a review from jeckersb June 16, 2025 18:24

cgwalters reviewed Jun 16, 2025

View reviewed changes

Johan-Liebert1 force-pushed the composefs-backend branch from 5979f04 to 42632ce Compare June 17, 2025 05:59

travier mentioned this pull request Jun 17, 2025

composefs-rs integration in bootc #1190

Open

cgwalters changed the title ~~Composefs backend~~ Composefs-native backend Jun 25, 2025

cgwalters mentioned this pull request Jun 25, 2025

Investigate alignment/intersection with systemd-repart #448

Open

cgwalters reviewed Jun 25, 2025

View reviewed changes

Johan-Liebert1 force-pushed the composefs-backend branch from 25602da to 7dcc0fc Compare July 14, 2025 16:27

cgwalters requested changes Jul 16, 2025

View reviewed changes

jeckersb reviewed Jul 16, 2025

View reviewed changes

cgwalters reviewed Jul 16, 2025

View reviewed changes

jeckersb reviewed Jul 17, 2025

View reviewed changes

This was referenced Jul 17, 2025

Clean up kernel argument parsing #1425

Open

Mitigate generics containers/composefs-rs#159

Open

Johan-Liebert1 added 6 commits July 18, 2025 11:15

cli/install: Add composefs option to InstallToDiskOpts

a2768ef

Done to facilitate the installation of a composefs repository to disk Signed-off-by: Pragyan Poudyal <[email protected]>

install: Pull composefs repository

3c9f31d

Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Write boot entries

f3d9ab4

Signed-off-by: Pragyan Poudyal <[email protected]>

Grub wip

c6c9aaa

Signed-off-by: Pragyan Poudyal <[email protected]>

Use discoverable partition specification for rootfs UUID

5f4b13a

Signed-off-by: Pragyan Poudyal <[email protected]>

Bump composefs-rs

7c62cfd

Signed-off-by: Pragyan Poudyal <[email protected]>

Johan-Liebert1 added 19 commits July 18, 2025 11:19

install/composefs: Update composefs install options

dbb29e1

Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Introduce flag for bls/uki boot

1dd786b

Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Get image and transport source_imgref

2313e3c

Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Return result from opts.validate

d15c988

Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Handle kargs for BLS

f75689c

Also exit early if kargs are passed for `--boot=uki` Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Put UKI in the ESP

6817ba7

Instead of putting the UKI in `/boot` in the root partition, this commit moves it to the ESP. Update grub user.cfg and pass the disk UUID to `--fs-uuid` Signed-off-by: Pragyan Poudyal <[email protected]>

cli/composefs: Implement status cmd for compoesfs booted system

4e3bcec

This is currently WIP, as it only shows the currently booted image in use and not any staged or rollback deployments. Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Create origin file

6d2e5e7

Create a .origin file in /sysroot/state to store image info Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Move state to /state/deploy/<image_id>

92dba1c

Also create `/var` inside `/state/deploy/<image_id>` as a symlink to `../../fedora/os/var` which is to be the case for every deployment Signed-off-by: Pragyan Poudyal <[email protected]>

cli: Implement bootc status for composefs native booted system

42d816c

Signed-off-by: Pragyan Poudyal <[email protected]>

cli/composefs: Show staged/rollback deployments

5887dbf

Store the staged deployment at `/run/composefs/staged-deployment` similar to how it's done in ostree Signed-off-by: Pragyan Poudyal <[email protected]>

cli/composefs: Implement bootc switch

a0d96cd

This does not yet "apply" the switch, it only stages a deployment Also refactor pulling of a composefs repository to a separate function Signed-off-by: Pragyan Poudyal <[email protected]>

install/composefs: Store boot type in origin file

0e6ce9d

Store whether the boot type for the deployment is BLS or UKI in the origin file for the deployment, under the `boot` section with `boot_type` key Signed-off-by: Johan-Liebert1 <[email protected]>

cli/install: Use lowercase DPS UUID

27d8e87

Fixes weird issue where BLS boot hangs if root UUID is in all caps Signed-off-by: Johan-Liebert1 <[email protected]>

Bump composefs-rs

04f048f

Get exported `read_file` function Use `enable_verity_raw` Signed-off-by: Johan-Liebert1 <[email protected]>

Johan-Liebert1 force-pushed the composefs-backend branch from 7dcc0fc to 04f048f Compare July 19, 2025 11:16


		create_dir_all(&entries_path).with_context(\|\| format!("Creating {:?}", entries_path))?;

		std::fs::write(

Composefs-native backend #1314

Are you sure you want to change the base?

Composefs-native backend #1314

Conversation

Johan-Liebert1 commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgwalters left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cgwalters commented May 13, 2025

Uh oh!

Johan-Liebert1 commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgwalters commented May 15, 2025

Uh oh!

Johan-Liebert1 commented Jun 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Johan-Liebert1 Jun 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cgwalters left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jeckersb Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Johan-Liebert1 commented May 13, 2025 •

edited

Loading

Johan-Liebert1 commented May 15, 2025 •

edited

Loading

Johan-Liebert1 Jun 26, 2025 •

edited

Loading

jeckersb Jul 17, 2025 •

edited

Loading