Prepare a NVME SSD for moving an ArchLinux Installation

Readings

1. Secure erase the device

pacman -S nvme-cli
nvme id-ctrl -H /dev/nvme0 | grep -iP "format|erase" See details
nvme format /dev/nvme0n1 --ses=1
Optional blkdiscard /dev/nvme0n1 an alternative to nvme format

I pretty sure --ses option is ignored because not supported by my device

2. Create the partition table

gdisk /dev/nvme0n1

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624      1953525134   931.0 GiB   8309  Linux LUKS

3. Prepare UEFI boot partition

mkfs.fat -F32 /dev/nvme0n1p1

4. Prepare LUKS volume

cryptsetup luksFormat /dev/nvme0n1p2
cryptsetup open /dev/nvme0n1p2 cryptlvm

5. Make a LVM and filesystems

pvcreate /dev/mapper/cryptlvm
vgcreate blackssd /dev/mapper/cryptlvm
lvcreate -L 16G blackssd -n swap
lvcreate -L 50G blackssd -n root
lvcreate -L 8G blackssd -n tmp
lvcreate -L 30G blackssd -n var
lvcreate -L 340G blackssd -n home

6. Copy the filesystems from the old VG to the new one

Theorically it make much more sense to use pvmove but I want to be able to boot the old system if my attempt to make it boot failed.

https://askubuntu.com/questions/90940/how-to-move-copy-logical-volume-lv-to-another-volume-group-vg#answer-931082

pacman -S partclone
Then :

lvcreate --snapshot --size 1G /dev/ssd/root --name root-backup && \
  partclone.ext4 --dev-to-dev --source /dev/ssd/root-backup --output /dev/blackssd/root && \
  lvremove --yes /dev/ssd/root-backup

lvcreate --snapshot --size 1G /dev/ssd/var --name var-backup && \
  partclone.ext4 --dev-to-dev --source /dev/ssd/var-backup --output /dev/blackssd/var && \
  lvremove --yes /dev/ssd/var-backup

lvcreate --snapshot --size 1G /dev/ssd/tmp --name tmp-backup && \
  partclone.ext4 --dev-to-dev --source /dev/ssd/tmp-backup --output /dev/blackssd/tmp && \
  lvremove --yes /dev/ssd/tmp-backup

lvcreate --snapshot --size 5G /dev/ssd/home --name home-backup && \
  partclone.ext4 --dev-to-dev --source /dev/ssd/home-backup --output /dev/blackssd/home && \
  lvremove --yes /dev/ssd/home-backup

Here you can just follow the installation process in place of copying the old one see the next section.

7. Configure the installed OS for booting properly

Archlinux installation details

Mount file-systems

mount /dev/blackssd/root /mnt/newsys
mount /dev/blackssd/var /mnt/newsys/var
mount /dev/blackssd/tmp /mnt/newsys/tmp
mount /dev/blackssd/home /mnt/newsys/home
mount /dev/nvme0n1p1 /mnt/newsys/boot

Copy the old /boot to the new one rsync -av /boot/ /mnt/newsys/boot/
pacman -S arch-install-scripts
Check UUID lsblk -f, you just need to change UUID for boot partition and the mapper name of all LVs. Or you can use genfstab -L /mnt/newsys
Make the swap mkswap /dev/mapper/blackssd-swap
Chroot in the new fs arch-chroot /mnt/newsys
Edit /etc/mkinitcpio.conf with HOOKS="base udev autodetect keyboard keymap modconf block encrypt lvm2 filesystems fsck"
Build the initramfs mkinitcpio -p linux
Add the boot entry efibootmgr --disk /dev/nvme0n1 --part 1 --create --label "Black Install" --loader /vmlinuz-linux --unicode 'cryptdevice=UUID=ab7080d3-7ec1-454d-bf6e-3cdd4eeb0cbe:cryptlvm:allow-discards root=/dev/mapper/blackssd-root resume=/dev/mapper/blackssd-swap initrd=\intel-ucode.img initrd=\initramfs-linux.img' --verbose
Unmount fs umount -R /mnt/newsys

8. Enable FStrim

You can enable trim on dmcrypt device but beware it can reveal what kind of filesystems and partitions you have inside. Details about DmCrypt discard feature. I'm not very concerns about this because the kernel and init image reveal what kind of stuff I used. You have better performance and ssd lifespan using it.

Enable trim on the dm-crypt with :allow-discards after cryptdevice boot paramater see ahead efibootmgr command.
Enable fstrim weekly timer systemctl enable fstrim.timer
Do a manual trim systemctl start fstrim.service
See the logs journalctl -u fstrim.service

9. Securing the boot partition aka SecureBoot

This step is purely optional but ensure that the bootloader, kernel and initramfs is not modified by some attacker between shutdowns.

Generate the keys PK KEK DB with this script in /etc/efi-keys
Copy all PUBLIC keys to the ESP cp /etc/efi-keys/*.{cer,esl,auth} /boot/efi-keys
Install sbupdate-git tools from aur with yaourt sbupdate-git
Change CMDLINE_DEFAULT in /etc/sbupdate.conf like CMDLINE_DEFAULT="cryptdevice=UUID=ab7080d3-7ec1-454d-bf6e-3cdd4eeb0cbe:cryptlvm:allow-discards root=/dev/mapper/blackssd-root resume=/dev/mapper/blackssd-swap"
Signing the kernel and the initramfs sudo sbupdate
Add the new boot entry efibootmgr --disk /dev/nvme0n1 --part 1 --create --label "Black Arch" --loader /EFI/Arch/linux-signed.efi --verbose
Registering the keys in UEFI better to do it directly within UEFI
Add an UEFI password

In my case, I had to include the Microsoft Third Party Key to my DB. Because MSI UEFI firmware checking the VBIOS of my graphic card against the DB at boot, and the VBIOS is signed with Microsoft Third Party Key. Making this secure boot pretty much pointless.

Download Microsoft Third Party Cert wget https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt
Convert to DER openssl x509 -inform DER -outform PEM -in MicCorUEFCA2011_2011-06-27.crt -out MicCorUEFCA2011_2011-06-27.crt.pem
Craft a .esl file cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt.pem MS_UEFI_db.esl
Craft the signed .auth file sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth
Copy esl and auth file to boot partition
Append the esl or the auth file to your DB with your firmware utility

10. Erase my old SATA SSD

SSD cleraing guide

hdparm -I /dev/sdX | grep frozen
hdparm --user-master u --security-set-pass PasSWorD /dev/sdX
hdparm --user-master u --security-erase PasSWorD /dev/sdX
blkdiscard /dev/sdX

aesophor/Prepare NVME SSD for moving an Archlinux installation.md