Hello, my laptop runs with a default partition layout created by Debian Installer 4 years or so ago:
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 1550335 499712 244M Linux filesystem
/dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem
The boot partition is now big enough to contain 2 kernel version, too
small to contain 3, and too small to purge one and install another
(somehow a bit more space is needed during install than is used at the
end)
Boot happens via UEFI and grub, the root partition is a filesystem in a
LV in an encrypted PV.
d-i now has better defaults for partitioning, so this isn't a problem in
newly installed systems, but it seems like a nontrivial issue in
upgrades, which deserves a section in release notes. I'm not sure what
could be good, default, official suggestions for this situation, thoguh.
There's been some brainstorming on #debian-devel, I'll try to summarise
what I've seen so far. I'm not sure any of this can be turned into a
one-size-fits-all upgrade path, but a collection of tips and
workarounds is at least a starting point.
# Temporary mitigations
## /etc/initramfs-tools/initramfs.conf
# makes somewhat smaller initrd files and buys some time
COMPRESS=zstd
# makes definitely smaller initrd files, but breaks boot if
# dependencies are not computed correctly: risky! And it needs
# regenerating the initrd if running on different hardware
MODULES=dep
## using dracut
Someone reported that dracut creates smaller initrd images
## Using /boot/efi to grow /boot
My /boot/efi is 512M and mostly empty, and is contiguous with /boot. One
can shrink /boot/efi and use the space to enlarge /boot
## /boot inside the PV
grub can understand LVM, so one can move /boot inside the PV, if the PV
is not encrypted.
## Encrypted /boot
grub can also understand LUKS, so one can move /boot inside the
encrypted PV.
grub cannot however forward the LUKS key to Linux during boot, so one
would have to enter the password twice.
One can store LUKS keys inside the initrd (see
/etc/cryptsetup-initramfs/conf-hook), which is then stored in the
encrypted PV.
This allows to boot entering the password only once, but then anyone who
can read the initrd file on the filesystem after boot can recover the
key, so one needs to at least manage the permissions of the initd file,
which is world-readable by default.
This will also give another path for extracting the LUKS keys, although
I don't know how hard it is to extract the keys from a running system as
it is now, so I don't know how worse this would get.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: PGP signature
