Merge version 2026.2-1+rpi1 and 2026.4-1 to produce 2026.4-1+rpi1

Declare fast forward from 2026.3-1

[dgit --quilt=gbp --overwrite]

static-delta: validate bspatch payload offset and length

Origin: https://github.com/ostreedev/ostree/pull/3647
Applied-upstream: 2026.5, commit:84ca25e8a09da15fb96b81e87a5778b6db7dd05f

Gbp-Pq: Name static-delta-validate-bspatch-payload-offset-and-length.patch

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

Release to unstable

Update changelog

d/patches: Add post-release patch to fix offset validation

This is an out-of-bounds read when downloading from a malicious/crafted
ostree repository, but is not believed to be practically exploitable
for anything worse than a crash (denial-of-service).

New upstream release

Closes: #1144283

Update upstream source from tag 'upstream/2026.4'

Update to upstream version '2026.4'
with Debian dir 8748eca921818f27e106eb2588d9fa86d6ba8a59

New upstream version 2026.4

Release 2026.4

Merge pull request #3636 from correctmost/remove-const-attr

build: Remove `G_GNUC_CONST` from `ostree-enumtypes.h.template`

Merge pull request #3645 from cgwalters/static-delta-revert-margin-heuristic

Static delta revert margin heuristic

static-delta: Drop flat per-part decompression-size cap

The 512 MiB flat cap on decompressed part size is heuristic.
Since we broke flatpak firefox deltas with incorrect heuristics,
back that out until we come up with a design that is precise and
tighter.

This deliberately reopens <https://github.com/ostreedev/ostree/security/advisories/GHSA-7cgc-gp99-6jmm> for now.

Assisted-by: https://github.com/cgwalters/cgwalters#llms
Signed-off-by: Colin Walters <walters@verbum.org>

static-delta: Drop unreliable usize-based margin heuristic

The per-object margin formula added in the previous commit tries to
bound the gap between a delta part's declared usize (sum of
reconstructed object sizes) and its actual decompressed payload size
by scaling with the number of objects in the part.  That's the wrong
axis: the biggest source of that gap is the bsdiff patch stream for
bsdiff'd objects, which scales with object *content* size, not object
*count*.  A part with just one or two large bsdiff'd objects (e.g. a
big shared library that changed significantly between releases) blows
right past the margin, causing legitimate deltas to be rejected at
apply time.  This is the root cause of
https://github.com/ostreedev/ostree/issues/3635.

Just drop it, we'll work to add a more reliable limit later.

Assisted-by: https://github.com/cgwalters/cgwalters#llms
Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3638 from kali834x/xattr-validate-all-entries

core: don't skip entries in _ostree_validate_structureof_xattrs

core: don't skip entries in _ostree_validate_structureof_xattrs

the for loop already advances the index, but the body incremented it a
second time, so only even-indexed xattrs were examined and the empty-name,
duplicate-name and sort-order checks skipped half the array. a crafted
dirmeta from a remote could hide an unsorted or duplicate xattr in an odd
slot and still pass ostree_validate_structureof_dirmeta.

Mention #1144105, #1144106 in previous changelog entry

Release

Declare fast forward from 2026.2-1

[dgit --quilt=gbp --overwrite]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

d/libostree-1-1.symbols: Update

Update changelog

New upstream release

Update upstream source from tag 'upstream/2026.3'

Update to upstream version '2026.3'
with Debian dir a1672f29cf2bac4bc36a28b8c9700c40e06adc66

New upstream version 2026.3

build: Remove G_GNUC_CONST from ostree-enumtypes.h.template

get_type functions have global side effects, which makes them
ineligible for the G_GNUC_CONST attribute.

See https://gitlab.gnome.org/GNOME/glib/-/commit/01682955 for
further details.

Completes: e87513c5

Merge pull request #3631 from jmarrero/update-flaky-kola-test

tests: Fix flaky kola destructive tests

tests: Fix flaky kola destructive tests

The kargs-proc-cmdline-quoted test was parsing `ostree admin status`
text output with a sed regex that assumes the line ends with the
deployment serial.  Status annotations like "(pending)" break this;
just reuse $host_commit from libinsttest.sh instead.

For soft-reboot, make the initramfs regeneration check non-fatal
since dracut can fail inside bwrap in CI VMs.  The kargs-based
kernel state check still covers the same rejection path.

Merge pull request #3630 from jmarrero/release-2026.3

Release 2026.3

configure: post-release version bump

Release 2026.3

Merge pull request #3624 from pwithnall/summary-signatures

ot-builtin-summary: Verify signature when viewing a summary file

Merge pull request #3626 from lzwind/remove-g-gnuc-const

