Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bootc status doesn't work in CoreOS live ISO #1043

Open
jlebon opened this issue Jan 17, 2025 · 3 comments
Open

bootc status doesn't work in CoreOS live ISO #1043

jlebon opened this issue Jan 17, 2025 · 3 comments
Labels
area/client Related to the client/CLI

Comments

@jlebon
Copy link
Contributor

jlebon commented Jan 17, 2025

[root@cosa-devsh ~]# rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:oci-archive:/rhcos-9.6.20250108-0-ostree.x86_64.ociarchive
                   Digest: sha256:9bbe2af71215099ab5848b4b434369eb310297d54c1a9e6021da85014531d8f9
                  Version: 9.6.20250108-0 (2025-01-08T22:05:43Z)
[root@cosa-devsh ~]# bootc status
ERROR Status: Initializing storage: Acquiring sysroot: Remounting /sysroot read-write: Permission denied

Having to remount /sysroot at all for status seems dubious.

@jlebon
Copy link
Contributor Author

jlebon commented Jan 17, 2025

Whipped up

diff --git a/lib/src/cli.rs b/lib/src/cli.rs
index e7df044..a28e768 100644
--- a/lib/src/cli.rs
+++ b/lib/src/cli.rs
@@ -595,20 +595,24 @@ pub(crate) fn ensure_self_unshared_mount_namespace() -> Result<()> {
 /// Acquire a locked sysroot.
 /// TODO drain this and the above into SysrootLock
 #[context("Acquiring sysroot")]
-pub(crate) async fn get_locked_sysroot() -> Result<ostree_ext::sysroot::SysrootLock> {
+pub(crate) async fn get_sysroot(lock: bool) -> Result<ostree_ext::sysroot::SysrootLock> {
     prepare_for_write()?;
     let sysroot = ostree::Sysroot::new_default();
     sysroot.set_mount_namespace_in_use();
-    let sysroot = ostree_ext::sysroot::SysrootLock::new_from_sysroot(&sysroot).await?;
+    let sysroot = if lock {
+        ostree_ext::sysroot::SysrootLock::new_from_sysroot(&sysroot).await?
+    } else {
+        ostree_ext::sysroot::SysrootLock::from_assumed_locked(&sysroot)
+    };
     sysroot.load(gio::Cancellable::NONE)?;
     Ok(sysroot)
 }

 /// Load global storage state, expecting that we're booted into a bootc system.
 #[context("Initializing storage")]
-pub(crate) async fn get_storage() -> Result<crate::store::Storage> {
+pub(crate) async fn get_storage(lock_sysroot: bool) -> Result<crate::store::Storage> {
     let global_run = Dir::open_ambient_dir("/run", cap_std::ambient_authority())?;
-    let sysroot = get_locked_sysroot().await?;
+    let sysroot = get_sysroot(lock_sysroot).await?;
     crate::store::Storage::new(sysroot, &global_run)
 }

but feels hacky to use SysrootLock::from_assumed_locked() this way. I think we probably want Storage to own either a SysrootLock or a plain ostree::Sysroot?

@cgwalters cgwalters added the area/client Related to the client/CLI label Jan 17, 2025
@cgwalters
Copy link
Collaborator

Hmm, isn't there more to it? Presumably you're going to change the status (and other readonly cases) to set lock = false? This relates to #585

It may be a more targeted fix to detect when the block device under the sysroot is readonly and never lock (or attempt to remount readwrite) then.

@cgwalters
Copy link
Collaborator

OK I see, the difference between rpm-ostree and bootc is that in rpm-ostree we only call ostree_sysroot_lock() when performing a transaction. Yeah it's probably going to be a bit hard to fix this in bootc without splitting up Storage from StorageTransaction or so.

That said...I suspect we've always had the issue in rpm-ostree that it will be racy for us to try to reload the state if something else is concurrently changing it. The race is probably hard to hit because we only reload after the mtime bump, so one would have to do e.g.

Process/shell A Process/shell B
ostree cmd start
ostree cmd ends, bumps mtime
ostree cmd start picks up mtime change, starts reloading

IOW two concurrent mutations are required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/client Related to the client/CLI
Projects
None yet
Development

No branches or pull requests

2 participants