GRUB is gone after new drive install

General system Kernel, boot, graphics & hardware
1

I have recently gotten a new SSD to replace an older one, previously my system had:

Drive 1: Windows
Drive 2: EndeavourOS

I cloned the contents of SSD 1 to the new drive, and swapped them out. Upon booting back up, my option to boot to grub is not available and the motherboard BIOS only sees two options for Windows Boot Manager (despite the second drive having EOS installed and cleaned during EOS install process). Now I can’t seem to boot into my EOS drive.

Presumably, because I installed EOS with this Windows drive installed GRUB was installed to the Windows EFI? I was pretty sure I had created a new EFI partition on the EOS drive during the install, and would have assumed GRUB installed there.

Is there any way for me to reinstall grub on this drive / recover this? I still have the EOS installer on the flash I used to install, if that is of any help.

Thanks in advance for any help.

1 Like
2

I like that you already know what you need to do - you’re just not sure how to do it.
Here you go: Repair or Reinstall Grub

Boot into your live ISO, and open the wiki in a browser so you can copy and paste.

1 Like
3

Thanks, I’ll give that a shot

1 Like
4

So, after chrooting into the EOS system, it does not have grub or grub-install, so I installed grub using sudo pacman -S grub (I want the root to have it installed right?). I am running into some issues and wanted to consult so I don’t brick anything worse, it seems just a simple grub-install isn’t doing the trick. It would appear that the documentation on that page might be a bit off? (happy to update it, if that’s the case and it’s in git somewhere). From the section “Repair GRUB on EFI/UEFI systems” (seems like what I need?)

Only grub-install is needed no need to add any options, at least on EndeavourOS where we use the default efi-path /boot/efi what is the default used for the command already. The --bootloader-id option will create a new entry with the given ID that in some cases will not get set as the default boot entry in the firmware.

But my efi path appears to just be /efi and so I’m thinking that’s why grub-install is currently failing with error: cannot find EFI directory.

5

To confirm: Did you install with the standard installation?

Before you proceed, these instructions are made for a standard automatic installation, if you installed the system with a modified manual partition scheme

Also, while chrooted, what does the command below show:

ls /boot/grub/
6

Yup, I installed with standard installation. Perhaps I didn’t install grub, but instead had systemd-boot installed? Perhaps a hint, the EFI partition on the drive is 1GB which FWICT is larger than it would be for grub.

When I ls /boot/grub while chrooted, there is no output so that directory must be empty.

7

Correct

And correct.

How long ago did you install? Under 6 months?

8

Yeah, very recent less than 1 mo. ago

9

Yeah, so systemd-boot it is.

That being said, it’s not like you can’t install grub after the fact, but let’s try to get systemd-boot back on your system instead. https://discovery.endeavouros.com/installation/systemd-boot/2022/12/

This link is just for reference. One moment.

Okay, was looking for this: [Tutorial] Convert to systemd-boot

Be mindful of the section about dracut or mkinit

10

This is indicative of that your system used systemd-boot and not Grub.

What is the filesystem of your EnOS’ install?

Some output may help:

sudo parted -l

efibootmgr

And perhaps also the content of your /etc/fstab.

11

Hey, yeah so I do feel like it is systemd-boot then and I could have very easily just misremembered.

efibootmgr:

efibootmgr 

BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0001,0000,0002
Boot0000* Windows Boot Manager  HD(2,GPT,16f0fcf8-2215-11ef-ac36-085bd6d933ce,0x109008,0x32008)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d000000ffff0100000010000000040000007fff0400
Boot0001* Windows Boot Manager  HD(1,GPT,6cf2575a-3e2a-40fd-9179-0be8c1e2e1dd,0x1000,0x200000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI0000424f
Boot0002* UEFI: Samsung Type-C 1100, Partition 1        PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(6,0)/HD(1,GPT,cd1bbb97-580f-4f32-b956-982a300d54a8,0x800,0xef039c0)0000424f

fstab contents:


sudo cat /mnt/etc/fstab 
# /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=CEA1-3F6B                            /efi           vfat    fmask=0137,dmask=0027 0 2
UUID=b8df1fb2-eb84-45c9-a65f-ee0c9bf59898 /              ext4    noatime    0 1
UUID=63c9b951-1751-4610-8b05-f79f28e2cb90 swap           swap    defaults   0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0

and parted -l:

Model: Samsung Type-C (scsi)
Disk /dev/sdd: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name                 Flags
 1      1049kB  128GB  128GB  fat32        Main Data Partition  msftdata


Model: Samsung SSD 980 PRO 2TB (nvme)
Disk /dev/nvme0n1: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name         Flags
 1      2097kB  1076MB  1074MB  fat32           EFI          boot, esp
 2      1076MB  1963GB  1962GB  ext4            endeavouros
 3      1963GB  2000GB  36.9GB  linux-swap(v1)               swap


Model: Samsung SSD 990 PRO 4TB (nvme)
Disk /dev/nvme1n1: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  556MB   555MB   ntfs         Basic data partition          hidden, diag, no_automount
 2      556MB   661MB   105MB   fat32        EFI system partition          boot, esp, no_automount
 3      661MB   677MB   16.8MB               Microsoft reserved partition  msftres, no_automount
 4      677MB   4001GB  4000GB  ntfs         Basic data partition          msftdata

So bizarrely, it seems that the EFI partition for systemd-boot is there? But both efibootmgr and my motherboard bios think it is windows boot manager? When setting that device as the preferred boot device in my bios, it will not boot and I’m hit with some windows error screen.

1 Like
12

You probably just need to run sudo bootctl install from a chroot

2 Likes
13

Awesome, that got me booting back into my EOS install. One issue though, it seems that now, the Windows option in systemd doesn’t work, it boots into an error screen (I’m thinking this is because the drive that was previously there changed locations or IDs or something?)

1 Like
14

Likewise, I’m just kinda curious what could have happened here?

Is it that whatever entries created by running bootctl install were located on the drive I removed / replaced? (Doesn’t seem likely, since the efi partition is on the drive as demonstrated above)

Or systemd expected certain boot options to exist and because they changed when drives were changed, it refused to load? Trying to really understand it well for the future. Thanks

15

So I’ve tried finding an entry for this Windows option in the /efi/loader/loader.conf or /efi/loader/entries but I don’t see an option here. Is EOS auto generating this boot entry? Is there a way for me to remove it? It doesn’t seem to work, I’ve even tried to use akm to install a new kernel and see if that would regenerate the entries but it doesn’t seem to have helped that broken Windows boot option.

16

systemd-boot adds it when it detects windows automatically.

If you don’t want that, set auto-entries no in /efi/loader/loader.conf

17

I do find it quite useful actually, but seems that the windows EFI that my systemd is pointing to is broken for some reason. Does the autogeneration of entries look for any bootable media it can find, or is it scoped to the same device that it running from? i.e is there maybe a bad windows EFI partition on the same disk as the EOS install?

In other words, is it possible for me to manually remove this broken windows EFI and point systemd to one on another, separate disk? Perhaps worth mentioning that I can boot to that OS using the BIOS but it seems to be because it is a separate EFI entry than the one systemd is trying to use.

18

It is looking for Windows EFI files is in the same ESP is booting out of.

Yes, delete the Windows related files in /efi/EFI

Either copy the files from your other EFI directory to /efi/EFI or follow this tutorial:

2 Likes
19

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.