build: Remove G_GNUC_CONST from *_get_type declarations

Merge pull request #3627 from lzwind/fix-find-remotes-writable

find-remotes: Don't require write access unless pulling

Merge pull request #3629 from jmarrero/ci-fixes-aug26

clang-format: fix files failing check.

style: Fix clang-format violation in tests/test-bsdiff.c

Collapse short array initializer to a single line to satisfy
clang-format.

style: Fix clang-format violation in ostree-repo-finder-mount.c

Line-wrap long declaration after G_GNUC_BEGIN_IGNORE_DEPRECATIONS to
satisfy clang-format.

build: Remove G_GNUC_CONST from *_get_type declarations

GLib removed G_GNUC_CONST from its *_get_type declarations to avoid
miscompilations with GCC trunk, and recommends downstream projects do
the same. See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5223

Closes #3612

find-remotes: Don't require write access to repo unless pulling

ostree find-remotes is a read-only operation that searches for remotes
which have a given collection-ref. It should not require write access
to the repository. Only when --pull is used does the command actually
write to the repo.

Move the ostree_ensure_repo_writable() check to just before the pull
phase so that read-only find-remotes works on read-only repositories.

Closes #3585

Merge pull request #3625 from pwithnall/gpg-sign-bang

man: Document how to select subkeys with --gpg-sign

tests: Add simple tests for `ostree summary` key commands

Add simple tests for `--list-metadata-keys` and `--print-metadata-key`,
mostly just to check that they don’t include signature verification
output, but also as a smoketest.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

ot-builtin-summary: Verify signature when viewing a summary file

So now we can run `ostree summary --repo . --view --gpg-homedir
/path/to/servers/gpg-homedir` and it’ll verify the GPG signatures.
That’s not so useful for verification per-se, since if you’re running
this on a server you’d expect the signatures you’ve generated to verify
correctly. It’s more useful to see how many signatures are on the
`summary` and which subkeys were used to generate them, when messing
around with multiple signing keys.

Aside from this, there is no way (that I know of) to inspect the
signatures on a summary file without checking out a copy of the
repository and hoping that the client has got a full copy of the keyring
containing all relevant subkeys.

The verification output is very similar to that of `ostree show`.

Note that signatures are not verified if running with `--raw`,
`--list-metadata-keys` or `--print-metadata-key`, since clients may be
parsing the output of those commands.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

man: Tweak formatting for ostree-summary.xml options

Make the `KEY-ID` placeholder match the `ostree commit` man page.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

man: Document how to select subkeys with --gpg-sign

See the ‘HOW TO SPECIFY A USER ID’ section of `man 1 gpg`; or
https://stackoverflow.com/a/48240076/2931197.

This will be important when rotating signing subkeys for an OSTree
repository.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

man: Fix some grammar problems with --gpg-sign documentation

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

ostree-repo: Add a new ostree_repo_verify_local_summary() API

This will be used in the following commit to add signature verification
to `ostree summary` when used to view the summary of a local repository.

It needs to be separate from `ostree_repo_verify_summary()`, as that API
expects to take a remote name and use the keyring for that remote. As
far as I can tell there isn’t a way to use an arbitrary GPG homedir to
verify a summary file, as is needed when running on the OSTree server
rather than on a client checkout.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

ostree-repo: Fix grammar in some error messages

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Merge pull request #3620 from pwithnall/sign-verify-error-handling

ostree-sign-ed25519: Fix overwriting already-set GErrors

ostree-sign: Slightly clarify docs around --key-file

It wasn’t 100% clear to idiots like me that the key file is in a custom
format, rather than being a GPG keyring.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

ostree-sign-ed25519: Fix overwriting already-set GErrors

There were a couple of issues here, related to passing a `GError**` into
a sub-function inside a loop:
 - If multiple calls inside the loop failed (e.g. if multiple keys
   inside the file were invalid, because it was a malformed file), the
   `GError` would be overwritten and cause a critical warning from GLib.
 - If an early iteration failed, but then subsequent ones succeeded, the
   `_load_pk_from_stream()` function would return `TRUE` but would also
   set its `GError`, which is a very non-standard (basically prohibited)
   thing to do with a `GError` argument.

Fix that by using a `first_error` variable internally and only
propagating it to the caller on failure.

This can be reproduced by trying to verify a signature using a key file
which isn’t actually a key file:
```
ostree sign --verify --repo ./my-repo $commit_id \
  --keys-file ./test.published.gpg
```

The keys file is expected to be in a custom format, with one ed25519 key
per line. An ASCII-armoured GPG keyring is not that format, and causes
it to go big boom.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

