This is triggered on Atomic Desktops & IoT by the migration to composefs: https://gitlab.com/fedora/ostree/sig/-/issues/35

This is tracked in: https://github.com/containers/bootc/issues/971

We will likely end up masking this unit on Atomic Desktops.

Another option would be to have it remount /sysroot (the real root mount point on ostree/bootc systems) instead of /

Previous discussion in https://github.com/ostreedev/ostree/issues/3193

Hmm, various ideas were proposed in 3193, but then it was closed as "Not planned".
I still think that systemd-remount-fs can and should be changed to support the
setup where the root filesystem is not what is listed in /etc/fstab. It certainly
shouldn't error out. Masking the service does not seem like a good idea because
the users may rely on it for other filesystems.

It'd be really nice if we could address this, because this is the *only* test failure in openQA for Fedora 42 right now :D

Proposing as an FE for Final. If it were in a release-blocking image this would violate Final criterion "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present." Silverblue is not release blocking, and this doesn't seem to be happening on IoT for whatever reason, but it does seem reasonable to give it an FE for Silverblue.

+4 in https://pagure.io/fedora-qa/blocker-review/issue/1834 , marking accepted FE.

This does not happen on IoT anymore as they tweaked the fstab entry to match: https://github.com/fedora-iot/iot-distro/issues/81

For Atomic Desktops, this is triggered by `compress=zstd:1` which is only in /etc/fstab and not on the kernel command line: https://gitlab.com/fedora/ostree/sig/-/issues/72

https://github.com/systemd/systemd/compare/main...travier:systemd:remount-fs-sysroot appears to make the error go away, but I had an error previously so I don't know if there is a race or not. It also does not solve the issue for compression (but that could be https://bugzilla.redhat.com/show_bug.cgi?id=2332319 instead or something else)

Script like version of what we would have to do to fix the compression karg (would still fail on first boot):

```
# Check stamp or check command line?
if [[ -f "/var/lib/.stamp" ]]; then
    exit 0
fi

fstype="$(findmnt /sysroot --json --output FSTYPE | jq -r '.filesystems[0].fstype')"
if [[ "${fstype}" != "btrfs" ]]; then
    echo "Not using btrfs for /"
    touch /var/lib/.stamp
    exit 0
fi

compress="$(cat /etc/fstab | grep -vE "^#|^$" | awk '{ if ($2 == "/") { print $4 } }' | grep -c '^subvol=root,compress=zstd:1,ro$')"
if [[ "${compress}" != "1" ]]; then
    echo "Not using btrfs for /"
    touch /var/lib/.stamp
    exit 0
fi

rpm-ostree kargs --delete=rootflags=subvol=root --append=rootflags=subvol=root,compress=zstd:1
touch /var/lib/.stamp
```

This should only touch default configs. Maybe we could add that to bootc alongside the workaround that already exists.

Common Issue description:
https://discussion.fedoraproject.org/t/common-issue/148562

Still valid in current Rawhide.

I believe this is the same bug as described in https://bugzilla.redhat.com/show_bug.cgi?id=2439682#c3, CC'ing the reporter (Christopher Klooz).

*** Bug 2379895 has been marked as a duplicate of this bug. ***

I have to plead extreme ignorance on most Linux topics, so I apologize if ‘butting in’ here is inappropriate, but after needing to use a Live ISO (Bazzite KDE in my case) to restore the boot loader, I was dumped into the ‘emergency’ mode that needed a root password, when my original Fedora 42 Kenoite Atomic had “discouraged” me against setting up a root account/password.

I tried a number of possibilities in case maybe I had set one, to no avail, and now root is locked out.

I have tried a number of times to follow various guides to “use a Live ISO to replace root’s password”, also unsuccessfully.

Currently I am using rd.break and various commands to ‘remount /sysroot with read-write’ (<mount -oremount,rw /sysroot> being the latest) but I get the following output:

mount: /sysroot: fsconfig() failed: overlay: No changes allowed in reconfigure.
       dmesg(1) may have more information after failed mount system call.


Is there anything else I might be able to try? Either to fix this mounting issue or to ‘bypass’ the emergency mode to complete a regular boot into the OS?

Thanks!

Nothing against this forum, but I’ve decided “I’m done” with my current quagmire and will simply overwrite my installation/OS. Those few files I most worry might be irreplaceable, I’ve copied onto another drive/partition for safekeeping.