This adds a `default: true` option for all cases where OSTree
information is specified in schemas and allows for the information
to be picked up from the filesystem.
This is a safe operation because when building disk images there is
no known case where having two deployments makes sense. In the case
there ever were a case then the osname, ref, and serial options still
exist and can be used.
Co-authored-by: Luke Yang <luyang@redhat.com>
Co-authored-by: Michael Vogt <michael.vogt@gmail.com>
Instead of operating directly on the tree for a stage we can operate
on a mount too. This is useful in the case where operating on the
directory tree of files isn't sufficient and the modifications need
to be made directly to the filesystems on the disk image that we are
creating.
One such example of this is we are having a problem right now where
the immutable bit being set on an OSTree deployment root doesn't
survive the `cp -a --reflink=auto` in the org.osbuild.copy stage when
being copied from the directory tree into the mounted XFS filesystem
we created on the disk image. Thus we have to workaround this loss
of attribute by applying the attribute directly on the mounted
filesystem from the disk.
In this change here we also add a check in osbuild/mounts.py to not
attempt a umount of the root of the mounts directory if that path
is no longer a mountpoint, which can happen when the umount -R
from the mounts/org.osbuild.ostree.deployment also removes the
overmount.
Here is an example of how this would be used:
```
- type: org.osbuild.chattr
options:
immutable: true
path: mount://root/
devices:
disk:
type: org.osbuild.loopback
options:
filename: disk.img
partscan: true
mounts:
- name: root
type: org.osbuild.xfs
source: disk
partition:
mpp-format-int: '{image.layout[''root''].partnum}'
target: /
- name: ostree.deployment
type: org.osbuild.ostree.deployment
options:
source: mount
deployment:
osname: fedora-coreos
ref: ostree/1/1/0
```
The initial mount on `/` is the filesystem from the root partition
on the disk. The second mount (of type org.osbuild.ostree.deployment)
then reconfigures things similar to how an OSTree system is set up.
We still target the tree here, but we open ourselves up to be able
to target something other than the tree in the future. This mostly
exchanges the `tree` variable for `target`.
We also update the comment to try to enhance clarity.
This unwinds part of a25ae2b. The way the code ended up both
self.tree and self.mountpoint ended up pointing to the exactly
same path and so we'd end up doing two `umount -R` operations
on the same path. This ended up being a duplicate unmount.
On Fedora 39 this yields an error like:
```
mount/ostree.deployment (org.osbuild.ostree.deployment): umount: /var/osbuild/store/stage/uuid-efaac9370d25455d9e8df6d847ecb5b3/data/tree: not mounted
mount/ostree.deployment (org.osbuild.ostree.deployment): Traceback (most recent call last):
mount/ostree.deployment (org.osbuild.ostree.deployment): File "/var/b/shared/code/github.com/osbuild/osbuild/mounts/org.osbuild.ostree.deployment", line 136, in <module>
mount/ostree.deployment (org.osbuild.ostree.deployment): main()
mount/ostree.deployment (org.osbuild.ostree.deployment): File "/var/b/shared/code/github.com/osbuild/osbuild/mounts/org.osbuild.ostree.deployment", line 132, in main
mount/ostree.deployment (org.osbuild.ostree.deployment): service.main()
mount/ostree.deployment (org.osbuild.ostree.deployment): File "/var/b/shared/code/github.com/osbuild/osbuild/osbuild/host.py", line 252, in main
mount/ostree.deployment (org.osbuild.ostree.deployment): self.stop()
mount/ostree.deployment (org.osbuild.ostree.deployment): File "/var/b/shared/code/github.com/osbuild/osbuild/osbuild/mounts.py", line 126, in stop
mount/ostree.deployment (org.osbuild.ostree.deployment): self.umount()
mount/ostree.deployment (org.osbuild.ostree.deployment): File "/var/b/shared/code/github.com/osbuild/osbuild/mounts/org.osbuild.ostree.deployment", line 125, in umount
mount/ostree.deployment (org.osbuild.ostree.deployment): subprocess.run(["umount", "-R", self.tree],
mount/ostree.deployment (org.osbuild.ostree.deployment): File "/usr/lib64/python3.12/subprocess.py", line 571, in run
mount/ostree.deployment (org.osbuild.ostree.deployment): raise CalledProcessError(retcode, process.args,
mount/ostree.deployment (org.osbuild.ostree.deployment): subprocess.CalledProcessError: Command '['umount', '-R', '/var/osbuild/store/stage/uuid-efaac9370d25455d9e8df6d847ecb5b3/data/tree']
' returned non-zero exit status 1.
⏱ Duration: 103s
```
I think this was necessary because of a bug in util-linux that
mean some of the accounting information got out of date when
doing a `mount --move` operation, which we use here. I think this
bug (or bugs) is now fixed [1][2] in util-linux v2.39 (in Fedora 39),
which is now causing the above pasted error on F39.
Let's just add code here that mentions the problem and workaround
it with a loop to keep unmounting (essentially what the umount -R
should have done to overmounted filesystems if the mountinfo/utab
was correct) and also mention when we should be able to drop this
workaround.
[1] a04149fbb7
[2] 8cf6c50757
Create a private mount point for the tree, so that later we can
move the `root` mount point. This is needed since "moving a mount
residing under a shared mount is invalid and unsupported.", see
`mount(8)`. Currently the `tree` is mounted via a private mount-
point since reading the tree is done via bind-mounts, but this
will change in subsequent commits; this prepares for it.
Apply the isort modifications to the entire source tree, not just the
selected python files of test-src.
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
This fixes pylint warnings on our modules that are currently not part of
CI-pylint. The fixes should all be straightforward.
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
Initialize `mountpoint` and `check` fields. In case of an error
in `open` not having `mountpoint` or `check` initialized will
cause another exception. So this is mostly important in case of
error, but it is the right thing anyway.
Create a new OSTree deployment mount service that will set up bind
mounts inside the tree very much as it is done by OSTree in early
boot. This allows any stage to transparently work with OSTree
deployments.
