Can't chroot into "mnt" to reinstall Grub

[mattikins]

I am having an incredibly difficult time trying to fix GRUB. I am running Debian 12 on a Lenovo Yoga 720-15IKB. My partitioning scheme has 3 partitions:
nvme0n1p1;
nvme0n1p2; and,
nvme0n1p3.

nvme0n1p1:
File Format=fat32;
Flagged as “boot”;
Size=512MiB using 7.78MiB;

nvme0n1p2:
File Format=ext2;
No flags;
Size=488MiB using 450.22
Contents:

nvme0n1p3 is encrypted using LUKs and is subdivided into 3 LVMs:
yogadebian—vg-root
yogadebian—vg-swap_1
yogadebian—vg-home

This is basically the LUKS/LVM install option when I installed Debian.I have tried as many of the fixes as I could find, including the Debian GrubEFIReinstall (https://wiki.debian.org/GrubEFIReinstall).

I am able to unencrypt yogadebian-vg and then mount the 3 volumes at “/mnt”, though this is where things break down. I have to “mkdir” for many (not all) of the “/mnt” in order to prepare the “chroot /mnt” command.

The problem seems to be with the efi/efivars. They appear to be missing? I did try Boot Repair but it didn’t fix it.The last Boot Repair analysis I did is at: https://paste.debian.net/hidden/2cf0a60a/

I have never been able to “chroot” so that I can just reinstall Grub. I really do not want to do a clean install of Debian and Grub before I exhaust just reinstalling Grub. I don’t want to go through the ordeal of getting my Root back up to speed. I know I can do that without changing my Home directory.

If anyone has any suggestions on what may be preventing me from being able to chroot I would very much appreciate it. Here are the results of some of the inventory commands:

Code: Select all

root@debian:~# fdisk -l
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: ADATA SX8200PNP                          
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: CC0A91A2-A1A8-40D2-84F4-F06EB5E599B3

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1    2048    1050623    1048576   512M EFI System
/dev/nvme0n1p2 1050624    2050047     999424   488M Linux filesystem
/dev/nvme0n1p3 2050048 2000408575 1998358528 952.9G Linux filesystem


Disk /dev/sda: 3.73 GiB, 4009754624 bytes, 7831552 sectors
Disk model: Storage Media    
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: dos
Disk identifier: 0xc7e6ef99

Device     Boot Start     End Sectors  Size Id Type
/dev/sda1  *       64 6835135 6835072  3.3G  0 Empty
/dev/sda2        7004   17243   10240    5M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 2.76 GiB, 2963050496 bytes, 5787208 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/luks-e733e1f4-f384-4d84-88ab-304a3fe434ae: 952.88 GiB, 1023142789120 bytes, 1998325760 sector
s
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/yogadebian--vg-root: 101.54 GiB, 109026738176 bytes, 212942848 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/yogadebian--vg-swap_1: 20.76 GiB, 22292725760 bytes, 43540480 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/yogadebian--vg-home: 830.08 GiB, 891289600000 bytes, 1740800000 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

[panpan]

Check this: https://www.declarativesystems.com/2023 ... +luks.html

[mattikins]

Thanks, I'm going to give it a go right now!

[mattikins]

Well I got right up to the point where I "chroot" into ${ROOTFS} /bin/bash and get hit with the "no such file or directory. And unlike the previous error messages, I was not able to mkdir the directory to chroot into. Here is my inuputs. I am so aggravated.

Code: Select all

thuser@debian:~$ sudo -s
root@debian:/home/user# modprobe efivarfs
root@debian:/home/user# cryptsetup luksOpen /dev/sda5 rootfs
Device /dev/sda5 does not exist or access denied.
root@debian:/home/user# cryptsetup luksOpen /dev/nvme0n1p3 rootfs
Enter passphrase for /dev/nvme0n1p3: 
root@debian:/home/user# export ROOTFS=/target
root@debian:/home/user# mkdir $ROOTFS
root@debian:/home/user# mount /dev/vg/root $ROOTFS
mount: /target: special device /dev/vg/root does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# vgscan
  Found volume group "yogadebian-vg" using metadata type lvm2
root@debian:/home/user# vgchange -a y main
  Volume group "main" not found
  Cannot process volume group main
root@debian:/home/user# lvscan
  ACTIVE            '/dev/yogadebian-vg/root' [<101.54 GiB] inherit
  ACTIVE            '/dev/yogadebian-vg/swap_1' [20.76 GiB] inherit
  ACTIVE            '/dev/yogadebian-vg/home' [<830.08 GiB] inherit
root@debian:/home/user# mount /dev/yogadebian-vg/root $ROOTFS
root@debian:/home/user# mount /dev/nvme0n1p2 ${ROOTFS}/boot/efi
mount: /target/boot/efi: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mount /dev/nvme0n1p2 ${ROOTFS}/boot
mount: /target/boot: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mount /dev/nvme0n1p2 ${ROOTFS}/boot
mount: /target/boot: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mkdir $ROOTFS/boot
root@debian:/home/user# mount /dev/nvme0n1p2 ${ROOTFS}/boot
root@debian:/home/user# mkdir $ROOTFS/boot/efi
mkdir: cannot create directory ‘/target/boot/efi’: File exists
root@debian:/home/user# mount /dev/nvme0n1p1 ${ROOTFS}/boot/efi
root@debian:/home/user# mount --bind /dev ${ROOTFS}/dev~
mount: /target/dev~: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mount --bind /dev ${ROOTFS}/dev
mount: /target/dev: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mount --bind /dev ${ROOTFS}/dev
mount: /target/dev: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mkdir $ROOTFS/dev
root@debian:/home/user# mount --bind /dev ${ROOTFS}/dev
root@debian:/home/user# mount -t devpts /dev/pts ${ROOTFS}/dev/pts
root@debian:/home/user# mount -t proc proc ${ROOTFS}/proc
mount: /target/proc: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mkdir $ROOTFS/proc
root@debian:/home/user# mount -t proc proc ${ROOTFS}/proc
root@debian:/home/user# mount -t sysfs sysfs ${ROOTFS}/sys
mount: /target/sys: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mkdir $ROOTFS/sys
root@debian:/home/user# mount -t sysfs sysfs ${ROOTFS}/sys
root@debian:/home/user# mount -t tmpfs tmpfs ${ROOTFS}/tmp
mount: /target/tmp: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@debian:/home/user# mkdir $ROOTFS/tmp
root@debian:/home/user# mount -t tmpfs tmpfs ${ROOTFS}/tmp
root@debian:/home/user# mount --bind /sys/firmware/efi/efivars ${ROOTFS}/sys/firmware/efi/efivars
root@debian:/home/user# chroot ${ROOTFS} /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory
root@debian:/home/user# chroot ${ROOTFS}
chroot: failed to run command ‘/bin/bash’: No such file or directory
root@debian:/home/user# chroot ${ROOTFS} /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory
root@debian:/home/user# lsblk
NAME                        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                         7:0    0   2.8G  1 loop  /usr/lib/live/mount/rootfs/filesystem.squashfs
                                                       /run/live/rootfs/filesystem.squashfs
sda                           8:0    1   3.7G  0 disk  
├─sda1                        8:1    1   3.3G  0 part  /usr/lib/live/mount/medium
│                                                      /run/live/medium
└─sda2                        8:2    1     5M  0 part  
nvme0n1                     259:0    0 953.9G  0 disk  
├─nvme0n1p1                 259:1    0   512M  0 part  /target/boot/efi
├─nvme0n1p2                 259:2    0   488M  0 part  /target/boot
└─nvme0n1p3                 259:3    0 952.9G  0 part  
  └─rootfs                  253:0    0 952.9G  0 crypt 
    ├─yogadebian--vg-root   253:1    0 101.5G  0 lvm   /target
    ├─yogadebian--vg-swap_1 253:2    0  20.8G  0 lvm   
    └─yogadebian--vg-home   253:3    0 830.1G  0 lvm   
root@debian:/home/user# blkid
/dev/nvme0n1p1: LABEL_FATBOOT="NVME0N1P1FA" LABEL="NVME0N1P1FA" UUID="AA28-18AB" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="9b86a387-64ca-47d9-948b-7b80b960a0e8"
/dev/nvme0n1p2: LABEL="nvme0n1p2ext2" UUID="fccac291-1fbf-4355-9ca7-09e3b0d69474" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="2297bf02-7e2e-4ae3-8a7e-f30310e9d0bd"
/dev/nvme0n1p3: UUID="e733e1f4-f384-4d84-88ab-304a3fe434ae" TYPE="crypto_LUKS" PARTUUID="ed0ef0a6-1164-4239-b9ff-a9193b536321"
/dev/sda1: BLOCK_SIZE="2048" UUID="2024-02-10-11-07-25-00" LABEL="d-live 12.5.0 kd amd64" TYPE="iso9660" PARTUUID="c7e6ef99-01"
/dev/loop0: TYPE="squashfs"
/dev/mapper/yogadebian--vg-root: LABEL="Root" UUID="6ec0f189-f8b5-4440-9a3a-eecc84cba5ad" UUID_SUB="c3f9ef7a-d916-4dc8-b63b-1be057f3de9d" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/mapper/yogadebian--vg-swap_1: LABEL="Swap" UUID="f47562af-df7b-4473-8f7f-a3a25693fce1" TYPE="swap"
/dev/mapper/rootfs: UUID="U64lg9-S4R6-yE14-MZCG-qlDH-FPoQ-IrwzpW" TYPE="LVM2_member"
/dev/sda2: SEC_TYPE="msdos" UUID="65C7-58ED" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c7e6ef99-02"
/dev/mapper/yogadebian--vg-home: LABEL="Home" UUID="12a4c896-8160-41e7-be5f-66828f029fac" UUID_SUB="d0b6ec97-ec42-4f54-8ca7-caaf5da21f13" BLOCK_SIZE="4096" TYPE="btrfs"
root@debian:/home/user# mkdir ${ROOTFS} /bin/bash
mkdir: cannot create directory ‘/target’: File exists
mkdir: cannot create directory ‘/bin/bash’: File exists
root@debian:/home/user# chroot ${ROOTFS} /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory
root@debian:/home/user# ^C
root@debian:/home/user#

[pbear]

There's no need for chroot to reinstall Grub (unlike updating Grub, which does). Testing in a VM, something like this should work:
[I don't use FDE, so this is based on comparing Debian-with-FDE installed in BIOS mode and regular Debian installed in UEFI mode.]

Code: Select all

apt install grub-efi-amd64-signed # will bring in several packages, including shim-signed
mount /dev/yogadebian-vg/root /mnt
mount /dev/nvme0n1p2 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi
grub-install /dev/nvme0n1 --boot-directory=/mnt/boot --uefi-secure-boot

This assumes you're in a live session and have set up an internet connection, switched to the root user, and already opened the LUKS container.
Edit: Out of curiosity, I created a VM of Debian-with-FDE in UEFI mode (using the standard installer), then reinstalled Grub using commands in this form.

FYI, if you need chroot, this is an easier way to do it. Start with the three mounts as above, then:

Code: Select all

for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt$i; done
cp /etc/resolv.conf /mnt/etc && modprobe efivars # if need internet access in chroot
chroot /mnt
[run commands]
exit
umount -R /mnt

Edit2: Turns out modprobe efivars isn't needed for Debian 12. Worse, provokes a warning. See discussion below.

By the way, please edit your earlier posts to add code tags (as I've used here). Long quotes of raw terminal output make the thread difficult to read.

[panpan]

Check also this, but before trying to read first the comments! https://gist.github.com/samuelcolvin/43 ... d0c9bfb068

[mattikins]

Thank you guys. I apologize for not using code tags, I was conscious of that when I was trying to figure out how to use them, but was tired and at my wits end. I will review @panpan 's recommended articles and give @pbear 's appraoch a shot. The way I figure it is that I have just enough knowledge of what I am doing to be dangerous, but not so dangerous that I can brick my SSD and not be able to ever recover the contents of my Home directory (which I do have backups of, I'm not that reckless!). Thank you all for your help, and more importantly, your time helping.

[mattikins]

@pbear, what does "FDE" mean? I'm going to feel dumb when you tell me...

[pbear]

FDE = Full Disk Encryption. In common usage, it means the system is encrypted, as distinguished from merely data files. The term is used even when, as here, the boot and EFI partitions are not encrypted.

[mattikins]

@pbear I was so close I couold smell victory...but alas, the Gods of Grub conspired against me:

Code: Select all

root@debian:~# mount /dev/yogadebian-vg/root /mnt
root@debian:~# mount /dev/nvme0n1p2 /mnt/boot
root@debian:~# mount /dev/nvme0n1p1 /mnt/boot/efi
root@debian:~# grub-install /dev/nvme0n1 --boot-directory=/mnt/boot --uefi-secure-boot
Installing for x86_64-efi platform.
grub-install: error: cannot copy `/usr/lib/grub/x86_64-efi/relocator.mod' to `/mnt/boot/grub/x86_64-efi/relocator.mod': No space left on device.

While I am on a live session, can I just increase the size of nvme0n1? What would I likely need, 500MB?

[pbear]

AFAIK, there's no way to shrink an encrypted partition (p3 in this case), so no way to increase the size of the boot partition (which is p2, by the way, not n1). I've a feeling the warning is mis-labeled, though. Checking my LVM test box, that file is only 26 KB. The /boot partition would have to be literally full to prevent copying it in. OTOH, you have a lot of kernel images. Any reason? If not, apt autoremove (in chroot) might solve the problem at a stroke.

Also, what's the background? Presumably the system used to boot correctly. What happened?

[mattikins]

Well I just tried to use @pbear's "chroot strategy":

Code: Select all

root@debian:~# cryptsetup luksOpen /dev/nvme0n1p3 home_nvme0n1p3
Enter passphrase for /dev/nvme0n1p3:  
root@debian:~# vgchange -ay
 3 logical volume(s) in volume group "yogadebian-vg" now active
root@debian:~# lvscan
 ACTIVE            '/dev/yogadebian-vg/root' [<101.54 GiB] inherit
 ACTIVE            '/dev/yogadebian-vg/swap_1' [20.76 GiB] inherit
 ACTIVE            '/dev/yogadebian-vg/home' [<830.08 GiB] inherit
root@debian:~# mount /dev/yogadebian-vg/root /mnt
root@debian:~# mount /dev/nvme0n1p2 /mnt/boot
root@debian:~# mount /dev/nvme0n1p1 /mnt/boot/efi
root@debian:~# for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt$i;
done
root@debian:~# cp /etc/resolv.conf /mnt/etc && modprobe efivars # if need
internet access in chroot
modprobe: FATAL: Module efivars not found in directory /lib/modules/6.1.0
-18-amd64
root@debian:~# chroot /mnt
chroot: failed to run command ‘/bin/bash’: No such file or directory

Now I am geting close to wits end. Should I give up on repairng Grub and do a clean install of Debian ?

[mattikins]

@pbear, the background when I thought back on what I could have done, I couldn't figure it out until I put a different SSD in and did a clean install and that didn't boot. I realized the reason is that I changed the boot settings in the BIOS. So my Yoga BIOS has Legacy and UIEF options. I believe tthat I had gone in and screwed around with that and didn't deactivate secure boot or something. But when I did it, I forgot and didn't make that connection until I failed to load the clean install. The reason I didn't run into it was because Lenovo puts a neat pin hole button to just immediately boot into the boot menu and I accessed live install and Bios that way the BIOS through that because it is so much faster...it pre-empts Grub so I was able to do the clean install on the other SSD. When I went back and reset everything for Legacy boot, I didn't have any problem loading the clean install. But I had already screwed around trying to fix the issu in the original SSD version I am trying to fix now.

[pbear]

Puzzled about the efivars problem, but no need to resolve for now, as apt autoremove doesn't use internet access. So, set up chroot again leaving out that line. Seemed to work just now in my VM (though nothing to remove).

Edit: Testing, it turns out the modprobe efivars command isn't needed in Debian 12. Which is to say, cp /etc/resolv.conf /mnt/etc was enough in a test I just ran to enable chroot to install an app to the test VM.
Sorry for the confusion. Frankly, I've been using those chroot commands for so long it didn't occur to me to confirm them before posting here. Will be editing my earlier post to correct the error.

As for clean install, up to you when to cut your losses and start over. If you reinstall, I encourage you to consider whether system encryption is worth the aggravation. It's easier and more reliable to encrypt just data files, preferably only those which actually need protection. I use a LUKS-encrypted partition on USB hard drive, which is mounted only when being used. Bear in mind, encryption doesn't protect anything when the files are mounted.

An in-between strategy would be to encrypt a home or data partition, like the home volume you have now, but not the system. I prefer a data partition (it's what I use on my main drive, albeit not encrypted), but either way works.

[mattikins]

Encryption on this one is necessary. I am a lawyer and my entire practice resides on that laptop. I am going to make some more stabs at this Grub fix before doing the reinstall. The second install is helping me get by. And I have been able to use Wayland with Plasma. The install on the old SSD I couldn't use Wayland because my keyboard would not work with Wayland.

[pbear]

... went back and reset everything for Legacy boot

Reviewing everything to see where we're going sideways, I notice this. The drive we're working on is set up for UEFI boot, of course. You should be booting the live session in the same mode. If booting in BIOS mode, that would explain why (from the first post) "efi/efivars ... appear to be missing." You can confirm boot mode with ls /sys/firmware; lists the directory's sub-folders; if booted in UEFI mode, one of them will be efi.

Edit: Reviewing the Boot Repair report (link in first post), I notice another odd thing. Although the EFI partition (p1) has all the Debian boot loaders we would expect, there's no corresponding entry in NVRAM (what the report calls "BIOS/UEFI firmware," i.e., the section with BootCurrent, BootOrder, Boot0000, etc.). My hunch is that the firmware deleted the Debian entry when you removed the drive, yet didn't restore it when you reinstalled the drive. The firmware might have a mechanism for adding the entry manually. If not, it can be done with efibootmgr. Whether worth a try depends on how much you dread reinstall.

Of which speaking, if you end up reinstalling, the most useful thing you can do is take detailed notes of everything you do, either a plain text file or regular word processing document. Include every setting you modify, every app you install, every command you run. Good notes make the next reinstall easier. And periodic reinstall is pretty much a fact of life in Linux, at least for stable releases like Debian.

[mattikins]

@pbear, so this is the return on "ls /sys/firmware":

Code: Select all

user@debian:~$ sudo -i
root@debian:~# ls /sys/firmware
acpi  dmi  efi  memmap
root@debian:~#

Is UEFI booting because there is the "efi"? The reason I didn't think this was an issue, was that the BIOS provide for "UEFI priority" or "Legacy BIOS." I thought that even though I chose Legacy that it would boot what I thought was the UEFI if there wasn't a Legacy boot present. Since I thought I had done a UEFI install, I thought it would default to UEFI if there wasn't Legacy present. And the reason I had to use Legacy was to defeat secure boot since it isn't a Windows install. Like I said, just enough knowledge to be dangerous...
What is it you do for a profession? Are you a programmer? I wanted to start a YouTube channel called "Linux 4 Lawyers" because I am so enthralled with everything Linux and believe that Windows is simply corrupt due to their stranglehold. When Windows 10 came out and read about the telemetry and read the terms of service, I was appalled at their audacity. At least Google gives you its services for free while it pilfers your personal information. Now Windows charges you a couple hundred bucks (for a mediocre product,) and has access to your entire OS and information, not just what you reveal online. I was dabbling with Linux three or maybe it was four years ago when I got a virus that nearly wiped out my data. I used Kali to recover almost everything and was shocked how easy it was. Who needs a profile password if your computer isn't encrypted? I immediately dropped Windows and got started with Mint. Anywho...

it can be done with efibootmgr. Whether worth a try depends on how much you dread reinstall.

I'm having fun, and dread doig a clean install. I had things just right...you know?

[mattikins]

Ok, here is the result of my attempt at your last revisions to deploy "apt autoremove." First is my revisions ot the original script based on your suggestions so you can easily see where I changed things. Then I will post the results. I still got the no bin/bash error.
Redlined script:

Code: Select all

root@debian:~# cryptsetup luksOpen /dev/nvme0n1p3 home_nvme0n1p3
Enter passphrase for /dev/nvme0n1p3:

root@debian:~# vgchange -ay
3 logical volume(s) in volume group "yogadebian-vg" now active

root@debian:~# lvscan
ACTIVE
 '/dev/yogadebian-vg/root' [<101.54 GiB] inherit
ACTIVE
 '/dev/yogadebian-vg/swap_1' [20.76 GiB] inherit
ACTIVE
 '/dev/yogadebian-vg/home' [<830.08 GiB] inherit

root@debian:~# mount /dev/yogadebian-vg/root /mnt

root@debian:~# mount /dev/nvme0n1p2 /mnt/boot

root@debian:~# mount /dev/nvme0n1p1 /mnt/boot/efi

root@debian:~# for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt$i; done

[s]root@debian:~# cp /etc/resolv.conf /mnt/etc && modprobe efivars # if need internet access in chroot
modprobe: FATAL: Module efivars not found in directory /lib/modules/6.1.0-18-amd64[/s]

for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt$i; done

[s]cp /etc/resolv.conf /mnt/etc && modprobe efivars # if need internet access in chroot[/s]

chroot /mnt

apt autoremove

exit

umount -R /mnt

Here is the implementation after I mounted the unencrypted "yogadebian-vg" volumes. I screwed up the first command and had to open a new terminal to put the first commend in properly:

Code: Select all

root@debian:~# for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt$i; done
root@debian:~# chroot /mnt
chroot: failed to run command ‘/bin/bash’: No such file or directory

[pbear]

That's goofy. Bash = Terminal = the thing you're using to generate the error message. What say apt list bash and ls -l /bin/bash? Bear in mind, we're probing the live session. By the way, which live session is this?

Actually, before we invest any more effort in chroot, let's try an Annie Oakley. Shooting over the shoulder while looking at the target in a mirror, run this in the live session:

Code: Select all

sudo efibootmgr --create --label "debian" --loader "\EFI\DEBIAN\SHIMX64.EFI" -d /dev/nvme0n1 -p 1

No need to decrypt anything, no need to switch to the root user, no need for an internet connection. This adds a boot entry directly to NVRAM. Shut down live session and try to boot the installed system. Use the firmware boot menu; the command should work, but the boot entry isn't yet first on the list. We'll burn that bridge next. Of which speaking, whether boot succeeds or not, please report the output of efibootmgr -v.

For what it's worth, what got me into Linux isn't what I do for a living. It's a love of puzzles, especially math and logic puzzles. The treasure hunt aspect of researching problems also appeals.

[pbear]

If the Annie Oakley doesn't work, there's a workaround you might consider. I notice from the Boot Repair report that you're familiar with rEFInd. What you may not know is that it also works from USB drive, bypassing Grub and NVRAM. Select flash drive; can be very small (rEFInd only needs 100 MB) or share with another use (e.g., Timeshift snapshots). Alternatively, if you use Ventoy, rEFInd offers an .img file, which will boot without installing anything.

With GParted (or other partitioning tool), create an EFI partition (100 MB, format = FAT32, label = REFIND); after creating, right-click partition, select Mange Flags and tick boot (also will automatically select esp). Download rEFInd zip file; extract (unzip); open new folder; right-click, Open in Terminal. Run ./refind-install --usedefault /dev/sdxn --alldrivers (notice dot), where sdxn = the EFI partition (e.g., sdb1).

Boot from rEFInd drive, same as you do a live session (secure boot must be disabled). Will scan for bootable objects. Should find both the Debian boot loader and the kernel; notably, rEFInd can boot from the kernel even if the boot loader is broken. Use arrow key to select which object to boot. Once the system is running, the rEFInd drive can be removed (freeing up the port). To access older kernels (like advanced options in Grub), tap F2, Insert or Tab.

Wouldn't call this a great long term solution, but should at least get you up-and-running. If you end up using long term, you might want to look at how to configure the app (timeout, etc.).