On a Lenovo ThinkPad T15 g Gen 2 I have installed Kali back in early 2022. Several days ago it ran into an ACPI bug during normal boot-up. Trying to resolve the issue, I've reset the BIOS settings and by having done this I totally messed up the system. Since then it can't boot anymore and I try to grub-install again, but to no avail. Have tried Boot Repair and the standard recipe (more on that below) from a live-stick. (BTW, I've seen that the kernel files are still on the original system, just to mention this.)
Status as of now after several days of intensive work:
1. I managed to update the computer BIOS, big success but changed nothing.
2. Now there are two dead-end roads:
a) boot with Secure Boot ON
b) boot with Secure Boot OFF
a) leads into a BIOS screen asking for a boot device. Needless to say, whatever I choose, I can't get any further, i.e. it does not boot.
b) leads into the grub boot menu offering a Kali boot and and Advanced Options item. The latter presents me with the exact boot menu as before the crash: (1) Linux kernel 6.5, (2) Linux kernel 6.5 recovery mode, (3) Linux kernel 6.4, and (4) Linux kernel 6.4 recovery mode. Interesting fact: the background picture shows a frame with rounded corners. Normally you see your boot options therein. This frame is left empty, all the options, if any, can be seen in the outer rectangularly framed part of the screen.
Let's put a) aside and concentrate on case b):
All options lead into Emergency Mode! And to make things even worse: root account locked. At this point I have to start allover.
In Boot Repair I have tried all options but the one to wipe out the kernels and install the latest one again. I was too suspicious that I could destroy the system beyond repair. No success so far using this system.
The recipe I mentioned above looks like this:
Code:
mount /dev/sda5 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
mkdir /mnt/boot/efi
mount /dev/sda4 /mnt/boot/efi
mount -o remount,rw /dev/sda4 /mnt/boot/efi
mkdir /mnt/hostrun
mount --bind /run /mnt/hostrun
chroot /mnt
mkdir /run/lvm
mount --bind /hostrun/lvm /run/lvm
grub-install /dev/sda
update-grub
exit
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt/sys/firmware/efi/efivars
umount /mnt/boot/efi
umount /mnt/hostrun
umount /mnt/run/lvm
umount /mnt
REBOOT
I have tried variations of it, e.g. w/ and w/o the firmware line, and other things. Didn't work out.
Okay, more information you'll need:
fdisk -l tells us:
Code:
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB
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/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: Micron MTFDKBA1T0TFH
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: 895E97B4-BD08-4EB2-8A89-252F3341CDA1
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 1998407679 1997357056 952.4G Linux filesystem
/dev/nvme0n1p3 1998407680 2000408575 2000896 977M Linux swap
Disk /dev/sda: 7.5 GiB, 8053063680 bytes, 15728640 sectors
Disk model: ProductCode
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: 0xcf09d938
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 64 9062927 9062864 4.3G 17 Hidden HPFS/NTFS
/dev/sda2 9062928 9064783 1856 928K 1 FAT12
/dev/sda3 9066496 15728639 6662144 3.2G 83 Linux
Disk /dev/loop0: 3.72 GiB, 3995672576 bytes, 7804048 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
It's obvious: /dev/nvme0n1 is the SSD with my root data, /dev/nvme0n1p2 is literally root, and /dev/nvme0n1p1 is what I consider /boot/efi on the original system.
If it's of use and requested I can give the log files which Boot Repair has written after successfully (as it said) writing a new grub/efi configuration to the old original system.
Maybe someone might suggest concentrating on getting Secure Boot running: Everything's fine if I only find out more about how to possibly repair this machine, I appreciate any reasonable idea!
Since the machine is in a state where it at least starts reading boot information from nvme0, I have a feeling as if I'm just inches away from having this Kali configuration revived, but maybe I'm wrong, I don't get myself any further and need your help! There is no urgency or time pressure at all! The laptop is sitting here with a Kali Live stick, ready to give more information if needed and waits patiently for repair.
Thank you so much!