On 13/06/2025 at 07:58, Paul Gevers wrote:
No btrfs here. Things are on ext4. Should we mention ext4 is fine as
it's the default in Debian IIRC. (Is it always?)
Good question. Yes, ext4 is still the default filesystem in Debian
installer partitioning.
Quoted from mke2fs(8) man page:
Valid block-size values are powers of two from 1024 up to 65536
(however note that the kernel is able to mount only file systems
with block-size smaller or equal to the system page size - 4k on
x86 systems, up to 64k on ppc64 or aarch64 depending on kernel
configuration).
/etc/mke2fs.conf from e2fsprogs sets the default block size to 4096, so
ext* filesystems created with the default block size are safe with 4k
page size. However it sets blocksize = -1 for filesystems created with
"largefile" or "largefile4" usage (-T). These usages can be selected in
the installer. Back to mke2fs(8) man page:
If omitted, block-size is heuristically determined by the file
system size and the expected usage of the file system (see the -T
option). In most common cases, the default block size is 4k. If
block-size is preceded by a negative sign ('-'), then mke2fs will
use heuristics to determine the appropriate block size, with the
constraint that the block size will be at least block-size bytes.
I have no details nor experience about mke2fs heuristics, but from the
above a block size above 4k might be chosen under specific conditions
when the page size is 64k. Maybe someone can shed some light here and
advise if the same check as btrfs should be suggested.
After, you can check all filesystem mounts and swap activations
defined in /etc/fstab, native systemd units or any othe means.
Both / and swap are working. Should we advice this for people that
stumble over these notes after they upgraded and want to be sure?
As written previously, swap page size mismatch should not be an issue
with systemd, but maybe warn users of other init systems ?
Unsupported filesystems will cause mount failure and usually result in
the boot process falling back to emergency shell, so the user will know
soon enough (but already too late?) after reboot that something went wrong.
