I’m sorry for posting this at all, I feel like I should have been able to figure it out by now. I did a fresh install with a manjaro liveusb I had floating around from ~last year on an old Dell laptop my workplace gave to me because it was obsolete for them. 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. From reading more recent posts about similar problems it appears that this is now considered “old school”, and is likely the source of my issue.
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) I’ve tried a few different grub repair tools but none of them seem to work, and I think I’m just missing a fundamental step in the repair process due to being an old scatterbrain.
Would someone mind pointing me at the correct repair process that’ll actually get grub to change its ways?
If you are on EFI then yes, this is wrong.
An EFI setup looks like this:
-/boot/efi - 300 mib
-/ - everything else
In the simplest form.*
But if it were wrong then it wouldnt boot the once.
This usually happens if someone tries to keep running an EOL kernel.
So maybe instead your issue arises from this.
I would probably tell you to just use a modern ISO in the first place.
* - Technically even this is no longer the recommended way (/efi is preferred over /boot/efi), but Calamares installer doesnt know that yet and I didnt want to be any more confusing. Neither is 300mib required but Calamares will (incorrectly) complain otherwise.
If you absolutely must use the older ISO then its up to you to be careful about the upgrade and also make sure to clean up such as by removing deprecated packages, et al.
Before or during your upgrades make sure to install linux66 and/or linux612 - the 2 latest LTS kernels.
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.
There are only three scenarios in which you would come across the error that vmlinuz cannot be found.
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;
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 /bootdirectory, but not on the filesystem that would normally be mounted there; or
The kernel you were trying to update is EOL and is no longer provided by the update process.
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…
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
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.
I also run it happily on multiple installs for years without issue.
If you have some sort of ~political~ or ~philosophical~ reason for categorizing it as ‘systemd dictatorial overreach’ or whatever then do you … but the longer some of these things are repeated without continued knowledge upkeep the larger risk of sounding out of touch and/or underinformed.
Like this.
Though this has nothing to do with time … this was never true.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 254:0 0 27G 0 disk [SWAP]
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /efi
[...]
Mine I kept at 260 kuz thats how it already was … but smaller would be fine too.
This is a multiboot system and its only using about 16 mb of the ESP.
Calamares will complain if its under 300 mib - actually act as if there is no ESP at all - but these warnings are both incorrect and can be ignored.
I actually appreciate them pointing out the parts of the system that are tethered to systemd; I’ve wasted many dozens of hours getting around Lennart’s codswallop and this was a good reminder that I should maybe look into setting up a SysVinit system instead. I was using Arch when they did the changeover and I never agreed with their logic at the time, and I can’t say my position has changed. Bit of an additional headache, unfortunately.
Then you will need to choose from the ever-diminishing list of anti-systemd distros like Devuan.
(No, Manjaro cannot be made to run without systemd. Not unless thats a passion project you want to undertake as a crazed developer.)
You may think of me whatever you like — such is your prerogative — but I have been in the GNU/Linux (and generic UNIX) circuit for much longer than you have, and as such, I have been a witness to all of the whims and arrogance of Lennart Pöttering and the freedesktop.org propaganda machine. I know what I’m talking about.
By the way, one of the two referential links in what you quoted from the Arch Wiki points at the systemd development page at GitHub. The other one points at the UAPI group, from which I quote…
In other words, it is once again explicitly required by systemd because of their own recommendation that the ESP should be mounted by way of autofs — which is not necessary.
I have my ESP mounted full-time, but read-only, and I only ever need to remount it read-write manually when it needs being written to, such as when updating the grub installation itself, as opposed to updating /boot/grub/grub.cfg.
But of course, the systemd developers would rather have everyone using systemd-boot than grub, and that’s a whole other type of boot loader.
It used to be that calamares refused to continue the installation if the ESP was smaller than 300 MiB, and that is why I recommended to make it 300 MiB. If calamares now only complains anymore but still allows finishing up the installation, then that’s an improvement.
As @cscs pointed out, Manjaro now no longer supports alternative init systems. In the past, openrc was also supported, but this support was dropped, possibly because of a lack of someone maintaining it.
As an init system, systemd actually works quite well, and some of our members prefer systemd-boot instead of grub, but systemd — or rather, its developers’ ambition — attempts to usurp too much of the GNU/Linux ecosystem, such as with systemd-homed, which offers a solution to a problem that didn’t even exist yet. Luckily systemd is quite modular, so one doesn’t have to use the components one doesn’t like.
I didnt make any statements about what I think of you - I said what it might look like to repeat certain things ad infinitum.
But do go on. “Pulling rank” is … an approach.
Er, are we reading the same thing?
It doesnt say that - it merely gives systemd as an example of one of the implementations in which the point is true.
Its neither required by systemd, nor is systemd required for /efi to work.
Furthermore it presents other points as to why /boot/efi is not recommended.
Such as “Mounting the two partitions via autofs is recommended because the simple VFAT file system has weak data integrity properties and should remain unmounted whenever possible.)”.
Thats fine for you.
But it should be obvious why its also not the standard setup for consumer desktops - no default logic exists, and most newbies are not going to remember to do this themselves, to remount this space whenver something like update-grub would be needed/used.
I think it may be worth stressing here that I think both mount points are valid … but I see more reason to agree with the Archwiki than to ignore it. Folks can and should make their own decision.
And I see no reason for anyone (ie: you) to act so hostilely to the mere mention of one or the other.
I have repeated what I use and what is recommended by Arch (GNU/systemd/)Linux.
No idea how this even appears to be related.
Mostly agreed - except one needs to know or actively ignore the dialogs … kuz it very much screams to the effect of “this will not boot - there is no ESP”.
