1

So I've read the wiki and this answer, and I'm still a bit overwhelmed. In the wiki it feels like a lot of these are optional.

Here's what I did. I used Manjaro to install into a single partition, which I may be regretting, and I enabled full disk encryption. What I observe when booting, to either windows or Linux, is I'm prompted for a password, and then I see the actual grub menu.

I'm not then certain which options will work. I think that LVM is enabled, but not 100% and I'm sure I selected ext4. I looked at modifying the grub.conf generation scripts, but I'm not sure where, nor am I sure if that's the right place.

What's the right answer for adding discard, no_read_workqueue, and no_write_workqueue on Manjaro?

UPDATE:

here's what my most current configuration is, but I keep getting dropped into a rescue shell. I'm trying to used the systemd cryptsetup to do all the things, which seems to suggest that I use luks.* parameters.

note: the name root is coming from my manual mounting in the rescue shell.

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS                                MOUNTPOINT                                 UUID
loop0         7:0    0 450.2M  1 loop  /var/lib/snapd/snap/wickrme/543            /var/lib/snapd/snap/wickrme/543            
loop1         7:1    0  55.4M  1 loop  /var/lib/snapd/snap/core18/2074            /var/lib/snapd/snap/core18/2074            
loop2         7:2    0  65.1M  1 loop  /var/lib/snapd/snap/gtk-common-themes/1515 /var/lib/snapd/snap/gtk-common-themes/1515 
loop3         7:3    0  32.3M  1 loop  /var/lib/snapd/snap/snapd/12398            /var/lib/snapd/snap/snapd/12398            
zram0       253:0    0   1.5G  0 disk  [SWAP]                                     [SWAP]                                     
nvme0n1     259:0    0 953.9G  0 disk                                                                                        
├─nvme0n1p1 259:1    0   100M  0 part  /boot/efi                                  /boot/efi                                  6CEB-F417
├─nvme0n1p2 259:2    0    16M  0 part                                                                                        
├─nvme0n1p3 259:3    0 780.6G  0 part                                                                                        
├─nvme0n1p4 259:4    0   508M  0 part                                                                                        CA343C30343C223D
├─nvme0n1p5 259:5    0 146.5G  0 part                                                                                        74c51543-eb14-4f61-afeb-b5de6c10a32a
│ └─root    254:0    0 146.5G  0 crypt /                                          /                                          e0a93c98-88a8-4fc9-9948-acdb423d05fd
└─nvme0n1p6 259:6    0  18.6G  0 part  [SWAP]                                     [SWAP]                                     72db96da-87e4-4b17-a622-6a4d56b314c6
4 ❯ cryptsetup luksDump /dev/nvme0n1p5                                                                                                                                                                         # ~
LUKS header information for /dev/nvme0n1p5

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
UUID:           74c51543-eb14-4f61-afeb-b5de6c10a32a
❯ cat /etc/default/grub | grep -v -e '^[[:space:]]*$' -e '^#'                                                                                                                                                  # ~
GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=hidden
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.uuid=74c51543-eb14-4f61-afeb-b5de6c10a32a luks.options=discard,no_read_workqueue,no_write_workqueue root=/dev/mapper/luks-e0a93c98-88a8-4fc9-9948-acdb423d05fd splash apparmor=1 security=apparmor udev.log_priority=3"
GRUB_CMDLINE_LINUX=""
GRUB_SAVEDEFAULT=true
GRUB_PRELOAD_MODULES="part_gpt part_msdos"
GRUB_TERMINAL_INPUT=console
GRUB_GFXMODE=1280x768x32,auto
GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_OS_PROBER=false
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"
GRUB_THEME="/usr/share/grub/themes/manjaro/theme.txt"
GRUB_ROOT_FS_RO=true
GRUB_ENABLE_CRYPTODISK=y

from what I understand systemd-cryptsetup-generator shouldn't need more options, I do have an /etc/crypttab but everything is commented out.

I'm fairly confident that GRUB_CMDLINE_LINUX_DEFAULT is my only problem, I'm not certain what it should be though. google isn't finding me a lot of (read no) examples of how to do this with the output of blkid or lsblk.

0

I finally figured it out, order to fix my boot, and get the features I want I had to do this.

GRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=UUID=74c51543-eb14-4f61-afeb-b5de6c10a32a:root:allow-discards,no-read-workqueue,no-write-workqueue quiet udev.log_priority=3"
-1

TLDR - If possible don't encrypt the entire disk, if possible give it some completely unpartitioned breathing room at the end, and keep mostly defaults in fstab.

This is one of those user choice trade offs where I am uncertain so I err on the side of caution and go with the maintainers.

That being said, the TRIM commands have the potential to lengthen the life of an SSD, but they also have the potential to increase vulnerability of that LUKS partition.

How much does it actually reduce the life of the drive to have them on? How much are you comfortable with?
How much of the drive must actually be encrypted? How vulnerable is your encrypted data with TRIM?

And it can also be done manually, on a cron, or as a service

I have stuck with the defaults on multiple machines and I always encrypt the root, but only usually 100GB LUKS partition, with in the very least root and home in there, on my desktops I typically have a few drives mounted in too that have no encrypted partitions whatsoever. Overall I don't think I've seen any personal drives die early from this when compared to the drives without encrypted partitions. I can't recall having owned a dead SSD yet aside from one misbehaving msata from an overheating laptop (it will go no data at some point when the machine gets hot). But I have heard of certain RAID 5 hardware controllers killing SSDs due to some similar situation. EDIT: I take back the not owning any dead SSDs, I have a box of SSD drives that were never good in the first place, a few odds and ends that were bad, but in particular a bunch of cheap SSDs from a big name two letter computer company that were sold around the block by a corporate office retail company that were known to just go belly up after a few of hours of use.

And it's possible, in terms of SSD wear, noatime is more important, especially on read intensive drives/partitions:

To mitigate some of this I typically do not even partition the last 10% of a drive giving the wear rotators lots to gnaw on even if I fill the disk (this is in addition to the typical reserved blocks of a file system). I have not used a swap partition on a personal machine in over a decade. And I do not encrypt the entire disk, I encrypt root, home usr and var inside an LVM on LUKS , and then make other data partitions outside of that where I try to place stuff that does not matter, for example a /mnt/steam partition for a SteamLibrary as this can be blown away and redownloaded with ease. 100GB LUKS partition is typically more than enough for the arch root usr var home partitions, and most modern machines I've got tons of RAM so I use tmpfs for /tmp. And I install a ton of software, so /usr is:

du -sh /usr
26G     /usr

to see if you have an lvm use the commands pvscan lvscan vgscan example:

[root@examplenode1 ~]# lvscan
  ACTIVE            '/dev/examplemachineVG/examplemachineRoot' [40.00 GiB] inherit
  ACTIVE            '/dev/examplemachineVG/examplemachineHome' [70.98 GiB] inherit
[root@examplenode1 ~]# vgscan
  Found volume group "examplemachineVG" using metadata type lvm2
[root@examplenode1 ~]# pvscan
  PV /dev/mapper/examplemachinecrypt   VG examplemachineVG          lvm2 [110.98 GiB / 0    free]
  Total: 1 [110.98 GiB] / in use: 1 [110.98 GiB] / in no VG: 0 [0   ]

also check the contents of

/dev/mapper/

and

/etc/fstab
/etc/mtab
2
  • to find out if lvm is there try these commands lvscan pvscan vgscan
    – thoth
    Jul 10 at 21:14
  • Don't worry about noatime, relatime is the default and this mostly gives the benefits of atime, but without the drawbacks - especially for a SSD. Jul 16 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.