On Sun, Nov 23, 2014 at 8:59 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Sun, Nov 23, 2014 at 12:27 PM, John Tall <mjtallx@xxxxxxxxx> wrote: > >> No. They are both regular GPT partitions. > > What results do you get for: > # journalctl -b -l -o short-monotonic | grep -i discard > > That may reveal the attempt to (re)mount sysroot with discard and why > it failed. If nothing comes up then boot debug options need to set. Not much, only two lines about the /boot partition. [ 27.339461] host1 systemd[1]: About to execute: /bin/mount -n /dev/disk/by-uuid/25692e3e-42cd-1923-bcd4-d3511ac23512 /boot -t xfs -o defaults,discard [ 27.341034] host1 systemd[507]: Executing: /bin/mount -n /dev/disk/by-uuid/25692e3e-42cd-1923-bcd4-d3511ac23512 /boot -t xfs -o defaults,discard > See if this works while you're at it: > # mount -o remount,discard / > > And then check mounts. It should now show discard is enabled. Unfortunately not, it does not show discard in /proc/mounts. > And while you're at it confirm this: > # sgdisk -i4 /dev/sda > > "partition GUID code" should be 0fc63daf-8483-4772-8e79-3d69d8477de4, > if you use one of the freedesktop discoverable partitions > partitiontypeGUIDs then systemd ignores fstab for that partition and > does its own automount. The partition GUID code is as expected 0FC63DAF-8483-4772-8E79-3D69D8477DE4. Same with -i2, the /boot partition. > Also FWIW discard isn't a good mount option to use for most SSDs with > non-queuable trim support. If it's one of the very newest SSDs > supporting queuable trim then it should be fine to set. Otherwise > you're better off with a weekly cron issuing fstrim. OK. Good tip! I'll do some testing if I can get discard working and keep that in mind. J -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
