First of all, sorry if this is in the wrong section, I did not find something more relevant. I am dual booting Windows 11 and Manjaro, they are on two separate drives.
A BIOS update wiped my Windows install, I had to completely reinstall Windows but Manjaro was still working before the reinstall. However, the Windows install completely wiped my Manjaro EFI partition. I tried the Manjaro live instance System Recovery but none of the three options worked.
I have some experience installing Arch, so I made an Arch install medium to try and remake the EFI partition:
Boot into Arch install
Create a new EFI partition using fdisk. The space at the start of the disk was empty because it used to contain the EFI partititon so I could simply make a new one the exact same size. Yes I wrote it as EFI System type.
Format it to fat32 via mkfs.fat -F32 /dev/sda3, I am not sure if the fact that it is not the first partition makes a difference.
Mount the main partition via mount /dev/sda1 /mnt
Mount the EFI partition via mount /dev/sda3 /mnt/boot/efi I had a look before doing this and found that path so I assumed that is where it should be installed, there was no separate EFI directory outside of /boot and when I installed Arch this is the path I used.
arch-chroot /mnt
Run grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro
Run grub-mkconfig -o /boot/grub/grub.cfg
Doing this looks successful and it does add a boot entry into the firmware but I can not boot into it. I even get the Manjaro logo telling me it is at least partially working, but I load until it throws me into emergency mode. I later tried doing this with the Manjaro installation medium instead, using manjaro-chroot, but it did not work either.
I can still access the main partition via the installation medium but the EFI partition will not work.
At this point I am out of ideas. I have no idea how to get log files out of it.
This should be done using manjaro … manjaro has its own grub that is sorta required to boot manjaro. That is manjaros grub can boot many different OSs … but most other OSs grubs cannot boot manjaro, ya dig?
Otherwise your approach of “Create partition at the beginning of the table, as fat32, mounted to /efi or /boot/efi, install grub to it, refresh entries and apply settings (update-grub)” seems broadly accurate.
EDIT - I just also remembered the esp and boot flags that should be set on the partition.
For further assistance I would ask for some further information like the layout of the partitions such as from sudo parted -l or similar.
I did try it using Manjaro, I do not know if it has different commands but I used the exact same process as with the Arch medium, except I used manjaro-chroot and it worked exactly the same as with the Arch install:
I can come back to you with the partition layout, do you need the layout of everything or just the disk with Manjaro on it?
Apparently I also missed the ‘New User’ banner, so hello and welcome.
Just the disk with manjaro on it should be fine.
Since you can boot into the manjaro installation I would think we can just do most of the work and information gathering from there.
Similarly doing things like creating a partition and managing its flags, etc, could be accomplished using gparted or similar via the available desktop.
Seems like it set the flags for the EFI partition automatically.
For funsies I may try and completely clear the /boot directory and try to make it again with Manjaro to see if it helps. If my original approach does not work, I see that EndeavourOS creates the /efi outside of /boot. Maybe Manjaro expects that too and I just messed something up.
It seems that I am able to manjaro-chroot into /dev/sda1 and access log files from it. I managed go grab the last boot (journalctl -b41, because just -b output nothing). Tried to boot it like an hour ago just in case it suddenly decided to work and this is that log.
I do not know which other logs are needed considering I can not even boot into the system.
The EFI System Partition (ESP) is always a separate partition.
/efi and /boot/efi are mountpoints only.
Calamares typically creates the /boot/efi mountpoint on Manajro during install; unless you choose the manual partitioning method and define a different mountpoint.
To access the $ESP via terminal you would use both the mountpoint and whichever directories might be targeted;
So, if you needed to ask for a directory listing of $ESP\EFI\Manjaro, for example, the following command would be used:
sudo ls /boot/efi/EFI/Manjaro
I’d suggest booting to a (latest available) Manjaro Installer ISO, and entering a chroot environment to reinstall GRUB2;
Not exactly true.
They should be actual paths … in the case of /efi it must be created manually as it is not present by default.
As noted above /boot/efi is considered ‘legacy’ and no longer recommended upstream, but if anything manjaro still expects the legacy /boot/efi path (mostly not anymore and will take either … but installs still default to the legacy version).
It is true. Just as /mnt/name would be be a mountpoint to a partition under that hierarchy, /efi or /boot/efi (created under /) are both mountpoints to the $ESP.
Of course every mountpoint requires a directory structure for the mountpoint to be defined; needed for the target partition to be mounted into. If /efi was defined during install (in preference to /boot/efi) that would be automatically created in it’s stead.
Adhering to /boot/efi as otherwise defined by Manjaro install negates any need to manually create a mountpoint; the procedures outlined in the linked guide will create it as needed.
Just after coming back from angrily plowing snow I did two final hail mary attempts, where I recreated the fstab (I admit I watched an Arch install video to see what they did), it did not work. I took a look at the file and it did not seem correct, then I deleted it and recreated it again, tried to boot and here I am!
Good thing, too, I was just about to take the nuclear option (reinstall everything).
Are you saying that you followed the linked guide and also changed the UUID reference in /etc/fstab, and that solved your issue, or, simply changing the UUID solved your issue?
