[SOLVED] Grub not working after installation (previously ubuntu partition)

I installed EndeavourOS via live USB onto a partition that was previously running ubuntu 20.04.
EndeavourOS works fine, but I can’t seem to correctly boot it.
I get redirected to the grub shell and manually load the correct partition like so:

grub>ls
grub>(hd0) (hd1) ... (hd0,gpt1) (hd0,gpt2) (hd1,msdos1)...

The partition which I installed EndeavourOS is (hd0,gpt2) so I do:

grub>set root (hd0,gpt2)
grub>linux /boot/vmlinuz-linux root=/dev/sda2
grub>initrd /boot/initramfs_linux.image
grub> boot

and it boots normally into EndeavourOS. Then I try to fix my grub installation:

$ sudo grub-mkconfig -o /boot/grub/grub.cfg
$ sudo grub-install /dev/sda

And I then get this error:

Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

I have tried specified the EFI partition following this answer:

$ sudo mount /dev/sda1 /mnt
$ sudo grub-install --efi-directory=/mnt

but I get this error:

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.

So I checked my /mnt folder:

$ ls /mnt/EFI
BOOT  endeavouros  ubuntu
$ ls /mnt/EFI/endeavouros
grubx64.efi
$ ls /mnt/EFI/ubuntu
BOOTX64.CSV  fw  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi

The old ubuntu folder is still there, but I’m not sure if I should get rid of it.
This is my system (sda for EndeavourOS and sdb for windows 10)

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 111,8G  0 disk 
├─sda1   8:1    0   512M  0 part /mnt
└─sda2   8:2    0 111,3G  0 part /
sdb      8:16   0 931,5G  0 disk 
├─sdb1   8:17   0 831,5M  0 part 
├─sdb2   8:18   0 926,6G  0 part 
└─sdb3   8:19   0   4,1G  0 part 
sr0     11:0    1  1024M  0 rom 

Any suggestions?

check if you are booting in efi mode

test

I have checked before, this is my results:

$ls /sys/firmware/efi
config_table  esrt              fw_vendor  runtime-map
efivars       fw_platform_size  runtime    systab

Check efibootmgr if there is an entry for EOS.

i would probably fix this using the live session instead and using arch-chroot instead.

mount sda2 /mnt
mount sda1 /mnt/boot/efi
arch-chroot /mnt
grub-install --target=x86_64-efi
grub-mkconfig -o /boot/grub/grub.cfg

thats how i would finx grub issues when i have them. but you probably know better than i am since i cant even understand how to use the grub rescue.

1 Like

Cant’ find any EOS reference. This is my output

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,000C,001A,0012,0007,0009,0011,0013,0014,0015,0017,0018,0019,0001,0002,0003
Boot0000* ubuntu
Boot0001* UEFI:CD/DVD Drive
Boot0002* UEFI:Removable Device
Boot0003* UEFI:Network Device
Boot0007  UEFI OS
Boot0009  CD/DVD Drive 
Boot000C* UEFI OS
Boot0011  UEFI OS
Boot0012* Unknown Device
Boot0013  ubuntu
Boot0014  ubuntu
Boot0015  UEFI OS
Boot0017  ubuntu
Boot0018  UEFI OS
Boot0019  ubuntu
Boot001A* UEFI OS

Please post your /etc/fstab.

When you installed did you use the manual partitioning during setup?

You probably didn’t edit the existing EFI partition to mark as /boot/EFI and flag as /boot and do not not format it when you installed EndeavourOS.

You’ll have to boot into the live iso as @negative suggested and arch-chroot to fix. Instructions are on the wiki.

https://endeavouros.com/docs/system-rescue/repair-grub-efi-uefi-system/

1 Like

Hmm…you replied to me @ricklinux . But I am not the OP… :wink: I have a working EOS…

I am not able to boot into endeavourOS anymore, instead of grub shell I get a wall of “grub” word repeat… I’m now booting from USB.
I don’t think the first part of the guide you linked is clear:" If not /boot is a folder under “ /” on the same partition as the filesystem root ." I don’t understand what it means in English :confused:

Anyway, from live USB I did:

$ sudo su
$ mount /dev/sda2 /mnt
$ mkdir /efi
$ mount /dev/sda1 /efi

so my devices now are:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0   1.6G  1 loop 
sda      8:0    0 111.8G  0 disk 
├─sda1   8:1    0   512M  0 part /efi
└─sda2   8:2    0 111.3G  0 part /mnt
sdb      8:16   0 931.5G  0 disk 
├─sdb1   8:17   0 831.5M  0 part 
├─sdb2   8:18   0 926.6G  0 part 
└─sdb3   8:19   0   4.1G  0 part 
sdd      8:48   1   3.9G  0 disk 
├─sdd1   8:49   1   1.7G  0 part 
└─sdd2   8:50   1    64M  0 part 
sr0     11:0    1  1024M  0 rom

