Dracut kernel installation

I’m working on an EndeavourOS ARM installer image for Snapdragon X devices. Currently, my custom kernel package relies on mkinitcpio, but, apparently, it is wasn’t playing nicely with installation using Calamares. However, kernel-install-for-dracut doesn’t seem to work in chroot (which is kind of necessary for creating a bootable image), so no initramfs was ever created.
I’m using arch-image-builder, custom packages are available in the x1e-alarm repo.

The initramfs creation fails with the following error:

(4/7) Running kernel-install...
Running kernel-install for 6.11.0-rc6-3-x1e-g1e503208bf0f
Failed to load machine ID from /etc/machine-id: Structure needs cleaning
Running in a chroot, skipping cmdline generation
(5/7) Updating linux-x1e initcpios...
call to execv failed (No such file or directory)
error: command failed to execute correctly
(6/7) Refreshing PackageKit...
Error connecting: Could not connect: No such file or directory
error: command failed to execute correctly

Error 5 is expected (as this hook runs mkinitcpio which is missing`), but 4 and 6 make no sense. Is my kernel package missing something to make it build initramfs? Note that a very specific set of kernel arguments is required for USB boot and it actually differs from normal NVMe boot.

If I chroot into the image afterwards and run

dracut --force --kver 6.11.0-rc6-3-x1e-g1e503208bf0f

It will create initramfs just fine, however, as one might imagine, this isn’t a solution.

There are a few other problems with dracut compared to mkinitcpio:

  1. It is much slower (~10 times slower)
  2. It produces much bigger ramdisks (~3 times as big).

Why was it even decided to switch to it given these obvious drawbacks?

The installer on x86 inhibits the mkintcpio hooks. kernel-install works fine in a chroot as long as you properly set /etc/kernel/cmdline which the installer would normally be doing.

This is informational. It is just letting you know it isn’t permanently writing an /etc/kernel/cmdline because that would yield incorrect behavior when running in a chroot.

Because those issues don’t exist on x86. It can be bigger if you use nvidia because it pulls in the drivers but is otherwise comparable in size. It is also comparable in speed.

What are you seeing seems abnormal. Is perhaps something timing out causing the slowness?

That being said, there is no reason you can’t use mkinitcpio if that is your preference, just don’t use the eos_bootloader module.

Well, I have nothing against this since I set the correct cmdline there, but dracut isn’t being run at all.
And (once I boot the image and reinstall the kernel) kernel-install script makes dracut completely ignore parts of the config file (i.e. output file name) which is bad.

Doubt. Wasn’t this “no initramfs created” intended?

EDIT: link fixed

Well, I wouldn’t expect to see nvidia drivers on Arm. However, it’s definitely bigger (1886 vs 421 files).

That is intentional. kernel-install writes the kernel and the initrams into /efi. It doesn’t keep them in /boot. If you want something different then you can just not use kernel-install-for-dracut.

That only happens if /etc/machineid exists but is empty which should never be the case.

I have never run it on snapdragon hardware so I can’t comment on why it is bigger there. You would have look and see what is being brought in.

Again, if you prefer to use mkinitcpio, there is no reason you can’t do that. EndeavourOS ARM also uses mkinitcpio due to some of the kernel packaging on ARM.

Keep in mind that our Calamares config is intended to be used with the files on our ISO. Since your ISO will have differences, you will need to adjust the config.

Well, apparently, it exists and is empty.

lsinitrd mkinitcpio.img
lsinitrd dracut.img
Some firmware files are not (yet) present in the first one, but other than that (which is expected) there are many more files in initramfs generated by dracut.

The end goal is to not have my own ISO (right now I don’t even have one, but rather a disk image since persistence allows for more flexibility, i.e. not having to rebuild the image just to make small changes), but rather an official one.

Well, in such case I’ll need another module to create bootloader configs, so it’ll probably have to be create in the calamares repo along with arm configs.

The bootloader module is what creates the bootloader configs, not the eos_bootloader module.