Not long ago I felt nostalgic inside FreeBSD again, everything is wonderful, everything is familiar, everything is convenient. There is just one point that completely rules it out from desktop use, at least for me. On almost all my laptops, FreeBSD does not support either sleep or standby modes (s2disk/s2ram). And I couldn’t do anything with the hardware/drivers/ACPI, but I tried a lot.
Without standby mode, it is completely impossible to use a laptop, since after transportation, you need to load everything again, turn it on, and restore a complex work session. And I only reboot workstations after applying updates that require it.
One of the many nice little things that Beastie has that Debian lacks is ZFS Boot Environments, this is somewhat more convenient than, say, LVM snapshots. And the second is GEOM_ELI, which supports not only, like LUKS, the OR password OR key mode, but also supports password WITH key mode.
I thought and thought, and decided to deploy Debian from scratch, taking into account all the tools I use, my experience, and, importantly, my habits.
Debian is still my main system, so the only way to get a hardware (physical) encryption key in addition to the password is to make it from the header and place it on a bootable USB flash drive.
Habits
And makes us rather bear those ills we have. Than fly to others that we know not of.
mdadm raid1
This is the base layer of all my disk systems and it is a habit that is difficult to break. Even if the workstation only has one disk, it will be based on a degraded RAID1. Although there are always at least two disks in systems. This allows you to create a bootable and functional copy of your system and data in just a few minutes.
The disk can be connected via any bus; I have cloned a mirror via eSATA, USB2/3, EXPRESSCARD 54, Thunderbolt, and even on a mounted /dev/loop file.
A system deployed on good equipment and customized to your needs that you can trust is as valuable as your data. Because writing a small project can take 2-3 months of work, and setting up the system during the process can take up to half a year.
Let me point out right away that no dd, rsync, cpio, or other programs can correctly create a backup from a running system as conveniently as RAID.
LUKS
This is the second level, immediately above the Raid mirror. Its purpose does not need to be explained.
LVM
Sometimes you need “Hibernate mode” (s2disk), so you need SWAP, and since you want to have one password, then LVM is necessary.
Yes, mdadm, LVM and LUKS can be replaced with ZFS alone, but those are habits. For a good fifteen years there hasn’t been a single problem with them. There were power failures/laptop resets, multiple Debian release updates, HDD crashes, but the system always booted.
# usb
sda 8:16 1 14.9G 0 disk
├─sda1 8:17 1 1000K 0 part
├─sda2 8:18 1 512M 0 part /boot/efi
└─sda3 8:19 1 4G 0 part /boot
# nvme
nvme0n1 259:0 0 3.6T 0 disk
└─nvme0n1p1 259:1 0 904G 0 part
└─md1 9:1 0 903.9G 0 raid1
└─md1_crypt 253:0 0 903.9G 0 crypt
├─lvm_system-swap 253:1 0 96G 0 lvm
└─lvm_system-zfs 253:2 0 807.9G 0 lvm zroot
Deployment
The Debian installer does not provide the ability to perform a custom installation that meets all requirements. Therefore, it was decided to install using the good old debootstrap under the LiveCD system. In my case it is debian-live-13.3.0-amd64-kde.iso. The LiveCD image was downloaded, all hashes and GPG signatures were verified.
# trixie
deb https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware
mkdir /mnt/etc/zfs
cp /etc/zfs/zpool.cache /mnt/etc/zfs/
# I didn't have this file# cp: cannot stat '/etc/zfs/zpool.cache': No such file or directoryhostname deb
hostname> /mnt/etc/hostname
printf'127.0.1.1 deb'>> /mnt/etc/hosts
ip addr show nano /mnt/etc/network/interfaces.d/eth0
# trixie
deb http://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware
mkdir /mnt/etc/.crypto_data
cp /tmp/keys/md1_header /mnt/etc/.crypto_data/md1_header
chmod 700 /mnt/etc/.crypto_data
chmod 400 /mnt/etc/.crypto_data/md1_header
# Make a second temporary copy of md1_header in /boot on USB# If you can't boot the first time,# then you don't need to extract this file from the initrd image# to mount md1_crypt manually.cp /tmp/keys/md1_header /mnt/boot/md1_header
# trixie
deb https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware
search.fs_uuid b5bd933b-51e9-4693-bf3b-d13307bbd885 root hd1,gpt3
set prefix=($root)'/grub'
configfile $prefix/grub.cfg
fs_uuid corresponds /dev/sdb3.
If the new system boots successfully
You can remove md1_header from /boot, because it is already contained inside all /boot/initrd.img*. rm -f /boot/md1_header
And make some copies of your bootable flash drive. Decide for yourself whether to use dd or copy files, remember about grub-install. Without this flash drive, or more precisely without md1_header, your data will become a brick.