ostree-blob-reader: Add error handling for invalid base64 blobs

One cannot base64 decode the empty string, so catch that case (which can
happen if asked to load a malformed key file) early before it causes an
assertion failure inside GLib.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Merge pull request #3618 from cgwalters/static-delta-overhead

static-delta: Account for the full part payload consistently

static-delta: Account for the full part payload consistently

The previous commit adding a limit here didn't account
correctly for metadata overhead; in trying to do it as a private
security fix we didn't run all of the tests, which was a procedural
mistake.

Assisted-by: AI
Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3608 from ricardosalveti/volatile-root-composefs

prepare-root: create /run/systemd/volatile-root for composefs

Merge pull request #3566 from jeckersb/readme-atomic-desktops

README.md: Link to top-level Atomic Desktops page

Merge pull request #3617 from cgwalters/ukleinek-snprintf-rebase

prepare-root: Properly check return value of snprintf()

Merge pull request #3589 from miabbott/vserver

docs: update link to VServer reference

prepare-root: Properly check return value of snprintf()

When the target buffer is to small to hold the resulting string a value
larger or equal than the buffer's size is returned. (In pre C99
versions, snprintf returned -1 in this case, too.)

So to ensure that no truncated paths are used adapt the error checking
accordingly.

Merge pull request #3592 from bbhtt/bbhtt/fix-werrors

Ignore typedef-redefinition warnings with Clang and Fix enum type mismatch in copy flags

Merge pull request #3607 from jmarrero/re-add-jenkins

ci: revert removing coreos-ci Jenkins CI job

deploy: Fix enum type mismatch in copy flags

Fixes: https://github.com/ostreedev/ostree/issues/3591

configure: Ignore typedef-redefinition warnings with Clang

redefinition is legal in C11 and before that via gcc extension

Fixes: https://github.com/ostreedev/ostree/issues/3590

Merge commit from fork

static-delta: bound LZMA decompression to prevent decompression bombs

Merge commit from fork

static-delta: guard bspatch against integer truncation on 32-bit

static-delta: Validate decompressed size against declared usize

Each delta part header already declares the expected uncompressed
size of the resulting objects.  Pass that through to
_ostree_static_delta_part_open() and use it as the decompression
limit when it is smaller than the hard cap.  This catches a
crafted delta that declares a small usize (passing the free-space
pre-check) but actually decompresses to something much larger.

The hard cap (512 MiB) remains as a backstop when the declared
size is unavailable (e.g. the show/dump path passes 0).

Suggested-by: Colin Walters <walters@verbum.org>

static-delta: Reject oversized parts at generation time

Error in finish_part() when the uncompressed payload exceeds the
consumer-side limit, so that an oversized --max-chunk-size fails
at delta creation rather than producing content clients reject.

static-delta: Add resource limits for LZMA decompression

A malicious repository can serve crafted static delta content that
exhausts client memory and disk during ostree pull before checksum
validation completes.

