On 20/04/2026 at 04:34, Richard Allen wrote:
I sort of deserved this one - I was playing with the sparse virtual
disk support in OpenZFS, and had created an impossibly large VM,
but then Debian wouldn't install. The guided partitioner could limit
new partitions to the max the filesystem can support.
Just my thoughts:
This is a really unlikely edge case, not sure if it is worth fixing.
An explicit maximum size could be set in automatic partitioning recipes,
for example:
8000 8850 16000000 $default_filesystem # 16TB maximum size
instead of
8000 8850 -1 $default_filesystem # unlimited maximum size
But
- The default filesystem type may be preseeded with filesystem types
other than ext4, e.g. btrfs or xfs, which may have different limits (did
not check).
- The actual ext4 filesystem size limit is unclear. Some sources mention
16TiB (e2fsprogs limit), 1EiB (extent limit), 64ZiB or 1YiB depending on
block size. If the actual limit depends on the block size, then on some
architectures (arm64 and ppc64el) it may depend on the kernel page size
(4, 16 or 64KiB) which limits the maximum usable block size.
- The issue also exists with manual partitioning, this would not fix it.
A better option would be to interpret "-1" in recipes as the filesystem
type maximum size instead of "unlimited". But it would not fix the issue
with manual partitioning either.
IMO a proper solution would require 3 steps:
- define the maximum size for each filesystem type in relevant partman
udebs (may be calculated at runtime if dependent on kernel page size)
- use these values to enable or disable filesystems type in the manual
partitioning filesystem selection dialog
- use these values for "-1" in automatic partitioning recipes.
