0

i have an Intel Nuc-8i3beh running a Debian 10 Buster and Windows 10 in dual boot. The Windows system was installed first. The bootloader is grub in uefi mode.

System:
sda -> main harddrive with windows and debian on
sdb -> second harddrive for data
sdc -> external harddrive for backup of second harddrive

I recently installed some new drivers for the intel systems in Windows 10. After that my bootloader is not showing up anymore. The system directly boots in Windows. I then tried to run a boot-repair image on an usb stick, but the default repair of the Boot-Repair utility wont work. Here is the hole summary of the boot-repair: http://paste.ubuntu.com/p/kgPymkWqGM/

I think the problem lies in the line 29:

wrong fs type, bad option, bad superblock on /dev/sda6, missing codepage or helper program, or other error

Somehow the tabel of the superblocks are not correct anymore:

Disk sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk identifier: EC763990-4AF7-4A4C-A3AA-355A8DC62FB8
          Start       End   Sectors  Size Type
sda1       2048   1085439   1083392  529M Windows recovery environment
sda2    1085440   1290239    204800  100M EFI System
sda3    1290240   1323007     32768   16M Microsoft reserved
sda4    1323008 117221375 115898368 55.3G Microsoft basic data
sda5  117221376 125034495   7813120  3.7G Linux swap
sda6  125034496 234437070 109402575 52.2G Linux filesystem

The end of sda6 is not correct anymore.

I tried the following after telcoM's answer. I booted with a live system of debian with an usb drive:

efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
Could not prepare Boot variable: Permission denied

The same i tried after that with sudo:

sudo efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
Could not prepare Boot variable: No space left on device

After reading the comment i tried to run the fsck command without success:

sudo e2fsck -C0 -p -f -v /dev/sda6
/dev/sda6: The filesystem size (according to the superblock) is 13675776 blocks
The physical size of the device is 13675321 blocks
Either the superblock or the partition table is likely to be corrupt!


/dev/sda6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    (i.e., without -a or -p options)

I don't know what options i have to set on fsck when running it manually.

Anyone got an idea of how to fix that? Very thanks

0

Is your sda6 supposed to be encrypted or something? That might explain why Boot-Repair cannot make any sense of it.

The efibootmgr -v output within the Boot-Repair summary could be important here:

efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004,0002,0003,0001
Boot0000* Windows Boot Manager  HD(2,GPT,768a1a9a-11ae-40d1-a0d8-b52954fa5abc,0x109000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...M................
Boot0001* debian    VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0002* UEFI : LAN : PXE IP4 Intel(R) Ethernet Connection (6) I219-V  PciRoot(0x0)/Pci(0x1f,0x6)/MAC(1c697a017978,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* UEFI : LAN : PXE IP6 Intel(R) Ethernet Connection (6) I219-V  PciRoot(0x0)/Pci(0x1f,0x6)/MAC(1c697a017978,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0004* UEFI : USB : SanDisk : PART 0 : OS Bootloader PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)/HD(1,MBR,0x456c7,0x800,0x3a7f800)..BO

From here, you can see that the UEFI boot option named debian still exists, but apparently Windows has pushed it way back in the boot order, and has made itself the first boot item. So the problem might be with the firmware settings, not with GRUB itself.

(Apparently at least some versions of Windows 10 really want the UEFI Boot0000 slot for itself, but won't mind if it isn't necessarily set as the first one in the BootOrder. But if Windows is started and its UEFI boot settings are missing, Windows will definitely auto-restore itself as the first OS in the BootOrder, in an attempt to self-heal. When dual-booting with UEFI, it might be wise to assume Windows will always occupy Boot0000 and configure the other OSs accordingly.)

Your debian boot entry looks a bit odd, though. It does not refer to a regular UEFI bootloader like Windows's Boot0000 entry does. Since sda2 seems to contain a valid-looking GRUB with a pathname like Debian normally uses on the EFI System Partition, I would have expected a normal Secure Boot-compatible debian entry to look like:

Boot0001* debian HD(2,GPT,68a1a9a-11ae-40d1-a0d8-b52954fa5abc,0x109000,0x32000)/File(\efi\debian\shimx64.efi)

But your debian entry has VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) instead.

It could mean that your Debian used to use the legacy BIOS-compatible boot method, or perhaps the firmware uses some strange vendor-specific kludge.

If you can manually run efibootmgr using Boot-Repair or any other Linux Live USB, you could perhaps fix this pretty quickly with:

efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
efibootmgr -0 0005,0001,0000,0004,0002,0003

The first command will define a new UEFI boot entry for Debian, identifying the correct disk and the pathname on the ESP partition (which can be shared by all UEFI bootloaders installed on the system, as per the UEFI specification).

The second command will rearrange the boot order to make the new entry be the first, the old debian entry second, then Windows as a third option, and then all the remaining possible options (to keep the firmware happy).

If you cannot find a way to use efibootmgr, you might be able to go to system firmware settings (often known as "BIOS settings", but that is technically an obsolete term as UEFI is not BIOS), and just change your boot order to try the boot entry named debian first before Windows Boot Manager. But that relies on the existing strange VenHw boot entry for Debian actually working... and that does not exactly fill me with confidence. But it certainly does not hurt to try.

2
  • You probably need fsck on sda6 before running the efibootmgr commands to repair boot. You show Debian UEFI boot in /EFI/Debian & mount of ESP in fstab. e2fsck commands: askubuntu.com/questions/642504/… – oldfred Oct 6 '20 at 14:44
  • Hey thanks for the help. I tried it yesterday but it didn't quite worked. I edited my answer according to the problem. – alwa Oct 7 '20 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.