(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: DVD ISO
Image version: debian-13.4.0-amd64-netinst.iso
Date: <Date and time of the install>

Machine: KVM on Debian 13
Partitions: 10EiB sparse virtual disk

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:           [O]
Detect network card:    [O]
Configure network:      [O]
Detect media:           [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:    [O]
Detect hard drives:     [O]
Partition hard drives:  [E]
Install base system:    [ ]
Install tasks:          [ ]
Install boot loader:    [ ]
Overall install:        [ ]

Comments/Problems:

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.

I choose "Guided - use entire disk", "All files in one partition", "Finish and Write"

Result: Failed to create a filesystem.
The ext4 file system creation in partition #2 of Virtual disk 1 (vda) failed.

partman log:
mke2fs 1.47.2 (1-Jan-2025)
mkfs.ext4: Size of device (0x9fffffff80000 blocks)
/dev/vda2 too big to create a filesystem using a blocksize of 4096

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.