how to fix (or reinstal) UEFI boot patition on GPT disk?

Question

Debian 11 new install on new hard disk, UEFI mode and GPT partitioned disk. The problem is, when boot system, the error is shown:

"Internal hard disk drive not found. To resolve this issue, try to reset the drive. No bootable devices -- strike F1 to retry boot, F2 to enter setup menu, F5 to enter PSA."

Installation was from Live USB, before this, I created partitions use GParted Live. I think possibly issue was when I created first (boot) partition, first I've set Label name 'efi', then tried to rename it to '/boot/efi': and GParted immediately hung and stop responds, so I had manually power-Off to force PC shut down. Possibly two slashes '/' in label name could cause an issue, but I'm not sure.

$ efibootmgr -v
BootCurrent: 000C
Timeout: 1 seconds
BootOrder: 0000,0004,0003,0009,000A,000C
Boot0000* Debian    HD(1,GPT,c906677e-c2c2-42b5-b818-f0b19c046e95,0x800,0xfa000)/File(\EFI\Debian\shimx64.efi)
Boot0003* UEFI OS   HD(2,MBR,0xfcba9dae,0x14000,0x1388000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0004* UEFI OS   HD(2,MBR,0xb45e11b8,0xaf800,0x600000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0009* Onboard NIC(IPV4) PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(20474749bc75,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot000A* Onboard NIC(IPV6) PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(20474749bc75,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot000C* UEFI:  USB DISK 2.0 PMAP  PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(3,0)/HD(1,MBR,0xcd9a6b9,0x5d4,0x146a)..BO

EDIT: blkid & fdisk output

$ sudo blkid
/dev/sdb1: BLOCK_SIZE="2048" UUID="2021-10-09-12-36-57-00" LABEL="d-live nf 11.1.0 xf amd64" TYPE="iso9660" PTUUID="0cd9a6b9" PTTYPE="dos" PARTUUID="0cd9a6b9-01"
/dev/loop0: TYPE="squashfs"
/dev/sda1: LABEL="BOOT" UUID="2F1D-01E6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c906677e-c2c2-42b5-b818-f0b19c046e95"
/dev/sda2: LABEL="swap" UUID="1274a782-676a-41b0-8509-92f73bd675c3" TYPE="swap" PARTUUID="4a555697-e713-400d-ae9e-613d028c7893"
/dev/sda3: LABEL="root" UUID="13503165-9c5f-498d-ab5f-0c13f11cbaa6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="5484dedd-6adf-45af-b7b0-ba105d14528b"
/dev/sda4: LABEL="home" UUID="93c98828-5fb8-4c0e-b6bf-de8d13a9d22e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ae15bbdb-4e29-4dfa-aa99-b39e5377a098"
/dev/sdb2: SEC_TYPE="msdos" UUID="DEB0-0001" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="0cd9a6b9-02"

$ sudo fdisk -l
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: TOSHIBA HDWK105 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0C3CF112-75DD-4197-9A0C-7C92036731C6

Device        Start       End   Sectors   Size Type
/dev/sda1      2048   1026047   1024000   500M EFI System
/dev/sda2   1026048   9414655   8388608     4G Linux swap
/dev/sda3   9414656  61843455  52428800    25G Linux filesystem
/dev/sda4  61843456 976773119 914929664 436.3G Linux filesystem


Disk /dev/sdb: 7.22 GiB, 7747928064 bytes, 15132672 sectors
Disk model: USB DISK 2.0    
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: 0x0cd9a6b9

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *        0 6240351 6240352    3G  0 Empty
/dev/sdb2        1492    6717    5226  2.6M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 2.6 GiB, 2789027840 bytes, 5447320 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

In BIOS menu: [Debian (Drive not present)]

smartctl tool show the disk is Ok:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

/etc/fstab content:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=2F1D-01E6                            /boot/efi      vfat    defaults,noatime 0 2
UUID=13503165-9c5f-498d-ab5f-0c13f11cbaa6 /              ext4    defaults,noatime 0 1
UUID=93c98828-5fb8-4c0e-b6bf-de8d13a9d22e /home          ext4    defaults,noatime 0 2

EDIT: parted error

root@debian:/# parted /dev/sda1
GNU Parted 3.4
Using /dev/sda1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: Unknown (unknown)
Disk /dev/sda1: 524MB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags: 

Number  Start  End    Size   File system  Flags
 1      0.00B  524MB  524MB  fat32

(parted) help toggle                                                      
  toggle [NUMBER [FLAG]]                   toggle the state of FLAG on partition
        NUMBER

    NUMBER is the partition number used by Linux.  On MS-DOS disk labels,
        the primary partitions number from 1 to 4, logical partitions from 5
        onwards.
        FLAG is one of: boot, root, swap, hidden, raid, lvm, lba, hp-service,
        palo, prep, msftres, bios_grub, atvrecv, diag, legacy_boot, msftdata,
        irst, esp, chromeos_kernel, bls_boot
(parted) toggle 1 esp                                                     
Error: No flags supported
(parted) toggle 1 bios_grub                                               
Error: No flags supported
(parted) quit

Answer 1

Since /dev/sda1 appears to be an EFI System Partition (ESP for short), it should have been configured to mount to /boot/efi by the Debian installer. The label is not really important, as the installer will normally configure /etc/fstab to mount it by filesystem UUID anyway.

The /etc/fstab line would in your case be:

UUID="2F1D-01E6"    /boot/efi    vfat   umask=0077,tz=UTC,codepage=437,iocharset=iso8859-1 0 1

Since the bootloader was apparently successfully registered to the system NVRAM (as indicated by efibootmgr -v), it is possible that the disk is actually fine, but when trying to start up the system, the UEFI firmware might not give the disk enough time to spin up before attempting to read from it, causing a false "disk not detected" error condition.

If that's the problem, then you should check the BIOS settings for any option that would slow down the boot process by just a few seconds. Some BIOSes have a dedicated "boot delay" option for just this purpose. If there is no adjustable delay, you might have to try alternatives like disabling Fast Boot, enabling legacy USB support, etc... anything that could give the disk a few extra seconds to spin up.

Before converting to legacy mode, you might try setting the system to try booting from network before the "Debian" UEFI boot entry. That should definitely take enough time to allow the disk to complete spin-up. You may be able to accomplish this with the efibootmgr command:

efibootmgr --bootorder 0009,0000,0004,0003,000A,000C

Waiting for the network boot to fail might be irritating in regular use, but if the disk works with this configuration, it would confirm the problem is the slow-starting disk.

You said the disk is new, and in the comments you mentioned the system is an old Dell laptop. Is the disk an official spare part from Dell? If you just bought a generic 2.5" SATA HDD for it, you may have run into a hidden requirement that is fulfilled by the official Dell spare part disk but not necessarily by your chosen replacement disk: in order to work successfully as a system disk, the disk needs to be ready to receive commands by some xxx milliseconds after power-up, since that's when the system firmware checks for the disk.

If the TOSHIBA HDWK105 you chose is significantly slower to start up than the original disk, that problem might not be fixable by changing the boot method or any other available BIOS settings. If the disk is the same model as the original, remember that a large vendor like Dell might even get disks with custom firmware, optimized for a particular use case.

If the laptop is from the first half of 2010's, at that time UEFI was new and vendors like Dell might have still perceived the legacy boot mode as their primary target, and as a result, the UEFI boot mode might have received less testing. At that time, there was a lot of more or less buggy UEFI implementations. (The UEFI became mainstream in 2011, as Intel introduced the Sandy Bridge chipset that was designed to be used with UEFI rather than classic BIOS.)

If you want to try changing the boot mode from UEFI to legacy, you must boot from the live media and chroot into the HDD-based installation:

mount /dev/sda3 /mnt
mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
mount -o rbind,rw /dev /mnt/dev
chroot /mnt /bin/bash
mount -a   # to mount the /home filesystem; not essential for this task

After the chroot command, your command-line session should be able to access the HDD-based installation essentially as if the system was booted from the HDD. So, you can use the normal package management tools to remove the grub-efi-amd64* packages and install grub-pc* packages in their stead:

apt remove grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed
apt install grub-pc grub-pc-bin

You might also want to remove the packages related to the Secure Boot shim, as it's unnecessary in legacy boot mode:

apt remove shim-signed shim-unsigned shim-helpers-amd64-signed shim-signed-common

In order to provide a location for grub-pc to embed its core image, you could switch the partition type of /dev/sda1 to bios_grub. It's a bit of a waste as grub-pc needs only 1 MB for its core image, but it would allow conversion back into UEFI mode in the future if necessary.

parted /dev/sda1
(parted) toggle 1 esp
(parted) toggle 1 bios_grub
(parted) quit

Then comment out the /boot/efi line in /etc/fstab and ensure /boot/efi is unmounted, as the beginning of that filesystem is going to be overwritten by the BIOS GRUB.

Now the disk is ready to have a BIOS-booting version of GRUB installed. Since the system may currently be booted in UEFI mode, you will need to specify the GRUB target architecture explicitly; by default, grub-install may attempt to install a bootloader that matches the system's current boot style.

grub-install --target=i386-pc /dev/sda

After this, the conversion should be complete: it's time to undo the chroot process:

umount /home # (if you ran "mount -a" after chrooting)
exit   # to pop out of the chrooted shell session
umount /mnt/dev
umount /mnt/sys
umount /mnt/proc
umount /mnt

Then it's time to reboot the system, go into BIOS, set the boot mode to Legacy, and set the HDD as the boot target.

Good luck! Working with name-brand laptops that have very minimal BIOS settings can be irritating, and systems with buggy/quirky early-version UEFI implementations can also be a headache. It seems you may have a system where these two facts combine.