Hello,
First, thank you for your adaptation of this guide and maintaining it.
I installed Artix on a new computer these last few days (I first spent hours deciding of my setup, then tried several configurations, and ran into a few problems, it probably was my most complicated installation since a long time).
I read your guide and mixed it with another one, a wiki and random threads more up-to-date on certain aspects (mainly EFI, also different encryption models) as well as reading what each step was doing and why do it this way.
I have a second disk with two partitions mounting on /home/backup and /home/data. Also my SSD are identified as nvmeXn1 and partitions as nvmeXn1pY. I will do as if I only have one drive and simulate /dev/sdaX to shorten the syntax.
I have a Meteor Lake CPU, 2 SSD, wanted Xfce as a desktop environment and LightDM as a login manager. The other software is not relevant to this comment.
I tried to write some complementary remarks, approximately in the same order than the guide. Good luck with it, I am often quite confused when writing and even more in English.
You could use GPT as a partition table instead of MBR, it might especially be useful on computers with UEFI, but is also supported with BIOS. I will try to remember of the different changes it needs and also write them in the guide order.
The first change is that with GPT, the first option of mklabel is not primary/logical anymore, but the disk label; this means that the example linked on rohlix.eu set “primary” as the labels to his partitions. Also, fat32 could (should?) then be used for the ESP partition with mklabel, and must be reused with mkfs.fat (as showed Artix main installation guide).
I am not sure about the lvm flag when using LVM on LUKS. I set it when I installed the other way around (LUKS on LVM) before reinstalling because it was harder to get what I wanted (except the graphics which instantly worked…), now it works without the lvm flag but would probably also work with.
parted /dev/sdX mklabel gpt
parted -a optimal /dev/sdX mkpart "boot" "ext4" "1MiB" "1025MiB"
parted -a optimal /dev/sdX mkpart "bootefi" "fat32" "1025MiB" "2049MiB"
parted -a optimal /dev/sdX mkpart "main" "ext4" "2049MiB" "100%"
parted /dev/sdX set 2 esp on
mkfs.fat -F 32 /dev/sdX2
Note that FAT32 can be used with /boot partition, it may even be better for multi-environment booting.
LUKS2 (default) has been OK for the last few years, so it better to use (more secure, I believe that the key is copied at several places in case some get corrupted).
Even when you want to encrypt /boot, you can keep luks2 with GRUB (not with other boot loaders), but need to use --pbkdf pbkdf2. The --hash sha512 is still a good option. I did not try the Serpent cipher; it is slower, so is probably marginally more secure because the attacker would not have the instruction set, but neither do you so it probably is slower at execution.
My command was just:
cryptsetup --verbose --hash sha512 --verify-passphrase luksFormat /dev/sdX3
After setting the last logical volume on a volume group containing at least one ext4 partition, you can reduce one of the logical volume of at least 256MiB with lvreduce -L -256M lvmSystem/volhome
(for example). It lets e2scrub run to check the filesystem metadata.
Not sure if contiguous is needed or even better with SSD.
I ran fstabgen, but only to look for the mount options it suggested and compared them with what Calamares set and what I have on my current computer.
I often read that periodic TRIM is better for SSD longevity than discard option. Also you should add noatime (it can break some software like mutt) or at least relatime to decrease the writes. I have not tried lazytime which was introduced a few years ago (but is seems useless with noatime which I set).
root password should have been set by Calamares installer and setting it up was not needed in my case.
The keyboard hook might need to be placed before autodetect when using an external keyboard on a laptop (the only minor drawback is that placing hooks before autodetect slightly enlarge the initramfs produced).
When using a non-QWERTY layout, it is also better to place keymap and consolefont before encrypt and set the correct layout in /etc/vconsole.conf.
HOOKS=(base udev keyboard autodetect microcode modconf kms keymap consolefont block lvm2 encrypt filesystems fsck)
I am not sure about what the net.ifnames=0 kernel parameter does. I have this parameter on my current computer, it keeps the interfaces names the old way (ethX, wlanY…). I tried without it this time until I understand what the implications are.
GRUB_ENABLE_CRYPTODISK=y is only needed when /boot is encrypted.
You can add the parameter root=/dev/lvmSystem/volRoot to the kernel parameters line. It is not needed when generating grub.cfg with grub-mkconfig, but as adding the device seems to be advised in most of the documentation I found, I believe it is better as fallback functioning. With my configuration, with /boot and /boot/efi separated, the line looked like:
grub-install --target=x86_64-efi --esp-directory=/boot/efi --boot-directory=/boot --bootloader-id=artix --recheck
With UEFI, the first parameter should be changed to --target=x86_64-efi, another parameter --esp-directory=/boot/efi added (or /boot or /efi, as the person wants it¹), and no device path at the end.
Important: also with UEFI, install efibootmgr at the same time than grub or at least before launching grub-install, otherwise it shows errors and probably does not work.
Still with an UEFI computer, with root and other partitions encrypted, but an unencrypted /boot, the cleanest way I partitionned my disk was with: a partition for root /, another one for /home (this is quite a must), one for swap, and I also set a specific partition for /var but that is less useful (and a last one for /opt which will be useless, we will no longer care about it), all of them on the LVM volume group.
I also set up /boot and /boot/efi separated, so I can encrypt /boot if I want one day. I did not encrypt /boot, as it is slower to boot, and you either need to enter two passwords (the one for /boot and the one for root), or let a root keyfile in the encrypted boot partition. However, the /boot partition can not have Argon2 KDF, so letting the keyfile of a more secure partition in /boot would downgrade its security to the weakest link of the chain.
My partition scheme is (without the quite-useless stuff):
/dev/sda with GPT partition table
/dev/sda1 /boot ext4 or fat32
/dev/sda2 esp flag /boot/efi fat32
/dev/sda3 encrypted with LUKS and partitioned into a LVM container
/dev/mapper/lvmsys (second SSD is lvmdata, but whatever)
/dev/MyVolGroup/volroot / ext4
/dev/MyVolGroup/volvar /var ext4
/dev/MyVolGroup/volswap [SWAP]
/dev/MyVolGroup/volhome /home ext4
/dev/mapper/lvmsys as the LVM physical volume.
MyVolGroup as the volume group.
The logical volumes of this VG are: volroot (32 GB), volvar (16 GB), volswap (normally RAM size, but I gave it half, I will see if it can suspend) and volhome (the rest minus 1 GB for
e2scrub).
I used ext4 for all of the volumes (except the one where the ESP is). It never failed me, should do great with periodic TRIM (and noatime or at least relatime mount option in fstab). I thought about using Btrfs, especially for its compression feature; but I believe that Btrfs loses a bit of its usefulness with LVM already on top which can do (block) snapshots and resize quite easily.
I had a blank screen problem after installing xfce4 and LightDM; only the tty were working. It turned out that I needed to remove xf86-intel-driver and install intel-media-driver.
As I mentioned, I first tried to install LUKS on LVM and maybe can complement another guide if you would like to.
It was much more complex, I had less experience, and I had to mix two or three different guides to get what I wanted (basically the one from ArchWiki and the Artix one). It made sense, as I have two SSD and thought a volume group with two physical volumes (/boot excluded) so I had a huge 1.8 TB /home would be the cleanest scheme.
However, Calamares always failed (the pacman commands) so I installed the system manually with pacstrap. I may had not correctly installed GRUB (or maybe I did it correctly) and had to enter my LUKS password before GRUB in QWERTY and after GRUB in QWERTY, with a minor non-blocking error appearing after GRUB. Only the root volume automounted after that, all the other volumes had to be manually mounted even with crypttab configured and keyfiles working when doing it manually. What was strange is that I had less problems to get the display and login working, I installed xfce4 and LightDM and that was it, no need to remove and add other drivers.
All in all, it is probably best this way, because if one SSD failed, the whole volume group would have failed and all data be inaccessible.
Still it was interesting, and as bad as I am in Linux administration, if you want some information in order to write a guide, I can try to remember.
¹ Setting the EFI directory directly in /boot is the easiest way as you can follow the same commands as with MBR. Setting it in /efi seems to be popular with Arch as some systemd programs
default to it. Finally, /boot/efi probably is a clean way to do it, as you can make the special ESP partition for it separated from an encrpyted /boot, so you could still dual-boot without
problem if you need. Setting it in a separated /efi would also work for dual-booting, but it does not look as logical to me.
Topic: Full Disk Encryption for a new install: force GRUB to ask a passphrase for LUKS? (Read 28297 times)
previous topic - next topic
