OK, tried that and saw that os_prober detected the other Linux OS. However, rebooting just boots straight into Manjaro again with no menu.
Oh, and GRUB_DISABLE_OS_PROBER=false was already not commented out.
And the mentioned GRUB_TIMEOUT and GRUB_TIMEOUT_STYLE? If not already, set former to 10 and latter to menu (and save, rerun sudo update-grub and reboot to see),
First of all, use PREFORMATTED TEXT </> when posting output.
- Chroot
- Update everything
- Install all kernels you had - again. (you can do last two points simultaneously)
By the way…
Generating grub configuration file …
Found theme: /boot/grub/themes/EndeavourOS/theme.txt
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux.img
…these are not manjaro’s files.
1 Like
All his stuff is still there; he just has a weird situation with /boot on a dedicated (not weird) FAT-formatted (weird) partition and some confusion about probably former legacy install vs now UEFI. we’ve just managed to get him into Manjaro again; now waiting for confirm/deny that with the Manjaro Grub he can also boot his other two installs.
Once all works it’ll seemingly be a good idea to reformat that /boot partition to ext4 or integrate it outright, since it seems the Endeavour OS Grub tripped over it (over something at least) when it reinstalled itself on update.
To be honest I haven’t looked too hard at those walls of unreadable text. 
Why is vfat partition weird? I have it too (using systemd-boot).
Normally (well, surely, even) /boot/efi is VFAT if it’s the ESP but /boot itself does not tend to be. Yes, seems it probably should be able to be, but it’s a non-common situation at least and if we need to explain the other supposedly non-common situation of the Endeavour OS Grub effing up then I’m personally going to start there 
Let me in any case for now wait for the mentioned confirm/deny…
Yes, that’s fixed it. I now have a boot menu which can access Manjaro and the other linux OSes. Thank you very much for all your help. 
I’m just a bit concerned that another grub update will come along at some time and muck everything up again…
Do the simplest thing first, which is manjaro-chroot -a. It will, hopefully, do all the work of guessing where is what for you. Then just follow with other 2 points.
…nevermind then. 
Yes, I agree that’s a definite chance. As I just said to zbe, although things “should” work I’m suspicious of the FAT-formatted boot being the thing that the Endeavour OS Grub tripped over. I.e., it being in some sense not set up with FAT support for loading the kernel from – which seems weird, but well, we need to explain things somehow…
If you’re up for it I’d backup /boot, unmount and reformat it ext4, remount and restore contents. Guess I can give direct instructions if need be – but note it’s all a bit uncertain as to how needed it is.
As it’s all functioning again, I don’t want to risk doing anymore with it atm. The last two grub updates for me have been problematic for different reasons, but I guess I’ll cross that bridge when I come to it.
Thanks for your immense patience!
Sure; glad things worked out – for now
1 Like
Since you mention it - did you fiddle with the great systemd boot guide by @dalto on EndeavourOS forum?
The following looks like a mount hiding the real content
This indicates several kernels foreign to Manjaro - so it is a confused system to say the least
[rant] Multiboot may prove valuable when used correct - but used without considerations - it becomes a plague.[/rant]
Absolutely agree, hence why i prefer to bind-mount my /boot from a specific subdir of /efi 
He said that his /boot on the Manjaro system showed empty when viewed from Endeavour (and his Manjaro /etc/fstab in fact mounted that filesystem on /boot – and it is 10G large) so it does seem like it is/was a simple matter of a once intentionally split off /boot
Even if having that formatted as FAT would not be normal. I due to that originally considered it likely that he mistakenly placed all of /boot on the ESP as such but not even that: his Manjaro /etc/fstab not mentioning /boot/efi nor an efi mountpoint in fact existing on that /boot fs probably means Manjaro was originally installed in Legacy rather than UEFI mode and that he was up to now using either Endeavour’s or one of the other system’s Grub instances to boot that originally legacy Manjaro install in UEFI mode – which instance presumably then recently broke loading the kernel of a FAT fs, which is why I wanted him to reinstall the Manjaro Grub.
That scheme worked in the end – as mentioned until whatever instance of Grub that seem’s broken in this FAT regard reinstalls itself again as a matter of an update but hey
By the way, to original poster: now that Manjaro is booting in UEFI mode using the Manjaro Grub, I would at the very least add to the Manjaro /etc/fstab
/dev/nvme0n1p1 /boot/efi vfat defaults/boot/efi should already exist as a matter of what was done but check; if not, first simple sudo mkdir /boot/efi.
This should at least keep things going from the Manjaro side also if Grub updates there.
[EDIT] For some reason this board has now turned me typing /boot/efi into /boot<space>efi 3 or 4 times until I edit it back; sorta sucks.
1 Like
Must be your auto-discorrect 
OK, thanks for that, I’ve made those changes. (/boot existed but not /boot/efi!)
I don’t recall having any major problems with Grub until a few weeks back with the notorious update which caused all kinds of problems with the EOS boot loader (out of memory, etc). I remember trying various things at the time to get it to work, which may well explain some of the weirdness, although I’m pretty sure I decided against the systemd boot approach.
Don’t fight vs systemd it’s the future, the sooner you adapt to everything the systemd way the easier your live will be in long run in a distro agnostic way.
Just as a follow-up, I tried to install the latest Fedora yesterday and the installer complained about efi being on vfat and wouldn’t let me proceed!
You misunderstood whatever error you saw. EFI has to be on vfat aka FAT32.