Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1801539

Summary: Silverblue 38 can't fstrim some partitions of SSD hard drive
Product: [Fedora] Fedora Reporter: Junjie Yuan <yuan>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 38CC: anaconda-maint-list, brad.ison, dasebek, delor.vd, dng, dustymabe, henrique.ferreiro, jkonecny, jlebon, jonathan, jonathan, jurf, kdudka, kellin, miabbott, ovasik, philip.wyett, pknirsch, stefano, tpopela, vanmeeuwen+fedora, vponcova, vslavik, walters, wwoods, yuan
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Junjie Yuan 2020-02-11 06:36:29 UTC
Description of problem:
Silverblue 31 can't fstrim some partitions of SSD hard drive

Version-Release number of selected component (if applicable):
[junjie@xps ~]$ fstrim --version
fstrim from util-linux 2.34

[junjie@xps ~]$ rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/31/x86_64/silverblue
                   Version: 31.20200210.0 (2020-02-10T00:40:47Z)
                BaseCommit: 5d20cf79b4efde70a873d815015554f169f58085576aabcf4fe34c1ea54edf4e
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
             LocalPackages: google-chrome-stable-80.0.3987.87-1.x86_64

  ostree://fedora:fedora/31/x86_64/silverblue
                   Version: 31.20200209.0 (2020-02-09T00:44:42Z)
                BaseCommit: 1d84699a832851471d71804bb2933fe2241d3e341e0d34ca360543e10d8d2fe3
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
             LocalPackages: google-chrome-stable-80.0.3987.87-1.x86_64

How reproducible:
[junjie@xps ~]$ sudo fstrim -av
/boot/efi: 569.5 MiB (597159936 bytes) trimmed on /dev/sda1
/boot: 0 B (0 bytes) trimmed on /dev/sda2

[junjie@xps ~]$ sudo fstrim /
fstrim: /: the discard operation is not supported

[junjie@xps ~]$ sudo fstrim /home
fstrim: /home: the discard operation is not supported

[junjie@xps ~]$ sudo fstrim /var/home
fstrim: /var/home: the discard operation is not supported

Steps to Reproduce:
1.sudo fstrim /
2.sudo fstrim /home
3.sudo fstrim -av

Actual results:
fstrim is only available in /boot and /boot/efi

Expected results:
fstrim works on all partitions, not just /boot and /boot/efi

Additional info:
I installed Silverblue 31 using the default installation option without modifying the file system.

[junjie@xps ~]$ df -Th
Filesystem              Type      Size  Used Avail Use% Mounted on
devtmpfs                devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs                   tmpfs     3.7G   65M  3.7G   2% /dev/shm
tmpfs                   tmpfs     3.7G  1.9M  3.7G   1% /run
/dev/mapper/fedora-root ext4       69G   21G   44G  33% /sysroot
tmpfs                   tmpfs     3.7G  100K  3.7G   1% /tmp
/dev/sda2               ext4      976M  141M  769M  16% /boot
/dev/sda1               vfat      599M   30M  570M   5% /boot/efi
/dev/mapper/fedora-home ext4       40G   33G  4.2G  89% /var/home
tmpfs                   tmpfs     756M   46M  711M   6% /run/user/1000

[junjie@xps ~]$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=3834560k,nr_inodes=958640,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/fedora-root on /sysroot type ext4 (rw,relatime,seclabel)
/dev/mapper/fedora-root on / type ext4 (rw,relatime,seclabel)
/dev/mapper/fedora-root on /usr type ext4 (ro,relatime,seclabel)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=7584)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/fedora-root on /var type ext4 (rw,relatime,seclabel)
/dev/sda2 on /boot type ext4 (rw,relatime,seclabel)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
/dev/mapper/fedora-home on /var/home type ext4 (rw,relatime,seclabel)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=773424k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Comment 1 David Sebek 2020-03-10 09:30:46 UTC
Are you using disk encryption? I came across a similar problem on my machines. It seems that somehow LUKS (dm-crypt) in Silverblue is not properly configured to pass discard commands. If I select disk encryption in Anaconda when installing Silverblue, fstrim does not work on the LUKS partition. Without disk encryption, TRIM works just fine. I have tested Silverblue 31 and Silverblue 32, the problem exists on both of them (only when using disk encryption). The problem is not present in regular Fedora Workstation 31 and 32.

Output of lsblk on my Fedora Silverblue 31 installation signalling that even though the storage device supports TRIM, it is blocked by LUKS (Silverblue 32 gives the same output):
[david@localhost ~]$ lsblk -D
NAME                                       DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                               0        4K       1G         0
├─sda1                                            0        4K       1G         0
├─sda2                                            0        4K       1G         0
└─sda3                                            0        4K       1G         0
  └─luks-31a68890-6d8b-42fc-a80f-2262577c1178
                                                  0        0B       0B         0
    ├─fedora-root                                 0        0B       0B         0
    ├─fedora-swap                                 0        0B       0B         0
    └─fedora-home                                 0        0B       0B         0
sr0                                               0        0B       0B         0

Comment 2 David Sebek 2020-03-10 13:12:47 UTC
I found a way to solve my problem with fstrim not working on LUKS on Silverblue. Comments in an old bug report #901888 provide some useful information. The problem seems to be caused by an omission of /etc/crypttab file in the initramfs image. This file is present in initramfs of Fedora Workstation (can be listed by the lsinitrd command), so I tried to include it in the initramfs of my Silverblue too:
[david@localhost ~]$ rpm-ostree initramfs --enable --arg=-I --arg=/etc/crypttab

After a reboot, fstrim works!
[david@localhost ~]$ lsblk -D
NAME                                       DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                               0        4K       1G         0
├─sda1                                            0        4K       1G         0
├─sda2                                            0        4K       1G         0
└─sda3                                            0        4K       1G         0
  └─luks-31a68890-6d8b-42fc-a80f-2262577c1178
                                                  0        4K       1G         0
    ├─fedora-root                                 0        4K       1G         0
    ├─fedora-swap                                 0        4K       1G         0
    └─fedora-home                                 0        4K       1G         0
sr0                                               0        0B       0B         0

