IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Closes: https://github.com/ostreedev/ostree/issues/3113
It'd greatly improve compatibility with things like RPMs that install
in `/opt` if we supported a full "original docker" style model where
`/` is a transient overlayfs. We'd still keep our semantics for `/etc`
and `/var` by default, but e.g. we'd stop recommending
`/opt` ➡️ `/var/opt`, in this model,
so `/opt` would be on the overlayfs.
Note this all aligns with composefs, where we'd actually be making
`/` a *read-only* overlayfs by default; it'd be really nice of course
to *implement* this by just making the composefs overlayfs writable,
but I am not sure we can hard require composefs for this right now.
So this change adds support for `root.transient = true`
in `/usr/lib/ostree/prepare-root.conf`.
The major downside is that people could be surprised if files they
write to e.g. `/opt` don't persist across upgrades. But, that's
already again how it works since Docker started.
Note as part of the implementation of this, we need to add a whole
new "backing" directory distinct from the deployment directories.
(Tangentially related to this, it's tempting to switch to always
using a *read-only* overlay mount by default.
I think we originally used to do this, but at some point in a
code refactoring, this optimization got lost.
It's a quite important optimization for the case of writing content
generated by an external system into an ostree repository.
xref https://issues.redhat.com/browse/MGMT-16303
Basically the OCP Assisted installer has now grown code
to try to do OS updates offline post-install, and this means
we need to handle the case of running zipl from the target
root.
This is a pattern we want to encourage. It's honestly just
way simpler than what rpm-ostree is doing today in auto-synthesizing
individual tmpfiles.d snippets.
When backporting a patch recently we hit a non-obvious
dependency on another fix for `ot-main.h` includes. Clean
this up a bit by dropping the redundant includes.
It's about time we do this; deployment finalization locking
is a useful feature. An absolutely key thing here is that
we've slowly been moving towards the deployments as the primary
"source of truth".
Specifically in bootc for example, we will GC container images
not referenced by a deployment.
This is then neecessary to support a "pull but don't apply automatically" model.
This stabilizes the existing `ostree admin deploy --lock-finalization`
CLI, and adds a new `ostree admin unlock-finalization`.
We still check the old lock file path, but there's a new boolean
value as part of the staged deployment data which is intended
to be the source of truth in the future. At some point then we
can drop the rpm-ostree lockfile handling.
Closes: https://github.com/ostreedev/ostree/issues/3025
Right now `ostree admin status` errors out in this case, but
`rpm-ostree status` doesn't. The former behavior is probably
more of a bug, work around it for now.
The explanation of sysroot.readonly is a little confusing - we say
that "everything else is mounted read-only" but it's perhaps clearer
to say /sysroot is mounted read-only.
Also note that read-only is the default with composefs.
Finally, document the option in ostree.repo-config even though it is
now considered legacy - as of commit 22b8e4f9 (#2930) - it is still
commonly seen in repo configs, so users will look to understand
what it means.
This command will apply fs-verity on all objects that need it and
needs to be called when an ostree deployment has been copied on a
file-by-file basis, which would loose information such as fs-verity.
This is needed by osbuild which works by creating the final image in a
rootfs, and then separately copying that rootfs file-by-file to a
loopback mounted filesystem image.
There seems to be a tricky regression here with the util-linux
support for the new mount API, plus overlays support for it.
```
[2023-11-09T21:05:30.633Z] Nov 09 21:05:26 qemu0 kola-runext-unlock-transient.sh[2108]: + unshare -m -- /bin/sh -c 'mount -o remount,rw /usr && echo hello from transient unlock >/usr/share/writable-usr-test'
[2023-11-09T21:05:30.633Z] Nov 09 21:05:26 qemu0 kola-runext-unlock-transient.sh[2148]: mount: /usr: mount point not mounted or bad option.
[2023-11-09T21:05:30.633Z] Nov 09 21:05:26 qemu0 kola-runext-unlock-transient.sh[2148]: dmesg(1) may have more information after failed mount system call.
```
OK this seems related to the new mount API support in util-linux and overlayfs. From a strace:
```
2095 open_tree(AT_FDCWD, "/usr", OPEN_TREE_CLOEXEC) = 3
2095 mount_setattr(-1, NULL, 0, NULL, 0) = -1 EINVAL (Invalid argument)
...
2095 fspick(3, "", FSPICK_NO_AUTOMOUNT|FSPICK_EMPTY_PATH) = 4
2095 fsconfig(4, FSCONFIG_SET_FLAG, "seclabel", NULL, 0) = 0
2095 fsconfig(4, FSCONFIG_SET_STRING, "lowerdir", "usr", 0) = -1 EINVAL (Invalid argument)
```
I think the core problem here is it's trying to reconfigure the mount with existing options,
but in the new mount namespace we can't see the lowerdir.
Here we really really just want to remount writable. Telling
util-linux to not pass existing options fixes it.
