I just went to boot Manjaro as usual from grub only to be greeted with:
error: file ‘/boot/initramfs-kernelname.img’ not found
When I view the boot directory from my EndeavourOS partition, the Manjaro /boot is indeed completely empty. I personally haven’t deleted it or changed anything there, so I’m at a loss to explain it…
Any help would be much appreciated.
I suppose that “kernelname” in /boot/initramfs-kernelname.img is a placeholder? I.e., it actually said something like “initramfs-5.15-x86_64.img”?
Is your /boot normally a seperate fs? Check /etc/stab on that partition from Endeavour if not sure.
Thanks for the reply. Yes, that’s correct. I have several Manjaro boot entries and none of them now work.
I have EndeavourOS on my my main SSD and Manjaro and OpenSUSE on my second SSD. The others all boot OK.
So as to be able to advise we really need to know whether or not your /boot was on a separate fs; if it is, seeing it empty from Endeavour would be expected. Yes, not too likely probably but an emptied /boot also isn’t so let’s make sure: check /etc/fstab on your Manjaro partition (as you said you could see from Endeavour) and see if it mentions anything about /boot.
It says this:
UUID=2DCB-8B08 /boot vfat defaults,noatime 0 2
UUID=aa6c1363-5b98-4342-a144-88d6db83f80a / ext4 defaults,noatime 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Are you reallyreallyreally sure that says /boot and not /boot/efi? If you are then it seems you’ve placed all of your boot onto the ESP and that should really not be the case and should then be repaired.
But if you are sure let us at least look there. I expect you in Endeavour have that same filesystem mounted on e.g. /boot/efi? The output of “sudo lsblk” would say. Or just mount it (again) with
sudo mount -t vfat UUID=2DCB-8B08 /mntand look in /mnt to see what’s in fact there.
Yes, that’s exactly what it says.
When I follow your instructions and look in /mnt it lists all the .img and vmlinuz files for my Manjaro kernels. It also has a grub directory.
total 173504
drwxr-xr-x 2 root root 8192 Feb 25 2021 ‘$RECYCLE.BIN’
drwxr-xr-x 6 root root 8192 Oct 29 15:47 grub
-rwxr-xr-x 1 root root 35255763 Oct 29 15:47 initramfs-6.0-x86_64-fallback.img
-rwxr-xr-x 1 root root 9088159 Oct 29 15:47 initramfs-6.0-x86_64.img
-rwxr-xr-x 1 root root 36219642 Nov 14 12:15 initramfs-linux61-fallback.img
-rwxr-xr-x 1 root root 9929035 Nov 14 12:15 initramfs-linux61.img
-rwxr-xr-x 1 root root 37050554 Nov 11 20:58 initramfs-linux-cachyos-fallback.img
-rwxr-xr-x 1 root root 9988314 Nov 11 20:58 initramfs-linux-cachyos.img
-rwxr-xr-x 1 root root 5678080 Nov 8 19:02 intel-ucode.img
-rwxr-xr-x 1 root root 23 Nov 13 22:30 linux61-x86_64.kver
drwxr-xr-x 2 root root 8192 Oct 30 15:34 memtest86+
drwxr-xr-x 2 root root 8192 Feb 25 2021 ‘System Volume Information’
-rwxr-xr-x 1 root root 11120224 Oct 26 22:52 vmlinuz-6.0-x86_64
-rwxr-xr-x 1 root root 11158048 Nov 14 12:15 vmlinuz-linux61
-rwxr-xr-x 1 root root 12085632 Nov 11 13:46 vmlinuz-linux-cachyos
That’s a /boot directory alright – but having that on vfat is quite unexpected and it does not even in fact appear to be an ESP (EFI System Partition).
Just for the heck of it; does currently in Endeavour the command
[ -d /sys/firmware/efi ] && echo UEFI || echo Legacysay UEFI or Legacy?
But “just for the heck of it” since although this situation definitely wants repair in essence /boot on VFAT probably/seemingly works, and what I take in fact happened is that Grub got (re-)installed from one of your other distributions which then screwed things up – so let’s reinstall Grub from Manjaro first; in fact repairing that mess can be secondary it seems.
We need the output of “sudo lsblk” for precise instructions…
It says UEFI.
sudo lsblk says:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 283G 0 part /run/media/endbob/aa6c1363-5b98-4342-a144-88d6db83f80a
├─sda2 8:2 0 1K 0 part
├─sda3 8:3 0 10G 0 part /mnt
├─sda5 8:5 0 99.5G 0 part /run/media/endbob/138a2f48-1fd3-48f7-9abd-1fe466a16644
└─sda6 8:6 0 73.3G 0 part /run/media/endbob/10108487-7dd6-4af1-8eb1-d2b95adddf83
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1
│ 259:1 0 300M 0 part /boot/efi
└─nvme0n1p2
259:2 0 238.2G 0 part /
EOS/Arch gave a new Grub update earlier today. Do you think this has messed things up?
Yes, it probably did and not in fact sure its intrinsically related to /boot being on VFAT.
I wanted the lsblk output to know that your Manjaro / is /dev/sda1 and /boot /dev/sda3 – but if you are booting in UEFI mode and not Legacy that should actually be irrelevant. If you run sudo update-grub from within Endeavour is Manjaro then detected and if so, can you after doing that reboot into it again?
If it’s on the other hand not detected; does /etc/default/grub on Endeavour specify
GRUB_DISABLE_OS_PROBER=false? If not have it say that and rerun sudo update-grub.
sudo update-grub shows:
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
Found fallback initrd image(s) in /boot: amd-ucode.img initramfs-linux-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Manjaro Linux (22.0.0) on /dev/sda1
Found openSUSE Tumbleweed on /dev/sda5
Found Redcore Linux Hardened - rolling (rolling) on /dev/sda6
Adding boot menu entry for UEFI Firmware Settings …
done
However, when I reboot, it’s still the same: all the other Linux OS will boot OK but Manjaro just gives the usual ‘.img not found’ error.
Am lightly dragging my feet here because the Manjaro /etc/fstab not specifying a /boot /efi nor an efi subdirectory in fact existing on your shown /boot seemed to imply Manjaro being booted in Legacy rather than UEFI mode, but if you in fact boot Endeavour in UEFI mode that seems to make no sense.
That is, wouldn’t want to miss something and make things only worse – but I say let’s then just reinstall Grub from Manjaro. You only live once, right?
$ sudo mount /dev/sda1 /mnt
$ sudo mount -t vfat /dev/sda3 /mnt/boot
$ sudo mkdir /mnt/boot/efi
$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/boot/efi
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /sys /mnt/sys
$ sudo mount --bind /proc /mnt/proc
$ sudo chroot /mnt grub-install
$ sudo chroot /mnt update-grubNone of these should produce errors. If that last update-grub step does not list also Endeavour and SUSE first edit /mnt/etc/default/grub to there also have GRUB_DISABLE_OS_PROBER=false and rerun it.
If it shows all found it’s probably safe to reboot and try again; you’d supposedly again at least be able to reboot into Endeavour/SUSE if still not Manjaro.
I can imagine something going wrong at the grub-install if the Manjaro install is in fact a legacy install – but let’s just see.
sudo chroot /mnt grub-install gives:
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.
As far as have ever seen this this is to say you’re booted in Legacy mode after all. Can you reconfirm that
[ -d /sys/firmware/efi ] && echo UEFI || echo Legacysays UEFI? You do have an ESP on your NVMe drive so really wondering here…
Definitely says UEFI.
I wonder if it might be confused as my second SSD (with Manjaro) used to be the main OS. I then got a new PC with an NVME drive on which I installed EOS.
I’m going to have to leave now as it’s getting late here. Thanks for all your help. Sorry to be a pain!
It would seem the case that originally the Manjaro install was a legacy install but I have just verified that the Arch/Manjaro Grub package hasn’t been split between UEFI and Legacy, i.e., that as far as I can think of this should’ve just worked – and it seemingly did before today so I’m coming up blank. Sorry, can’t for now think of other advise than to try that above reinstall recipe again but now from SUSE
Believe this’ll be it: seems newest versions want also /sys/firmware/efi/efivars bind-mounted. I.e., just before the grub-install step insert
mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivarsIt’s expected that the grub-install will then succeed.
OK, back again!
Tried what you suggested and this time it booted directly into Manjaro (no boot menu).
Okay, semi-great, as that’ll supposedly just mean os_prober is disabled Manjaro-sides together, then supposedly, with a zero timeout having been set there. I.e., you will in Manjaro want to look at / edit /etc/default/grub.
You want certainly the already mentioned
GRUB_DISABLE_OS_PROBER=falseIt’s in Manjaro present by default, but commented out (i.e., has a # at the start of the line; you’d remove that).
If you in Manjaro now run sudo update-grub both others should be found, and Grub is setup by default so that if other OSen are found it’ll present you the menu (I know, since I always immediately disable that…)
If not then also note GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE and, well, potentially others; if it doesn’t just work after the OS_PROBER and/or TIMEOUT thing I guess you can post your Manjaro /etc/default/grub for us to look at.