Installation fails: "failed to register the boot entry: Input/output error"

Hi,
I’m trying to install Endeavour on a completely wiped laptop. Both manual partitioning and auto-partitioning result in the following error:

Boost.Python error in job "bootloader".
Command 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS --force' returned non-zero exit status 1.
Installing for x86_64-efi platform. Could not prepare Boot variable: Input/output error grub-install: error: efibootmgr failed to register the boot entry: Input/output error.

Traceback:
File "/usr/lib/calamares/modules/bootloader/main.py", line 485, in run
    prepare_bootloader(fw_type)

  File "/usr/lib/calamares/modules/bootloader/main.py", line 457, in prepare_bootloader
    install_grub(efi_directory, fw_type)

  File "/usr/lib/calamares/modules/bootloader/main.py", line 319, in install_grub
    check_target_env_call([libcalamares.job.configuration["grubInstall"],

  File "<string>", line 6, in <module>

I’m using endeavouros-2020.07.15-x86_64 and created the USB drive with dd. Solus OS ran previously on the system (same drive) and booted without problems.

Thanks!

2 Likes

Could you share with us what that partitioning was? Especially the manual…

The EnOS experts will be along soon :smile:

My partitioning was:
(GPT)

  • 512MB fat32 /boot/efi
  • ~900GB ext4 /
  • 8GB swap

this is usually due to a mismatch.

A mismatch between GPT/UEFI and BIOS/MBR

The message you have introduced is not enough to deduct the reason but

error: efibootmgr failed to register the boot entry: Input/output error.

is a fairly good starting point.

What is deductable is

your designated $esp is

  • not a designated EFI partition
  • not formatted using FAT32

Probable solutions is

  • ensure partition is FAT32 formatted (mkfs.vfat -F32)
  • ensure your $esp is partition type EF00

GPT or MBR ?

in case of EFI , do a GPT format

you should also check under terminal
and just before installing

test -d /sys/firmware/efi && echo efi || echo bios
inxi -Mxxxa

go in chroot
and add theses options --recheck --verbose ( or --debug ) for grub-install

1 Like

fdisk -l /dev/sda shows “EFI System” as type, but lsblk -l o +PARTTYPE doesn’t show 0xef, instead some long UUID as parttype. Is this expected / correct or does the issue lie here?

test -d /sys/firmware/efi && echo efi || echo bios confirms that it’s EFI, and I’m using a GPT.

inxi doesn’t seem to exist in the live system.

can you add

sudo pacman -Sy inxi

While getting into a partial update mess by installing a wrong version of inxi is unlikely to cause any serious trouble, this is a terrible practice in general. Refreshing the local package database without updating, and then installing a package is just asking for trouble.

This, on the other hand, is safe:

sudo pacman -Syu inxi
2 Likes

Did you remember to set the boot flag on the /boot/efi partition?

1 Like

Here’s the output of inxi -Mxxxa

Machine:   Type: Desktop System: Medion product: Akoya E7226T v: 1.0 serial: 13CPE5050213 
           Mobo: Medion model: Akoya E7226T v: 1.0 serial: N/A UEFI: American Megatrends v: 606 
           date: 12/03/2013

Yes, boot and esp flags are set.

Odd there is no esp flag on the installer nor is it needed anymore. One simply has to use the boot flag.

1 Like

I had set both flags when doing it manually before the installation. However, I just retried the installation with doing the partitioning in the installer, and despite setting the boot flag there, afterwards the fat32 partition only has the msftdata flag instead of boot. Any idea what causes this?

Let’s try to get your system installed first.

I am thinking that since the bootloader gets installed at the end of the installation process could it be possible to chroot and manually install it? In case everything else is already properly installed.

Easiest to try and troubleshoot the easiest parts and move on from there. I have to run for a bit.

1 Like

When I do manual partitioning I usually use gparted and set EFI partition to /boot/efi and set the flag to /boot. I know if you use manual partition sometimes users forget to set this.

So the installation was successful? If so return sudo parted -l (letter ell not a 1) from terminal.

Sometimes i think is worth using live ISO and boot on it and check with gparted and if the flag is not set to boot then try setting it and reboot. As long as the efi partition was created and formatted fat32 it may have just not set the boot flag for whatever reason. Worth a shot trying first before drastic measures.