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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
I have a suspicion that the `semodule -N --refresh` we do here is
involved in https://github.com/coreos/fedora-coreos-tracker/issues/1597.
Let's log when we execute it and include its time.
While we're here, also log the time it takes to `syncfs()` and the
fsfreeze/thaw cycling. It's logged in a structured journal entry, but
that's less accessible than just having it in the journal message field.
This introduces the "retry-all-network-errors" option which
is enabled by default. This is a behavior change as now
ostree will retry on requests that fail except when
they fail with NOT_FOUND. It also introduces the options
"low-speed-limit-bytes" and "low-speed-time-seconds these"
map to CURL options only at the moment. Which have defaults
set following librepo:
7c9af219ab/librepo/handle.h (L90)7c9af219ab/librepo/handle.h (L96)
Currently these changes only apply when using libcurl.
Finally this change adds a final option that affects all
backends to control the max amount of connections of the
fetcher "max-outstanding-fetcher-requests".
This closes the biggest foot-gun when doing e.g.
`rpm-ostree rebase` when zincati is running on a FCOS system.
Previously if zincati happened to have staged + locked a deployment,
we'd keep around the lock which is definitely not what is desired.
Came up on an internal chat; previously we were only erroring
out when trying to do the SELinux labeling for `/var` which
was really misleading.
Add some other error prefixing while we have the patient open.
If the `prepare-root.conf` file contains:
```
[etc]
transient=yes
```
Then during prepare-root, an overlayfs is mounted as /etc, with the
upper dir being in /run. If composefs is used, the lower dir is
`usr/etc` from the composefs image , or it is the deployed
`$deploydir/usr/etc`.
Note that for this to work with selinux, the commit must have been
built with OSTREE_REPO_COMMIT_MODIFIER_FLAGS_USRETC_AS_ETC. Otherwise
the lowerdir (/usr/etc) will have the wrong selinux contexts for the
final location of the mount (/etc).
We also set the transient-etc key in the ostree-booted file, pointing it
to the directory that is used for the overlayfs.
There are some additional work happening in ostree-remount, mostly
related to selinux (as this needs to happen post selinux policy
load):
* Recent versions of selinux-poliy have issues with the overlayfs
mount being kernel_t, and that is not allowed to manage files as
needed. This is fixed in
https://github.com/fedora-selinux/selinux-policy/pull/1893
* Any /etc files created in the initramfs will not be labeled,
because the selinux policy has not been loaded. In addition, the
upper dir is on a tmpfs, and any manually set xattr-based selinux
labels on those are reset during policy load. To work around this
ostree-remount will relabel all files on /etc that have
corresponding files in overlayfs upper dir.
* During early boot, systemd mounts /run/machine-id on top of
/etc/machine-id (as /etc is readonly). Later during boot, when etc
is readwrite, systemd-machine-id-commit.service will remove the
mount and update the real file under it with the right content. To
ensure that this keeps working, we need to ensure that when we
relabel /etc/machine-id we relabel the real (covered) file, not the
temporary bind-mount.
* ostree-remount no longer needs to remount /etc read-only in the
transient-etc case.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
