Bug#1108285: debian-installer: Btrfs installation results in a non-bootable system with "no usable shell found"
Please reply to 1108285@bugs.debian.org, not only me. I am quoting all
you reply for completeness.
On 26/06/2025 at 04:19, andrewlorusso@icloud.com wrote:
To clarify and provide more context, here’s a full account of my installation process and the issues I encountered. Apologies if some of this information is tangential or overly detailed, but I want to be thorough.
1. Installation Background
I initially attempted to install Debian Stable, but due to my motherboard's newer Wi-Fi card, I needed the updated kernel and firmware available in Debian Trixie. While the Trixie installer detected my wireless network (ESSID), it consistently failed to connect via DHCP after I entered the Wi-Fi password.
At one point, I managed to connect by disabling the 2.4 GHz radio on my router, but the connection dropped shortly after. I believe this is a driver/firmware issue, as the MediaTek card I’m using is not fully supported (closed-source), and others have reported similar DHCP exchange failures on the same hardware.
As a workaround, I downloaded the DVD ISO and opted for an offline base system install so I could configure networking with nmcli post-installation. This method worked reliably every time I completed the installation.
2. Partitioning and Subvolumes
My goal was to set up a single Btrfs partition with two subvolumes: @ for the root filesystem and @home for user data.
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.
I followed the steps from a tutorial video closely:
Unmounted the /target and /target/boot/efi directories
Created the subvolumes manually from the installer’s BusyBox shell
Edited the fstab to reflect the correct subvolumes
This part of the process completed without issues.
3. Bootloader Installation
I intended to use systemd-boot, but the installer didn’t allow me to select it as a bootloader (I don’t recall the exact error).
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.
I then chose GRUB, mistakenly enabling the option to "Force GRUB installation to the EFI removable media path." This resulted in the system being undetected by UEFI firmware upon reboot.
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.
This seems more related to my UEFI implementation than to Debian. Even if systemd-boot had worked, it appears that only GRUB supports the fallback installation path, which may be necessary on my system.
No, systemd-boot also installs itself in the removable media path by
default.
4. Btrfs Boot Failure
This appears to be where Debian itself may be at fault. I attempted around 10 installations with different combinations of:
Base system only
XFCE and base packages
Btrfs and ext4 file systems
The only successful installations (i.e., the system booted correctly) were those using ext4 with GRUB.
Whenever I used Btrfs, even after a seemingly successful installation, the system would fail to boot and would go straight into UEFI.
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.
I suspect the base system files were not properly copied into the correct Btrfs subvolume, resulting in the "no usable shell was found on your root file system" error when I tried to chroot in Rescue Mode.
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) ?
Given that I didn’t change any bootloader or firmware settings between attempts, and the only consistent variable was the filesystem (ext4 vs Btrfs), I believe this may indicate a bug in the Debian Btrfs installation process.
Please let me know if you need logs or further details to help clarify this issue.
Best regards,
Andrew Lorusso
Similar Exchange issue
https://unix.stackexchange.com/questions/656993/debian-installer-failure-of-key-exchange-and-association-when-attempting-wifi
Partitioning video I followed
https://www.youtube.com/watch?v=MoWApyUb5w8;
Debian 12 Bookworm Minimal Install w/BTRFS
youtube.com
Reply to: