Dear Debian Maintainers,

I am reporting a bug encountered during the installation of Debian Trixie using the debian-trixie-DI-rc1-amd64-DVD-1.iso. The installation fails to produce a working system when using a Btrfs root filesystem, but succeeds when using ext4.

Summary of the Problem:

When performing a minimal installation ("Standard system utilities" only) and partitioning the disk with an EFI System Partition and a Btrfs root filesystem (/), the installation process appears to complete without error. However, upon reboot, the system is not bootable. Booting into the installer's Rescue Mode and attempting to chroot into the installed system fails with the error: "no usable shell was found on your root file system". This indicates the base system files were not correctly copied to the Btrfs partition during installation.

Steps to Reproduce:

1. Boot from the debian-trixie-DI-rc1-amd64-DVD-1.iso installer.
2. Proceed to the "Partition disks" step and choose "Manual".
3. Create two partitions on the target drive (e.g., /dev/nvme0n1):
   - A ~500 MB partition, set to "Use as: EFI System Partition".
   - The remaining space as a partition set to "Use as: Btrfs journaling file system" with the mount point set to /.
4. Write the changes to the disk.
(Created subvolumes in busy box)
5. When prompted, select YES to "Force GRUB installation to the EFI removable media path?".
6. Proceed with the installation. At the "Software selection" screen, deselect all options except for "Standard system utilities".
7. Complete the installation, choosing not to use any network mirrors.
8. Upon rebooting, the system fails to boot.
9. Booting back into the installer's Rescue Mode and selecting the Btrfs partition as the root filesystem leads to the "no usable shell found" error when trying to execute a shell in the installed environment.

Working Workaround:

The installation is successful if the exact same steps are followed, with one single change:
- In step 3, setting the root partition to use "Ext4 journaling file system" instead of Btrfs.

This proves that the installer image, the hardware, and the rest of the installation process are functional. The point of failure is specifically the installer's routine for setting up a Btrfs root filesystem.

Hardware Details:

- Wireless Controller: MediaTek Corp. MT7925 (Device 0717)
- System Firmware: UEFI, which required the "Force GRUB to fallback path" option to boot successfully even on the working ext4 installation.

This bug is particularly critical as the installer gives no indication of failure, leaving the user with a system that appears to have installed correctly but is fundamentally broken.

Thank you for your work on Debian. I hope this report helps improve the installer for the final Trixie release.

In some rare conditions they may be copied to the wrong subvolume.

Please elaborate.

Please elaborate.

Please reply to 1108285@bugs.debian.org, not only me. I am quoting all
you reply for completeness.

This may explain why rescue-mode did not find a usable shell. Trixie RC1
installation images include rescue-mode 1.102 but the capability to
mount the @ subvolume was added to version 1.103 (included in recent
weekly images). Besides, if you left the @rootfs subvolume created by
the installer, rescue-mode would mount it first and ignore other subvolumes.

Current DVD-1 installation images do not include systemd-boot packages,
so a network mirror is required to install it. I believe they should,
but there does not seem to be strong motivation to change this.

This option cannot be responsible for this. All it does it install an
extra copy of the boot loader in the removable media path, increasing
the chances to boot the system on flawed UEFI firmwares.

No, systemd-boot also installs itself in the removable media path by
default.

Please elaborate. What happens _exactly_ ?
Does GRUB show up (menu or command prompt) ? GRUB is on the EFI
partition, so it should show up regardless of the root filesystem.

Suspecting is not enough. Did you check in all subvolumes, from
rescue-mode installer shell or any live system ?
Did you try with the default btrfs partitioning (@rootfs subvolume) ?