Init (runit) fails when booting with initramfs (solved)

22 September 2022, 04:57:56

I'm having what seems to me a strange problem at boot. Someone on the reddit sub for Artix was having what I think is probably a similar problem --link-- but there's no solution posted there. I shared my experience there was well, so I apologize for any duplication.

I'm dual booting Artix and Gentoo, with the zen kernel for Artix and a custom compiled kernel for Gentoo. The two share an efi boot partition containing both kernels. I have so far been using efibootmgr directly to create efi boot entries for them, and they were both working for months.

However, Artix suddenly stopped booting with the zen kernel. I get errors roughly like this at boot:

Code: [Select]

Failed to execute /init (error -2)
Kernel panic - not syncing: No working init found
...
Kernel offset ...

It also said something suggesting adding an init= line to the kernel options. I tried that (I'm using runit as my init system), and instead it would just say /sbin/runit-init or /usr/bin/runit-init failed with the same -2 error and kernel panic.

But here's something weird. At some point months ago just for fun I added an EFI boot entry to load Artix using the kernel compiled for Gentoo. (I was just testing if it was any faster. It wasn't.) That entry still works and boots me into Artix, runit and all.

The difference seems to be that the Gentoo kernel doesn't need a init ramdisk to boot; there's no initrd=... in its kernel options. Somehow this allows it to work, even with the same runit installation failing with the zen kernel.

I've tried some other kernels from Artix: the regular linux package, linux-lts, (also a couple from the AUR). I also tried downgrading to older versions of the zen kernel I had in my pacman cache, which I thought had worked OK to boot (though it has been awhile since I last rebooted and didn't have that big a cache). All yield the same result as the zen kernel. It doesn't seem to be the kernel. It seems rather to be any loading of the kernel that requires an initramfs.

To make sure it wasn't the efibootmgr commands I was using, I also installed grub. When I use that, the boot hangs at "Loading initial ramdisk".

I tried rerunning mkinitcpio with various options. No luck. I also installed dracut to see if the initramfs it creates worked any better than mkinitcpio's, but it doesn't seem to be any different.

The other person on reddit is using openrc rather than runit and had been using grub from the start, but is also hung on loading the ramdisk. Also, since runit works with the Gentoo kernel, I doubt it's runit specific.

But I frankly don't have a clue what's going on.

Re: Init (runit) fails when booting with initramfs

Reply #1 – 22 September 2022, 06:49:03

UEFI? If so, might be worth to check efibootmgr and the Artix entries. Especially if you updated Grub from Artix and it's the grub controlling both Gentoo and Artix.

I'm not sure exactly, but in some instances the newer grub packages would add a efibootmgr entry and have to be manually adjusted.

Just a hunch, can't say for sure. But would be good to rule out, as it was one of the common grub issues after those 3-4 builds came out in that week..

Re: Init (runit) fails when booting with initramfs

Reply #2 – 22 September 2022, 09:50:42

Since you're booting the kernels without any bootloader, have you tried making a Unified Kernel Image?

Re: Init (runit) fails when booting with initramfs (solved)

Reply #3 – 23 September 2022, 01:37:18

Thanks for the replies.

I've been able to solve it due to the feedback in the reddit thread. It turns out it was due to a missing /usr/lib64 symlink, and some other files which I was able to restore by reinstalling the filesystem package.

I suspect this was the result of a bad decision I made when I was faced with a file conflict for the assimp package: the same one reported in this forum post here. pacman was telling me certain files including /usr/lib64 and some files underneath it already existed in the file system when updating assimp, but the files in question were reported by pacman -Qo as already owned by assimp, so I thought it was safe to force through the update, but that seems to have borked things somehow.

Anyway, booting with the initramfs works fine again now.

I never got around to trying a Unified Kernel Image, but that shouldn't be necessary for the Artix kernels. They should be bootable directly. The issue was not related specifically to grub; as I mentioned I wasn't even using grub to begin with (and am not using it now). I just tried grub in case I was using efibootmgr wrong somehow, but the problem wasn't efibootmgr or how I was using it, but that the libraries needed for the intramfs couldn't be found by the kernel, or so it seems.