Cap the LZMA decoder memory to 100 MiB (matching RPM's default) and
bound decompressed delta part output to 512 MiB. The size limit is
enforced on both compressed and uncompressed code paths.

Closes: RHEL-189208

Merge pull request #3615 from jlebon/pr/reflink-accounting

lib/commit: Fix min-free-space accounting for reflinked content objects

lib/commit: Fix min-free-space accounting for reflinked content objects

When writing a content object,
create_regular_tmpfile_linkable_with_content() opportunistically tries
FICLONE to reflink data from the input fd. The reflinked file shares its
data blocks via copy-on-write, so the actual disk cost is just metadata.

However, the min-free-space accounting in write_content_object()
reserves the full file size in max_blocks upfront and never credits it
back after a successful reflink. Over many files this causes max_blocks
to diverge significantly from actual free space.

Propagate the reflink status from
create_regular_tmpfile_linkable_with_content back to
write_content_object so it can credit back the reserved blocks,
following the same pattern used for duplicate objects in 16e537cb
("lib/commit: Fix min-free-space accounting for duplicate content
objects").

This should fix the CI issues in
https://github.com/coreos/fedora-coreos-config/pull/4265.

Heavily AI-guided investigation and resolution and red-green testing.

Assisted-by: AI

Merge pull request #3614 from jlebon/pr/double-accounting

lib/commit: Fix min-free-space accounting for duplicate content objects

tree: Go back to git.mk-generated .gitignore

Commit b0cd80d9 ("ci: Add Packit CI with RPM builds and TMT integration
tests") added an in-tree .gitignore which trips up the `git.mk` bits
which normally generate it. And so then build artifacts showed up all as
untracked files.

Go back to keeping `.gitignore` untracked and instead add `.cosa` to
`GITIGNOREFILES` to retain the original entries that b0cd80d9 added.

lib/commit: Fix min-free-space accounting for duplicate content objects

First, in the _ostree_repo_bare_content_commit(), we never actually
checked whether the file was already present in the repo before linking
it in place. Do this so that we can no-op up front.

Second, and the actual bug this patch is fixing: the min-free-space
accounting in write_content_object() and
_ostree_repo_bare_content_commit() optimistically reserves space from
the running `txn.max_blocks` counter _before_ knowing whether we'll
actually no-op or not based on the object already existing.

Over many duplicate writes within a single transaction, the counter
diverges from the actual free space and eventually hits zero, causing a
spurious "min-free-space would be exceeded" error even with plenty of
disk space available.

This may be the source of the CI issue FCOS is hitting in
https://github.com/coreos/fedora-coreos-config/pull/4265 due to the
bootc SELinux relabeling done since
https://github.com/bootc-dev/bootc/pull/2088.

This patch saves the number of blocks reserved and credits them back in
both code paths when a duplicate object is detected.

This was heavily AI-guided, finding the bug, and then doing red-green
testing towards the fix.

Assisted-by: AI

lib/commit: Report whether committed object already existed

Add an `out_existed` output parameter to
`_ostree_repo_commit_tmpf_final()` and `commit_loose_regfile_object()`.
This requires switching from `GLNX_LINK_TMPFILE_NOREPLACE_IGNORE_EXIST`
to `GLNX_LINK_TMPFILE_NOREPLACE` so we can detect `G_IO_ERROR_EXISTS`
ourselves.

No users for now. Prep for a follow-up patch using this.

Assisted-by: AI

Merge version 2026.1-1+rpi1 and 2026.2-1 to produce 2026.2-1+rpi1

tests/bsdiff: add content_size guard boundary test

Add test_bspatch_content_size_guard to verify the integer truncation
guard added for RHEL-189207.  The test exercises the exact boundary
condition used in dispatch_bspatch():

  content_size > G_MAXSIZE || content_size > (guint64)G_MAXINT64

It validates that:
- Values with bit 63 set and G_MAXUINT64 are always rejected
- On 32-bit systems, values above G_MAXUINT32 (4 GiB) are rejected
  including the PoC value 0x100001000 (4 GiB + 4 KiB)
- Normal values (0, 1, 4096, 1 GiB) are accepted and the casts to
  gsize and int64_t produce correct values

static-delta: guard bspatch against integer truncation on 32-bit

On 32-bit systems (sizeof(gsize)==4), the attacker-controlled
content_size (a guint64) is silently truncated when passed to
g_malloc0(), which takes gsize.  Meanwhile bspatch() receives the
full 64-bit value as int64_t newsize and writes according to it,
producing a heap buffer overflow.

Add an explicit check that content_size fits in both gsize and int64_t
before the allocation.  Use separate typed locals (alloc_size, newsize)
to make the truncation-free intent clear and pass newsize to bspatch().

Addresses: RHEL-189207
CWE-680, CWE-122, CWE-190

Merge pull request #3603 from electricface/fix-consume-inode-stability

repo-commit: preserve existing .file object inode on consume commit

repo-commit: preserve existing object inode when staging to objects/

When ostree commit --consume is used and an object with the same
checksum already exists in objects/, rename_pending_loose_objects() was
unconditionally renaming the staging copy over it.  On Linux, renameat(2)
atomically replaces the destination for two regular files, silently
changing the inode of the existing repo object.

Fix this by checking whether the object already exists in objects/
before renaming.  If it does, the content is identical by definition
(the object store is content-addressed by SHA256), so we can simply
unlink the staging copy and keep the existing object with its original
inode.

Exception: .commitmeta objects are keyed by commit checksum rather than
their own content, so they can be updated in place (e.g. when GPG
signatures are added or deleted via ostree gpg-sign).  These are always
renamed unconditionally.

Merge pull request #3610 from cgwalters/revert-staged-bootconfig-extra-merge

Revert "sysroot: Merge bootconfig-extra from previously staged deployment"

Revert "sysroot: Merge bootconfig-extra from previously staged deployment"

This reverts commit 4c0d3a819033166ec9753ff8c5fdac5db1bac813.

The 3-way merge of bootconfig-extra during staging breaks bootc
loader-entries set-options-for-source when called multiple times on the
same boot.  Each call sets the desired x-options-source-* keys on the
merge deployment's in-memory bootconfig, but the merge logic gives
higher priority to the previously staged data, overriding the caller's
updates.  This corrupts the source-tracking metadata that bootc relies
on to compute override_kernel_argv, causing stale kargs to persist
across reboots.

The scenario this commit was trying to fix (rpm-ostree re-staging after
bootc on the same boot, preserving bootc's extension keys) will need a
different approach that does not conflict with callers that update
extension keys across multiple stagings.

Signed-off-by: Colin Walters <walters@verbum.org>

Release

Make fast forward from 2026.1-1

[dgit --quilt=gbp]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

Use dpkg build API v1

d/control: Stop running dwz

Bump debhelper compat level to 14

- Remove ${misc:Depends} etc., now added automatically
- Temporarily add dh-sequence-dwz build-dep for less diffoscope noise

New upstream release

Update upstream source from tag 'upstream/2026.2'

Update to upstream version '2026.2'
with Debian dir 41b5289bd97de17ca7f65f7e74b8cd77343c391a

New upstream version 2026.2

prepare-root: create /run/systemd/volatile-root for composefs

systemd resolves the block device backing the root filesystem via
blockdev_get_root(), which checks "/" and falls back to "/usr". With
composefs enabled both are overlayfs mounts with an anonymous st_dev
(and prepare-root intentionally skips the read-only /usr bind mount in
that case), so the lookup finds no device. As a result
systemd-gpt-auto-generator silently skips all partition discovery: the
ESP is never automounted on /boot, which in turn breaks tools that
expect the bootfs to be reachable, e.g. bootctl, systemd-bless-boot
(boot counting) and "ostree admin status" when the loader entries live
on the ESP.

systemd provides a hook for exactly this situation: if the root mount
has been replaced by some form of volatile file system, the original
root block device is expected to be symlinked at
/run/systemd/volatile-root. Create that symlink when composefs is in
use. Note the target must be in the /dev/block/MAJ:MIN form since
systemd parses it without ever going to disk
(device_path_parse_major_minor()).

The root device is resolved as follows: prefer /dev/gpt-auto-root when
it exists, since on systemd-based initrds udev has already identified
the root partition for us (EFI boot with LoaderDevicePartUUID set and
a discoverable-partitions-spec root partition type). Otherwise fall
back to stat()ing the root mountpoint, which also covers initrds
without systemd (e.g. meta-updater). Since btrfs reports an anonymous
st_dev (major 0) for its mounts, in that case query the backing device
via BTRFS_IOC_FS_INFO/BTRFS_IOC_DEV_INFO the same way systemd's
btrfs_get_block_device_fd() does, refusing multi-device filesystems
just as systemd does. This matters in practice as Fedora Atomic
Desktops default to composefs on btrfs.

bootc solves the same problem the same way for its composefs-native
backend: bootc-root-setup.service (gated on the composefs= karg) runs a
gpt_workaround() that creates this exact symlink. That service is
ordered after ostree-prepare-root.service, so with this change the
symlink already exists by the time it runs; bootc is being updated to
tolerate that instead of failing. See also the systemd discussion of
gpt-auto with overlay roots:
https://github.com/systemd/systemd/issues/35017

Failure to create the symlink is not fatal: the system boots fine
without it, only auto-discovery of auxiliary partitions is degraded.

Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com>

admin: Drop UNLOCKED flag from instutil set-kargs

In bf59d0c6 we added `OSTREE_ADMIN_BUILTIN_FLAG_UNLOCKED` to the
instutil subcommands, including `set-kargs`.  At the time, this flag
only controlled sysroot locking, and the commit message notes these
commands were "only used by Anaconda" so locking was unnecessary.

However, 599ffefe later consolidated mount namespace setup into the
same `if (!UNLOCKED)` block, so `UNLOCKED` now also means "skip
`ostree_sysroot_initialize_with_mount_namespace()`".  Without the
mount namespace, `_ostree_sysroot_ensure_writable()` is a no-op, and
any subsequent write to `/sysroot` fails with EROFS on systems where
the sysroot is mounted read-only (the default since composefs).

The practical symptom is:

  $ ostree admin instutil set-kargs --import-proc-cmdline
  error: mkdir(boot.1.0): Read-only file system

Dropping the flag is safe for the installer case: when not booted
into an ostree-managed system, `initialize_with_mount_namespace()`
returns early (since `root_is_ostree_booted` is FALSE), and the lock
acquisition is harmless on a writable target sysroot.

ci: revert removing coreos-ci Jenkins CI job

This partially reverts commit 3a4ced5c97bee5196f33feea6c685e191e129acf.

Restore .cci.jenkinsfile — the coreos-ci Jenkins pipeline is still in
use and should not have been removed.

Merge pull request #3606 from jmarrero/release-20262

Release 2026.2