-
Notifications
You must be signed in to change notification settings - Fork 305
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
ostree admin unlock should not create mount namespace #2653
Comments
Could you run it under |
The result of "sudo ./strace -f -o ostree.strace -s 1000 ostree admin unlock" is:
|
Just FYI, the dir /var/tmp/ostree-unlock-ovl.23AWQW is correctly created, as well as the subfolders /var/tmp/ostree-unlock-ovl.23AWQW/work/work and /var/tmp/ostree-unlock-ovl.23AWQW/upper
|
Can you run
I don't know why it's returning successfully but the mount isn't actually happening. |
I have updated the result of strace. |
Sorry, you already did that. Hmm, earlier there's an Hmm, maybe this is a bug. |
Ha, I was just updating the comment when you reply. Is there any idea about the cause or solution? |
I think that the admin builtin is applying the mount namespace too aggressively at https://github.com/ostreedev/ostree/blob/main/src/ostree/ot-main.c#L629. I'm going to do a quick test with that and see if I reproduce it on our system. If I'm correct, I think another flag will be needed to skip the remounting for commands that need to run in the root namespace but still want to lock the sysroot. I ran into something similar while working on #2544. |
OK, let me know if you need more information about my environment. |
I couldn't reproduce in an x86_64 VM where the Also, can you try |
|
Ok, I think that's why you're seeing this issue and not me. Your As said above, I think ostree could do better by not creating a mount namespace in this situation. For a very which workaround, you could probably call |
Thank you for your information. Though I'm sorry but I know few about shared mount. Do you have any idea why my |
systemd seems to mount |
Finally, I have found the problem. It's because my rootfs is generated by exporting a container from Docker. At first, I use To solve them once for all, I tried to use Docker to generate the rootfs. When building a image with Dockerfile, it has a sweet caching scheme, which makes rebuilding images a lot faster. Using docker also solves the problem of root privilege and hardlinks. However, when exporting a Docker container, a Deleting @dbnicholson Thank you very much for your help. |
Good to know you found a fix. I'm going to leave this open and retitle it since I believe that ostree should not be using a mount namespace in this scenario. |
I am trying to apply ostree on an RK3399 board running Ubuntu 22.04. The kernel version is 5.15.44 with RT patch. The ostree version is 2022.02, which is from Ubuntu 22.04.
The deployment seems successful, but I found ostree admin unlock does not work. Even after ostree admin unlock, it is still unable to write to /usr.
The kernel is customized and some features are turned off. At first, the OVERLAY_FS is turned off in the kernel and corresponding error information is given after "ostree admin unlock". After turning on OVERLAY_FS, the error is gone, but it still does not work.
Maybe I missed some kernel features required by ostree? FYI, I turned off features such as BTRFS_FS and FUSE_FS, maybe they are required for unlock?
Is there a list of required kernel feasures for ostree?
Thank you.
The text was updated successfully, but these errors were encountered: