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: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 38 | CC: | 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
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 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 (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! :) 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. 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? 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. 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. 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. This problem can still be reproduced in fedora 34. (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? (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. 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. 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. Hello, Just a quick note to report that this issue is still persisting in Fedora 40. Regards, Vincent. |