Fresh Install Stops Working After Update (grub config issue)

[Aragorn]

Welcome to the forum!

@Cronanius

Set up with an unformatted partition ~8MiB (as suggested in the installer pop-up), /boot partition ~2GB, / partition ~20GB, /home partition ~200GB, and ~10GB swap.

An unformatted partition — which may be as small as 2 MiB — is only needed if you are attempting to install the system with a GPT partition layout that boots in legacy BIOS mode. It is not needed if the machine boots in native UEFI mode — in which case you would need a formatted partition of ~300 MiB (mounted at /boot/efi) with a vfat (FAT32) filesystem on it — nor if you install the system on an MS-DOS MBR partition layout that boots in legacy BIOS mode.

@Cronanius

After installation, it worked for a single reboot. I ran a system update, and it installed a new kernel… and seems to have told grub to look in the root partition for everything. (Error: file /vmlinuz… not found)

There are only three scenarios in which you would come across the error that vmlinuz cannot be found.

1. If you interrupted the update process, in which case the old kernel image got deleted but the new compressed kernel image didn’t get installed — which only happens at the end of the update process;

2. If your /boot partition was not mounted during the update, which would cause mkinitcpio to create the initramfs and the compressed kernel image in the /boot directory, but not on the filesystem that would normally be mounted there; or

3. The kernel you were trying to update is EOL and is no longer provided by the update process.

@Cronanius

Would someone mind pointing me at the correct repair process that’ll actually get grub to change its ways?

I would suggest booting up from the live USB, mounting your on-disk root filesystem to /mnt/ and checking whether the conditions of #2 here-above apply, i.e. /mnt/boot contains your vmlinuz and initramfs images.

If that is the case, then temporarily copy them over to somewhere else — e.g. to the live USB — and then mount your /boot partition to /mnt/boot, and then copy over those files to /mnt/boot/. And then, chroot into your system using…

su - 
manjaro-chroot -a

… and run…

mkinitcpio -P && update-grub

After this, it should be safe to (cleanly) reboot.

If on the other hand the problem is the result of an interrupted update, then please see this tutorial…

[HowTo] Recovering from an interrupted update/upgrade

Difficulty: ★★☆☆☆ So you couldn’t wait until the update process had completed and you went for the reset/power button, didn’t you? And now you’re getting the message that you don’t have a kernel installed. Well, you’re not the only one — we’re seeing it happen all the time. So, here’s how to fix it, you impatient n00b. If you don’t happen to have a recent Manjaro installer USB/DVD/CD handy, direct your browser to this wonderful page, download t…

If the kernel you were trying to update was no longer supported, use mhwd-kernel from inside the chroot environment to install a more recent one. I recommend one of the LTS kernels, e.g. …

mhwd-kernel -i linux66

---

@cscs

• • Technically even this is no longer the recommended way (/efi is preferred over /boot/efi)

It is only the recommended/preferred way of the systemd developers — and by consequence, in RedHat, Fedora and derivative distributions — who are once again trying to dictate their own preferences onto the whole GNU/Linux community via their freedesktop.org propaganda machine. They’ve done it several times before — cfr. breaking the boot process if no initramfs is used, and also systemd-homed — and they usually don’t care that it breaks things.