Arch Linux

I'm not following you. Don't do what? Don't assign list of modules to MODULES as a string or don't assign list of modules to MODULES as array?

The first way worked well before 24 (before mkinitcpio switched to use arrays in /etc/mkinitcpio.conf), but now, according to mkinitcpio.conf comments the proper way is to set MODULES as an array. This is excerpt from /etc/mkinitcpio.conf:

# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(piix ide_disk reiserfs)


Or you mean "don't use this feature"? I thought this is the only way to put some modules in initramfs and make them available at earlier stage of kernel booting.

Sorry, I missed that they got converted to arrays in the last release

This is specific to systemd's use of MODULES in the config.

seems (more or less) this is my problem with systemd mkinitcpio hook and vfio modules

if use systemd as hook instead udev, the vfio modules in modules array (MODULES=(vfio vfio_iommu_type1 vfio_pci vfio_virqfd)) not load at boot, lead vfio_pci can't passtrought selected devices, or vfio_foo options defined into /etc/modprobe.d/vfio.config

└───╼ cat /etc/modprobe.d/vfio.conf
options vfio_pci ids=10de:17c2,10de:0fb0
options vfio_iommu_type1 allow_unsafe_interrupts=1

greetings

The workaround to this would be to just load the modules in your own /etc/modules-load.d fragment, rather than trying to shoehorn them into the initramfs.

talk with "PCI passthrough via OVMF" wiki writer

@falconindy (Dave Reisner): I use 'systemd' in HOOKS but didn't thought that it is relevant here. Does you comment that it is specific behavior mean this is a feature and I should use another approach to include some modules into initramfs? According to mkinitcpio(8) (if I read it correctly) the other way to include some modules into initramfs is to make custom install hook.

> Does you comment that it is specific behavior mean this is a feature and I should use another approach to include some modules into initramfs?
You misunderstand the scope of this bug. Inclusion of modules still works through the MODULES array in /etc/mkinitcpio.conf. What currently doesn't work is forcible loading of those modules in early userspace (something which isn't often needed).

@falconindy It seems to me that bug is specific to mkinitcpio behavior so pointing to /etc/modules-load.d doesn't make sense. As explained mkinitcpio.conf works against specified documentation when systemd hook is used instead of udev and that's the bug we're talking here.

When systemd hook is used in mkinitcpio.conf and modules section uses old syntax: MODULES="module1 module2", We have:

lsinitcpio -x initramfs-linux.img
cat etc/modules-load.d/MODULES.conf
module1
module2

When news syntax is used: MODULES=(module1 module2), we have:

lsinitcpio -x initramfs-linux.img
cat etc/modules-load.d/MODULES.conf
module1

> @falconindy It seems to me that bug is specific to mkinitcpio behavior so pointing to /etc/modules-load.d doesn't make sense.
Sure it does. I contend that many uses of MODULES in order to *forcibly* load modules in early userspace are misplaced (potentially based on cargo-cult/bad guidance from the wiki). You could just as effectively load them later. Hence my mention of /etc/modules-load.d.

Yeah but some modules are needed in initramfs, it depends on config and what we try to achieve. Anyway it's irrelevant to this bugreport. I don't think anyone is asking for guidance here. It's clear that incorrect behavior of mkinitcpio is legitimate concern.

@falconindy (Dave Reisner): I think this https://wiki.archlinux.org/index.php/Kernel_modules#Automatic_module_handling answers all my questions. So, if I understand correctly, the use of /etc/mkinitcpio.conf to load some modules is obsolete, it is for other purposes.

It seems to be fixed by https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd&id=c3000291672fd1bd55dcdd2b0917034e9a2e176a I confirmed it works.