Dear Maintainer,

I got a system that installs in non-UEFI mode but fails to mount the target install partition in UEFI mode. I've been told by a Linux graphics driver specialist that is bug is worth reporting.

   * What led up to the situation?

Old PC (Intel Core i5-4690K CPU), SecureBoot off, Ventoy-based USB stick with Debian 13.2.0 netinst ISO.

   * What exactly did you do (or not do) that was effective (or ineffective)?

Ineffective: UEFI boot the USB stick, during "Partition Disks" the system says "The attempt to mount a fil system with type vfat in SCSI3 (0,0,0), partition #1 (sda) at /boot/efi failed".

Effective: non-UEFI boot the stick, choose "Graphical Install" (note: I have to remove "vga=788" otherwise the display on the Radeon RX 5550 gets garbled -- I have been told this is a bug in the GPU BIOS), the install completes fine in 80x25 GUI mode.


Kind regards,

Daan

Control: reassign -1 partman-efi

Which partitioning method did you use in both cases: manual/guided,
using entire disk/largest free space, with LVM... ?

When the error happens, can you drop to an installer shell with
Ctrl+Alt+F2 and report the output of the following commands:

anna-install fdisk-udeb
fdisk -l
blkid -s TYPE /dev/sda*
grep "format EFI" /var/log/partman

Hi,

Daan Nusman <daan.nusman@proton.me> (2025-12-04):

What happens if you take Ventoy out of the equation and just copy the
netinst iso on your USB stick instead?


Cheers,

(Re-adding the bug address to the recipients, if others than Cyril and I
are interested in this case)

Do you mean that you do not want to destroy your successful installation
or all later installations in UEFI mode succeeded ?

I identified a few use cases which may cause this failure and are
dependent on the previous partitioning layout, that is why history
matters. Do you remember which partitions the disk had before your first
failed installation attempt in EFI mode ?

I guess it was in UEFI mode ?

In UEFI or legacy mode ? Which ones failed or succeeded ?

Hello, please find replies inline below.

The installations all succeeded, in non-UEFI and UEFI modes. I do not care about destroying / re-installing at this point in time.

(Always using guided mode, and the entire disk).

* Had a Fedora install with LVM/crypt enabled.
* Installed Debian 13.2 with LVM/crypt + full random overwrite, successfully in non-UEFI mode.

(Here installing NVidia non-free drivers killed the OS login (KDE seems to crash immediately on login), switched to an old AMD GPU I had lying around. This failed right after the "Graphical Installation" option with a garbled screen. A Fedora dev told me that the "vga=788" in the boot parameters is suspect, but that it's the VESA BIOS of the AMD GPU that's to blame. Started using UEFI mode as this seemed to work with the AMD GPU, so:)

* Installed Debian 13.2 with LVM/crypt + not a full random overwrite (canceled it): the reported mount fail error occurred here. Suspected the cancel was to blame, so:
* Installed Debian 13.2 without LVM: also mount fail.
* Installed Debian 13.2 in non-UEFI mode, graphics fix, without LVM. This installed correctly.

After this I filed the bug report. But any attempts to reproduce the mount fail error did not work after that:

* Tried the UEFI mode, no LVM/crypt. This installed correctly.
* Tried the UEFI mode, LVM/crypt + full bit scramble of the drive. This installed correctly. I'm using this install now.

I hope this also answers your questions about what was done in what mode. Caveat: I cannot be entirely sure about the exact order of events.

I'm available if you want to try some stuff out, otherwise I'll just go on a use this install.

Kind regards,
Daan Nusman

But you overwrote it with Debian, so it does not matter.

This created a /boot partition as #1, with maximum size 1GB, formatted
as ext4.

This created an EFI partition as #1, with maximum size 1GB. The
installer tries hard (maybe too hard ?) to not reformat EFI partitions,
so if it detects any filesystem in it, then it won't reformat it but
will try to mount it as vfat in any case regardless of the detected
filesystem type.

If the former /boot partition and the new EFI partition had the exact
same position and size, then the installer detected the old ext4
filesystem and did not reformat the partition as FAT. Then it tried and
failed to mount it as vfat.

If the old and new EFI partitions had the same position and size, same
problem as above.

This did not create any EFI nor /boot partitions but a big root
partition as #1 formatted as ext4.

This created an EFI partition as #1, with maximum size 1GB. The former
root partition #1 had a different size, so its filesystem was not
detected and the new EFI partition was formatted as FAT and could be
successfully mounted as vfat.

This created an EFI partition as #1, with maximum size 1GB. Either the
former and new EFI partitions had the same size and the new one was not
formatted but was already FAT, or they had different sizes and the new
one was formatted as FAT. In any case, it had a FAT filesystem and could
be mounted as vfat.
If the order is correct then it would explain what happened.
Can you show the current output of "fdisk -l" ?

Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 840
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5629284A-E692-4059-9076-5D0B4D39D223

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   2000895   1998848   976M EFI System
/dev/sda2  2000896   4001791   2000896   977M Linux filesystem
/dev/sda3  4001792 976771071 972769280 463.9G Linux filesystem


Disk /dev/mapper/sda3_crypt: 463.84 GiB, 498041094144 bytes, 972736512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/spire--vg-root: 440.31 GiB, 472777752576 bytes, 923394048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/spire--vg-swap_1: 23.49 GiB, 25220349952 bytes, 49258496 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
daan@spire:~$

The EFI and /boot partitions have the maximum size 1GB, so in non-UEFI
mode with LVM the ext4 /boot partition would have the same position and
size as this EFI partition.

Adding two related unanswered bug reports to the Cc: list.
This may happen with guided partitioning using an entire disk or manual
partitioning after deleting the existing partition or creating a new
partition table. I suspect it happens because partman-partitioning does
not properly clean partman device directory during these operations.

Other use cases are in manual partitioning or guided partitioning using
free space when re-using an existing partition, either non-EFI or EFI
with a filesystem other than FAT, as EFI.

To summarize the troublesome use cases:

* manual partitioning
- re-use an existing EFI partition containing a non-FAT filesystem
- re-use an existing non-EFI partition as EFI
- delete an existing partition and create an EFI partition at the same
location
- create a new partition table and an EFI partition at the same location
as an old partition

* guided partitioning using free space
- re-use an existing EFI partition containing a non-FAT filesystem

* guided partitioning using an entire disk
- create a new partition table and an EFI partition at the same location
as an old partition

Cleaning partman device directory when creating a new partition table or
deleting a partition would not fix the partition re-use use cases.

Should we enforce that an EFI partition must have a FAT filesystem ?
It has been reported that some UEFI firmware may support other
filesystems such as exFAT or NTFS.