Comment 3 Junjie Yuan 2020-03-17 16:03:21 UTC
(In reply to David Sebek from comment #1)
> Are you using disk encryption? I came across a similar problem on my
> machines. It seems that somehow LUKS (dm-crypt) in Silverblue is not
> properly configured to pass discard commands. If I select disk encryption in
> Anaconda when installing Silverblue, fstrim does not work on the LUKS
> partition. Without disk encryption, TRIM works just fine. I have tested
> Silverblue 31 and Silverblue 32, the problem exists on both of them (only
> when using disk encryption). The problem is not present in regular Fedora
> Workstation 31 and 32.
> 
> Output of lsblk on my Fedora Silverblue 31 installation signalling that even
> though the storage device supports TRIM, it is blocked by LUKS (Silverblue
> 32 gives the same output):
> [david@localhost ~]$ lsblk -D
> NAME                                       DISC-ALN DISC-GRAN DISC-MAX
> DISC-ZERO
> sda                                               0        4K       1G      
> 0
> ├─sda1                                            0        4K       1G      
> 0
> ├─sda2                                            0        4K       1G      
> 0
> └─sda3                                            0        4K       1G      
> 0
>   └─luks-31a68890-6d8b-42fc-a80f-2262577c1178
>                                                   0        0B       0B      
> 0
>     ├─fedora-root                                 0        0B       0B      
> 0
>     ├─fedora-swap                                 0        0B       0B      
> 0
>     └─fedora-home                                 0        0B       0B      
> 0
> sr0                                               0        0B       0B      
> 0

(In reply to David Sebek from comment #2)
> I found a way to solve my problem with fstrim not working on LUKS on
> Silverblue. Comments in an old bug report #901888 provide some useful
> information. The problem seems to be caused by an omission of /etc/crypttab
> file in the initramfs image. This file is present in initramfs of Fedora
> Workstation (can be listed by the lsinitrd command), so I tried to include
> it in the initramfs of my Silverblue too:
> [david@localhost ~]$ rpm-ostree initramfs --enable --arg=-I
> --arg=/etc/crypttab
> 
> After a reboot, fstrim works!
> [david@localhost ~]$ lsblk -D
> NAME                                       DISC-ALN DISC-GRAN DISC-MAX
> DISC-ZERO
> sda                                               0        4K       1G      
> 0
> ├─sda1                                            0        4K       1G      
> 0
> ├─sda2                                            0        4K       1G      
> 0
> └─sda3                                            0        4K       1G      
> 0
>   └─luks-31a68890-6d8b-42fc-a80f-2262577c1178
>                                                   0        4K       1G      
> 0
>     ├─fedora-root                                 0        4K       1G      
> 0
>     ├─fedora-swap                                 0        4K       1G      
> 0
>     └─fedora-home                                 0        4K       1G      
> 0
> sr0                                               0        0B       0B      
> 0

Yes, I used luks to encrypt my hard drive. Thank you very much for the solution! :)

Comment 4 Jonathan Lebon 2020-03-17 17:38:48 UTC
You can just add `rd.luks.options=discard` to the kargs. That way rpm-ostree doesn't have to rebuild the initramfs on each new deployment.

Comment 5 David Sebek 2020-03-18 10:10:38 UTC
In my case, I also solved it by replicating the content of /etc/crypttab to the kargs (instead of rebuilding the initramfs):
rpm-ostree kargs --append rd.luks.options=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx=discard

Is there any reason why it is not done automatically during the installation, or is this a bug?

Comment 6 Jonathan Lebon 2020-06-30 14:07:02 UTC
This isn't really an rpm-ostree bug. The LUKS mount needs to have the discard option enabled, either via kargs, or by editing crypttab and rebuilding the initramfs (I suggest the former).

Re-assigning to anaconda.

Comment 7 Fedora Program Management 2021-04-29 17:00:34 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Vladimír Slávik 2021-05-18 12:21:09 UTC
At a glance, it seems that the root cause is the same as bug 1890085 - a config file is missing in initramfs. The reason why it is missing is that Anaconda does not regenerate initramfs for rpm-ostree payloads, and that is because they are signed.

This problem can be solved the same way, if it is still present.

Comment 9 Junjie Yuan 2021-05-18 13:11:06 UTC
This problem can still be reproduced in fedora 34.

Comment 10 dngray 2021-12-27 14:59:14 UTC
(In reply to Jonathan Lebon from comment #6)
> This isn't really an rpm-ostree bug. The LUKS mount needs to have the
> discard option enabled, either via kargs, or by editing crypttab and
> rebuilding the initramfs (I suggest the former).
> 
> Re-assigning to anaconda.

I just installed Silverblue 35. I noticed "discard" was the last item on /etc/crypttab, however nothing in the boot options /boot/loader/entries/ostree-1-fedora.conf, /boot/loader/entries/ostree-2-fedora.confetc

Seeing as it's installed now, what is the way to fix this outside of Anaconda?

Comment 11 dngray 2021-12-27 15:04:45 UTC
(In reply to David Sebek from comment #5)
> In my case, I also solved it by replicating the content of /etc/crypttab to
> the kargs (instead of rebuilding the initramfs):
> rpm-ostree kargs --append
> rd.luks.options=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx=discard
> 
> Is there any reason why it is not done automatically during the
> installation, or is this a bug?

My bad. I missed this post.

Comment 12 Ben Cotton 2022-05-12 14:57:03 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 13 Ben Cotton 2023-04-25 16:39:59 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 14 Vincent 2024-04-27 18:50:36 UTC
Hello,

Just a quick note to report that this issue is still persisting in Fedora 40.

Regards,

Vincent.