This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Please see the Common Issue for solution/workarounds:
My F41 Silverblue /etc/fstab contains subvol=root,compress=zstd:1,x-systemd.device-timeout=0 and the same parameters for other subvolumes. Should I remove x-systemd.device-timeout=0 from them (or maybe add it to subvol=root’s kargs?) and add ro to subvol=root? If yes, can I do it before rebasing to F42?
Only add the compress=zstd:1 part to the kernel command line. Don’t add x-systemd.device-timeout=0 or ro to the kernel command line.
You can do it anytime. Before rebasing to F42 is fine.
I have the following kernel arguments, which specify zstd compression and noatime:
$ rpm-ostree kargs
rhgb quiet root=UUID=c9abf553-35aa-4590-b0d0-de337c28bddd rw ostree=/ostree/boot.0/fedora/bbfc12aa3893a0b8045484542828d31e113339344b94475623d47b05d418cd27/0 amd_pstate=guided rootflags=subvol=root,compress=zstd,noatime
But I see that the composefs overlay at / has the following options, which has no compression and relatime:
findmnt -T /
TARGET SOURCE FSTYPE OPTIONS
/ composefs overlay ro,relatime,seclabel,lowerdir+=/run/ostree/.private/cfsroot-lower,datadir+=/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on
What’s the resultant behavior? Is the immutable base commit data compressed, and any overlaid data non-compressed?
Thank you, Timothée, for your help!
You need to look at the /sysroot mount point. The options set on the command line are for the real root mount point, which ends up at /sysroot in the final system. The composefs / is not mounted using any of those options.
Apologies for replying on a closed topic.
I was holding the upgrade to 42 because of this (because I’m lazy tbh), but after reading the workaround and the anaconda bug report it sounds like, even once such bug is resolved, this will not be automatically fixed for existing installations and the fix seems to, basically, apply the workaround at installation time.
Fixing this automatically for existing installations is definitely part of the plan for fixing this issue.
I don’t think this bug should hold you from updating to Fedora 42. There are no risk of data loss and if you care about zstd compression then the workaround should be straightforward to apply. If you don’t care about compression (which only got added in recent installations) then this is mostly cosmetic.
The only case where this could be an issue (and applying the workaround would fix it) is if you manually set special mount options for the /proc and /sys filesystems, but that’s not the default.
Thanks a lot @siosm , I was completely wrong then 
I guess once the fix is delivered, the effect will be the similar to applying the workaround and will have no impact on running systems where the workaround is manually applied. Does that sound reasonable?
Exactly, the goal is to figure out how to apply the workaround at scale, safely, and only if needed (i.e. if not applied already).
I know root is ignored but my /home & /var also ignored.
$ cat /etc/fstab | grep -m 1 home
UUID=dbab971b-aa5c-412b-85aa-837f7370ef2c /home btrfs subvol=home,nodiscard,noatime,compress-force=zstd 0 0
$ findmnt -T /home
TARGET SOURCE FSTYPE OPTIONS
/var/home /dev/nvme0n1p3[/home] btrfs rw,noatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/home
That’s unexpected. Both of those partitions should be mounted from systemd units generated from the content of /etc/fstab. Can you look at those units to verify that they are correctly generated?
Yes, they are generated correctly, but for some reason, my mount does not follow either fstab or systemd. Do you think It’s because I am using root-transient?
$ systemctl cat var-home.mount
# /run/systemd/generator/var-home.mount
# Automatically generated by systemd-fstab-generator
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
After=blockdev@dev-disk-by\x2duuid-dbab971b\x2daa5c\x2d412b\x2d85aa\x2d837f7370ef2c.target
[Mount]
What=/dev/disk/by-uuid/dbab971b-aa5c-412b-85aa-837f7370ef2c
# Canonicalized from /home
Where=/var/home
Type=btrfs
Options=subvol=home,nodiscard,noatime,compress-force=zstd
$ systemctl status var-home.mount
● var-home.mount - /var/home
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Wed 2025-05-14 00:20:08 +03; 15h ago
Invocation: 5d0a3f330c5f4d74a7a7aa6e8ba17f79
Where: /var/home
What: /dev/nvme0n1p3
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 37963)
Memory: 88K (peak: 1M)
CPU: 5ms
CGroup: /system.slice/var-home.mount
May 14 00:20:08 fedora-t480 systemd[1]: Mounting var-home.mount - /var/home...
May 14 00:20:08 fedora-t480 systemd[1]: Mounted var-home.mount - /var/home.
$ findmnt -T /var/home
TARGET SOURCE FSTYPE OPTIONS
/var/home /dev/nvme0n1p3[/home] btrfs rw,noatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/home
I wrote about what I believe is a related problem some time ago but did not get many replies to it: https://discussion.fedoraproject.org/t/f42-silverblue-and-fstrim/148952
Am I the only one with this “fstrim” problem or is it a general problem with Fedora Atomic Desktops using the current way of mounting the root filesystem?
Have you looked at Enable fstrim on LUKS encrypted partitions · Issue #31 · fedora-silverblue/issue-tracker · GitHub?
Did you add the compress=zstd option to the kernel arguments as described in the solution here? Compression is enabled for the entire btrfs filesystem, so if your var or home is a subvolume in the same btrfs partition then it needs it enabled for root as well.
Yes /var & /home is a subvolume in the same btrfs partition. Adding option to the kernel arguments for root partition solve my subvolume mount options problem but what about if I want to add special mount option to just /home subvolume?
No, I had not but did take a look at it just now. Unfortunately I cannot see how it relates to the problem I describe. My root filesystem is plain xfs and no encryption involved.
Let me show some info about this:
From btrfs(5) § MOUNT OPTIONS: “Most mount options apply to the whole file system, and only the options for the first subvolume to be mounted will take effect. This is due to lack of implementation and may change in the future.”
From Btrfs Wiki FAQ for which mount options can be used per subvolume:
Can I mount subvolumes with different mount options?
The generic mount options can be different for each subvolume, see the list below.
Btrfs-specific mount options cannot be specified per-subvolume, but this will be
possible in the future (a work in progress).
Generic mount options:
nodev, nosuid, ro, rw, and probably more. See section FILESYSTEM INDEPENDENT MOUNT OPTIONS of man page mount(8).
Yes for btrfs-specific options:
subvol or subvolid
Planned:
compress/compress-force, autodefrag, inode_cache, ...
No:
the options affecting the whole filesystem like space_cache, discard, ssd, ...