Please reply to 1108...@bugs.debian.org, not only me. I am quoting all
you reply for completeness.
On 26/06/2025 at 04:19, andrewloru...@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
