Bootloader Installation Error code 1

[pebcak]

Did you reboot successfully into your installed system?

[snehil]

Ok it worked

[pebcak]

Glad it worked!

Please check the solution box under this post:

Bootloader Installation Error code 1

It’s the same issue as with the installer. For some reason, grub-install fails to write into your ESP. I don’t know why You could try the following but I am not sure if it will work: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EnOS --force --removable

Also, welcome to EnOS’ community!

[joekamprad]

strange issue… i see this from the installer log (first one)

[PYTHON JOB]: "Bootloader: grub (efi)" 
    .. Running QList("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=endeavouros", "--force") 
    .. Target cmd: QList("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=endeavouros", "--force") Exit code: 1 output:
 Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
WARNING: [PYTHON JOB]: "Command 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=endeavouros --force' returned non-zero exit status 1." 
[PYTHON JOB]: "stdout:Installing for x86_64-efi platform.\nCould not prepare Boot variable: No space left on device\ngrub-install: error: efibootmgr failed to register the boot entry: Input/output error." 

Could not prepare Boot variable: No space left on device
from there i see also this:

nvme1n1p1 holds a windows ESP with 260MB

[pebcak]

Yes I saw that as well.

It’s strange since the issue is not that ESP doesn’t have any space left. It was newly created after all.

The issue seemed rather be that

 efibootmgr failed to register the boot entry:

I have seen this issue before with some UEFI implementations where the “regular” grub-install fails. Adding --removable seems to be a “solution” (workaround) as it was in this case.

[joekamprad]

@pebcak

I have seen this issue before with some UEFI implementations where the “regular” grub-install fails. Adding --removable seems to be a “solution” (workaround) as it was in this case.

lately or longer times ago? as of i remember this happens a long time ago often…

Mainly interested as there is an ongoing issue with kpmcore we are currently investigating.
Related to msdos partition scheme as we think… but could be also something else

[pebcak]

@joekamprad

nvme1n1p1 holds a windows ESP with 260MB

This is not the relevant ESP.

The relevant ESP for this install is /dev/nvme0n1p1 with the size of 1074MB.

@snehil

Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name         Flags
 1      17.4kB  1074MB  1074MB  fat32        EFI          boot, esp
 2      1074MB  256GB   255GB   ext4         endeavouros

[pebcak]

@joekamprad

@pebcak

I have seen this issue before with some UEFI implementations where the “regular” grub-install fails. Adding --removable seems to be a “solution” (workaround) as it was in this case.

lately or longer times ago? as of i remember this happens a long time ago often…

Mainly interested as there is an ongoing issue with kpmcore we are currently investigating.
Related to msdos partition scheme as we think… but could be also something else

Lately, no but if the issue, as I remember it, is related to some UEFI implementation, that wouldn’t be relevant.

[joekamprad]

@pebcak

Lately, no but if the issue, as I remember it, is related to some UEFI implementation, that wouldn’t be relevant.

good (or not good) but there will always be hardware not working 100%

[pebcak]

Perhaps you would want to consider adding --removable to the grub-install command line in the installer.

It may avoid situations like this particular case. Also, some users may install the system on an external disk.

It is harmless after all as it only installs the grub bootloader’s efi binary BOOTX64.EFI into the fallback path /boot/BOOT.

[joekamprad]

i remember that it can be problematic in some cases… would need to do some research… but if so yes would be something to think about… may as a fallback option in case specific error happen

[dalto]

Keep in mind the install failed before it finished. It was mostly done at that point so the system is probably working but there may be some services that aren’t running, missing or extra drivers or other small issues.

[pebcak]

@dalto

Keep in mind the install failed before it finished.

Are you referring to the failed installation reported in the first post?

They did install a second time successfully but with no bootloader so we could install it manually post-install.

[dalto]

@pebcak

They did install a second time successfully but with no bootloader so we could install it manually post-installs.

Oh, OK, that is good then.

[petsam]

@joekamprad

i remember this happens a long time ago often…

Most probably it is this issue.
Maybe the USB installer needs to boot in paranoia.

[joekamprad]

uh wau interesting i like these smart guys pulling in these hints

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Userspace_tools_are_unable_to_modify_UEFI_variable_data

I got some paranoia too now

Main problem with such issues is that these cases are very rare and if you do not have the hardware very hard to test …
I do not think its a good idea to boot this by default ?

FS#34641 : [linux] 3.8.x - 3.9.x Efibootmgr do nothing

[petsam]

@joekamprad

I do not think its a good idea to boot this by default ?

You may want to add a boot entry in installer’s boot menu, to use when this happens, while inform the user, either in wiki, or after a failure to install (if such detection is possible).
Or, add a button to clear such dump-* entries, or do it anyway from the start of the installer.
IIUC they are dump, not actually useful, probably created from errors, or someone forgot to clean their mess.

[petsam]

Maybe @snehil can confirm if there are actually such dump vars.

What is the output of this?

ls /sys/firmware/efi/efivars | grep "^dump" 

[joekamprad]

dump-* entry cleaning could be good to do … a slong as it is safe to do automatically…
And yea adding boot entry would be a thing but … confusing we can also add boot parameter manually in case needed

[petsam]

From Archwiki

If they exist, delete them, reboot and retry again.

Deleting is harmless

Warning: efi_no_storage_paranoia should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See FS#34641 for more information.

Boot option is not harmless.