Grub(?) issues after partition changes

General system Newbie
1

Hi!

First of all sorry if this something that has been asked countless times, it is most probably related and already solved in some way somewhere, but i could not figure it out so please bear with me.

Short intro: I installed a new system lately, basically following the EOS installer. Then I messed up something with the partitions by resizing/moving them around. Also, it’s not critical for me to get this back up running, but i would kind of like to understand what went wrong or how i would fix it (in case i do have similar smart ideas on a more important system in the future).

So what I did:

Installed EndeavourOS and ticked “add fallback lts kernel”, because i thought it can’t hurt?

Slighlty later i wanted to install toolbox , which complained with about “no space left” on the efi partition. Okay i was wondering why that’s the case in the first place but also thought: “whatever, it’s a new system, how hard can it be”. So I:

  • Shrunk my main partition (it was [efi, main, swap] on a 1TB disk)
  • Moved my main partition 1GB forward, so there is space between efi and main
  • Backed up efi content
  • Deleted efi partition
  • Re-created efi partition as fat32 with 2GB and restored content
  • Edited fstab to fix the UUID of the now changed efi partition, the main partition UUID seemed fine.

Now that did not work, after trying to boot into the main system i am stuck in grub.

After this i tried following this guide, which already once fixed grub boot issues for me.

So I mounted the btrfs subvolumes, mount /efi, arch-chroot /mnt, make-grub, grub-mkconfig -o /boot/grub/grub.cfg. okay seemed fine, but still does not work.

Then i read about dracult and tried sudo reinstall-kernels and sudo dracut-rebuild buuuut still does not work.

So…what else would i do to fix this? I found entries in efibootmgr pointing to old entries and removed them, now i just have the EndeavourOs one left which i just created and a few others i am not sure about and thus not touch.

Thanks for all the great guides in this forum, if there is one that fits for my issue and i missed it, please just point me to it!

Edit:

Summary for the solution:

It seems like i created a mixup with systemd-boot and grub.

Installing latest kernels, followed by grub-makeconfig made the system boot again.

Essentially mount the partitions and chroot (as in the guide ) and then:

pacman -S linux linux-lts linux-headers linux-lts-headers
grub-mkconfig -o /boot/grub/grub.cfg
2

If you had enlarged it instead of recreating it, you probably would have had fewer issues.

If you have a /efi, you probably weren’t using grub. Did you have another linux distro at some point?

Can you share the output of:

pacman -Q | grep -E "dracut|grub|mkinit"
3

Thanks for the super quick reply! i already read some of your helpful answer in other posts :slight_smile:

If you had enlarged it instead of recreating it, you probably would have had fewer issues.

That was my initial intention, but for some reason “move/resize” was not available for that partition and (a very) short research on the topic said something like “thats normal” so i did not really think too much about it further.

If you have a /efi, you probably weren’t using grub. Did you have another linux distro at some point?

Yes, i used Pop_OS before. But it was the same for my desktop, where i also followed said guide and which worked (thats in fact the system i am writing from right now). But it could very well be one wrong base assumption. I was wondering about /efi vs /boot/efi and did not conclude on whats right or wrong, probably missing some basics there..

Can you share the output of:

pacman -Q | grep -E "dracut|grub|mkinit"

I assume from after chrooting?
That would be:
dracut 108_eos-1
eos-dracut 1.7-1
grub 2:2.12.r359.g19c698d12-1

4

Post:

cat /etc/fstab

sudo blkid 

efibootmgr
5

cat /etc/fstab:

#
# 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=5938-E2FA                            /efi           vfat    fmask=0137,dmask=0027 0 2
UUID=d9aafbe6-ba3f-4b9a-b65d-497a3cd92aaf /              btrfs   subvol=/@,noatime,compress=zstd 0 0
UUID=d9aafbe6-ba3f-4b9a-b65d-497a3cd92aaf /home          btrfs   subvol=/@home,noatime,compress=zstd 0 0
UUID=d9aafbe6-ba3f-4b9a-b65d-497a3cd92aaf /var/cache     btrfs   subvol=/@cache,noatime,compress=zstd 0 0
UUID=d9aafbe6-ba3f-4b9a-b65d-497a3cd92aaf /var/log       btrfs   subvol=/@log,noatime,compress=zstd 0 0
UUID=11ec9cfe-d4c4-48af-ae55-a6e2ef879c6f swap           swap    defaults   0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