Then:

$arch-chroot /mnt
$grub-mkconfig -o /boot/grub/grub.cfg
$grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=EndeavourOS-grub

but the last command got me this error:

Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

Note that after chroot you don’t have proper /efi mount. You need to mount it after chroot.

I’m sorry …doing this from the mobile phone doesn’t work too well sometimes. I miss things trying to enter info on this little screen. :disappointed:

1 Like

The error was due to starting live usb not in UEFI mode. I found out by chance on some ubuntu forum thread. I repeated the process suggested by the guide and now it works fine. Thanks everyone who tried to help, will mark as solved.

2 Likes

Nevermind :+1:.

1 Like

But you may clean up your NVRAM entries sometime. Lots of “ubuntus” there…

yeah, I definetily should. I am not sure which entries to delete though, last time I tried I endend up having a waterfall of “GRUB” instead a booting system. Is there a safe way to do this?
This is my current situation (after successfully fixing grub):

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,000C,001A,0012,001B,001C,001D,001E,001F,0007,0009,0011,0015,0002,0003,0004
Boot0000* ubuntu
Boot0001* EndeavourOS-grub
Boot0002* UEFI:CD/DVD Drive
Boot0003* UEFI:Removable Device
Boot0004* UEFI:Network Device
Boot0007  UEFI OS
Boot0009  CD/DVD Drive 
Boot000C* UEFI OS
Boot0011  UEFI OS
Boot0012* Unknown Device
Boot0015  UEFI OS
Boot001A* UEFI OS
Boot001B* UEFI: (FAT) UDISK PDU15_4G 71G2.0
Boot001C* UEFI OS
Boot001D* UEFI OS
Boot001E* UEFI OS
Boot001F* UEFI OS

This :slight_smile:
man efibootmgr

EXAMPLES

   Displaying the current settings (must be root):

       [root@localhost ~]# efibootmgr
       BootCurrent: 0004
       BootNext: 0003
       BootOrder: 0004,0000,0001,0002,0003
       Timeout: 30 seconds
       Boot0000* Diskette Drive(device:0)
       Boot0001* CD-ROM Drive(device:FF)
       Boot0002* Hard Drive(Device:80)/HD(Part1,Sig00112233)
       Boot0003* PXE Boot: MAC(00D0B7C15D91)
       Boot0004* Linux

       Each of the above are boot variables, which are defined as follows:

              • BootCurrent - the boot entry used to start the currently running system

              • BootOrder  -  the  boot order as would appear in the boot manager.  The boot manager tries to boot the first active entry in this
                list. If unsuccessful, it tries the next entry, and so on.

              • BootNext - the boot entry which is scheduled to be run on next boot. This supercedes BootOrder for one boot only, and is  deleted
                by the boot manager after first use. This allows you to change the next boot behavior without changing BootOrder.

              • Timeout - the time in seconds between when the boot manager appears on the screen until when it automatically chooses the startup
                value from BootNext or BootOrder.

              • Five boot entries (0000 - 0004), along with the active/inactive flag (* means active) and the name displayed on the screen.

   Creating a new boot option
       An OS installer would call efibootmgr -c.  This assumes that /boot/efi is your EFI System Partition, and is  mounted  at  /dev/sda1.  This
       creates  a new boot option, called "Linux", and puts it at the top of the boot order list. Options may be passed to modify the default be‐
       havior. The default OS Loader is elilo.efi.

   Changing the boot order
       Assuming the configuration in the first example, efibootmgr -o 3,4 could be called to specify PXE boot first, then Linux boot.

   Changing the boot order for the next boot only
       Assuming the configuration in the first example, efibootmgr -n 4 could be called to specify that the Linux entry be taken on next boot.

   Deleting a boot option
       Assuming the configuration in the first example, efibootmgr -b 4 -B could be called to delete entry 4 and remove it from the BootOrder.

   Creating network boot entries
       A system administrator wants to create a boot option to network boot. You create the boot entry with: efibootmgr -c -i eth0 -L  netboot  [
       -l '\filename.efi' ]

Ok I’ll start from that :slight_smile:
In case anyone was curious about the grub waterfall: https://giphy.com/gifs/Ss6b4xuYra0CChMky1

1 Like

I deleted some entries and I guess I deleted the windows 10 one too :scream:
Any suggestion on how to get that back?