sudo blkid:

/dev/mapper/sda1: LABEL="Ventoy" UUID="0A30-716D" BLOCK_SIZE="512" TYPE="exfat"
/dev/nvme0n1p3: UUID="11ec9cfe-d4c4-48af-ae55-a6e2ef879c6f" TYPE="swap" PARTUUID="1e97fa98-2391-4d1e-a18b-5c44b55e6e10"
/dev/nvme0n1p1: LABEL_FATBOOT="efi" LABEL="efi" UUID="5938-E2FA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ffb4fcd6-3394-48d9-b2a5-05624333a825"
/dev/nvme0n1p2: UUID="d9aafbe6-ba3f-4b9a-b65d-497a3cd92aaf" UUID_SUB="224fc72d-ec6e-4ef3-8fd4-5bf518bedaa1" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="4ef23ce3-9b8f-4993-be1a-1373d0eb0469"
/dev/loop0: BLOCK_SIZE="1048576" TYPE="squashfs"
/dev/mapper/ventoy: BLOCK_SIZE="2048" UUID="2025-03-19-11-30-07-00" LABEL="EOS_202503" TYPE="iso9660" PTUUID="ea64eddc" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="VTOYEFI" LABEL="VTOYEFI" UUID="626B-4255" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="38131597-02"
/dev/sda1: LABEL="Ventoy" UUID="0A30-716D" BLOCK_SIZE="512" TYPE="exfat" PARTUUID="38131597-01"

efibootmgr:

BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0005,0003,0001,0004,0006,0002,0000
Boot0000* UEFI HTTPs Boot       PciRoot(0x0)/Pci(0x1f,0x6)/MAC(000000000000,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
Boot0001* UEFI Intenso Intenso Micro Line 1104000000030448      PciRoot(0x0)/Pci(0x14,0x0)/USB(0,0)/USB(2,0)/HD(2,MBR,0x38131597,0x39c0000,0x10000)/\EFI\Boot\BootX64.efi{auto_created_boot_option}
Boot0002* Linux Firmware Updater        HD(1,GPT,90855eca-02d1-4d58-a180-ac02e9d0cc37,0x1000,0x1fefff)/\EFI\pop\fwupdx64.efi
Boot0003* arch  HD(1,GPT,ffb4fcd6-3394-48d9-b2a5-05624333a825,0x800,0x3f4000)/\EFI\arch\grubx64.efi
Boot0004* Linux Boot Manager    HD(1,GPT,c47d9f7d-de80-4a5e-b0a4-8d6e14a0beec,0x800,0x200000)/\EFI\systemd\systemd-bootx64.efi
Boot0005* EndeavourOs   HD(1,GPT,ffb4fcd6-3394-48d9-b2a5-05624333a825,0x800,0x3f4000)/\EFI\EndeavourOs\grubx64.efi
Boot0006* UEFI RST PM9A1 NVMe Samsung 1024GB S6H2NX0W338723     HD(1,GPT,ffb4fcd6-3394-48d9-b2a5-05624333a825,0x800,0x3f4000)/\EFI\Boot\BootX64.efi{auto_created_boot_option}
6

The /efi mountpoint, as mentioned already by @dalto, is used for systemd-boot.

If you just followed the installer, it defaults to systemd-boot.

Did you choose Grub in the installer when the option was given?

In that case, ESP defaults to mountpoint /boot/efi in EOS.

If you chose Grub when the option was given, did you change the mountpoint later when you edited /etc/fstab ?

This indicates that at some point systemd-boot was used. Is it an old entry belonging to another install?

7

When you edited /etc/fstab did you accidentally change /boot/efi to /efi?

8

f you just followed the installer, it defaults to systemd-boot.

Did you choose Grub in the installer when the option was given?

I do not recall changing this, but just assumed “grub is used for EOS”, more or less based only on the guide i linked. Judging by how it described to use grub-install etc. It might be a wrong assumption on my end?

I am 90% sure i used the same guide with grub-install pointing to /efi on my desktop system so i did not consider this to be a problem.

This indicates that at some point systemd-boot was used. Is it an old entry belonging to another install?

Either a remnant from Pop or i did something wrong and indeed systemd-boot is used? I can not really say.

dalto

When you edited /etc/fstab did you accidentally change /boot/efi to /efi?

The only thing i changed in fstab was the UUID for the efi partition.

I realized i lied when i said default installer. I setup the partitions manually because i wanted to enable LUKS (but failed at that apprently). So there i set efi to mount at /efi, based on what i did some time before on my desktop. I guess that was wrong but at least it worked until i messed with it further :slight_smile:

9

Could you post:

ls /boot

ls /efi
10 
ls /efi
bf0a72c05cc449b4b8eeecd408a2bd73  EFI  loader

ls /boot
6.12.51-1-lts   grub                          initramfs-linux.img               initramfs-linux-lts.img
6.17.1-arch1-1  initramfs-linux-fallback.img  initramfs-linux-lts-fallback.img  intel-ucode.img
11

It looks like you have created a mixture of both systemd-boot and Grub.

Also, if grub is your current active bootloader, the content of /boot shows that you don’t have any kernels ( vmlinuz-*) to be loaded. You have only initramfs.

Reinstall your kernels:

pacman -S linux linux-lts linux-headers linux-lts-headers

12

Thats what i guessed/hoped intitially by doing

sudo reinstall-kernels

sudo dracut-rebuild

But as this didn’t work there seems to be another mess, as you said with a mixup probably.

vmlinuz-*

I actually searched for this and was really wondering why there is no such thing to be found (e.g. with find . vmlinuz-* ?). I will try to reinstall one more time and if it doesn’t work i guess “wipe and reinstall” it is?

Another thing: If i recall correctly i wiped the partition (i.e. deleted everything from before) and then set news one for EOS. So i am really curious how i managed to have traces of Pop in there. Or is it just really the systemd/grub mixup? In that case, is there a similar guide for systemd maybe? Like “Repair non booting systemd” ? :slight_smile:

13

This is used for systemd-boot.

This would only rebuild your initramfs, if I am not mistaken.

You need to install/reinstall the kernels.

14

This is used for systemd-boot.

it even says so in the guide .. so i did both of those commands, thats probably one root cause of the mixup ?

You need to install/reinstall the kernels.

How do i do this with dracut?

15

Just use the regular pacman to install:

16

i wasn’t aware its that easy, thanks :slight_smile:
Though, i get an error after “Checking which library files need to be rebuild”: fatal library error: lookup self . I saw this should be ok when in chroot? But if i rerun the pacman command it shows to install everything again, so i am not sure if it’s ok?

Though the system still goes to a grub screen with only “UEFI settings” to choose from :confused:

17

This is normal.

Chroot again and regenerate the grub.cfg:

18

Now it works!! Thank you so much for your patience! :grin:

Only now it shows up as “Arch linux” entry from grub, is that because of the last grub-mkconfig command? Or because i (maybe) used grub-install at some point before without specifying distribution-id ?

In any case, it works, this is great!

19

Not sure if EOS ships its own /etc/default/grub. Most probably it does.

If it is important to you, you could edit this file and change:

GRUB_DISTRIBUTOR=

Then run

You don’t need to chroot.

PS.

You could remove bf****** and loader directories in there. Leave EFI as is.

20

not very, but was curious, thanks :slight_smile:

for clarification: the system is now indeed using grub and boots with /efi , right? are those two folders remnants from a previous install somehow? Or did i maybe really choose systemd-boot initially and now unintentionally switched to grub ? Does it really matter to me other than now at least knowing what i use?