Installer needs to add vmd module to mkinitcpio - Testers Needed

The outcome of my test is below:

#  My initial mkinitcpio.conf
~ >>> cat /etc/mkinitcpio.conf | grep MODULES=; lsmod | grep vmd                                                                                                                                                    
MODULES=(i915 dm-mod)

#  Module added to mkinitcpio.conf
~ >>> cat /etc/mkinitcpio.conf | grep MODULES=; lsmod | grep vmd                                                                                                                                                    
MODULES=(i915 dm-mod vmd)
vmd                    20480  0

I was able to boot my system without issues. It’s just that the module does not get loaded as it doesn’t exist for my system.

I’d recommend more testing on different environments before adding this to the source code, but this might prove that just adding the module as default on mkinitcpio.conf would do the trick.

I have a desktop and netbook, both of which do not have Intel VMD. I can test it on both machines.

What would I be looking for, aside from boot time? (I don’t really “time” how fast my PC boots as it doesn’t really bother me if I have to wait an extra 1-2 seconds.)

UPDATE: My netbook is from 2012 with a slow Atom CPU and slow storage. So if anything will negatively affect it, I should be able to notice it more easily. :wink:

Me neither. I didn’t take into account boot time cause I didn’t see any sensitive delay. It might be a roadblock though, depending on the hardware.

Just applied the above 3 changes to my desktop PC. Noticed zero difference. Same boot speed, nothing unsual, no quirks.

Here is the output from lsmod | grep vmd:

vmd 16384 0

Apparently the “0” means it’s not being used by anything.

I’ll apply the same things to my netbook later when I get the chance.

Another user faced the same problem (new HP laptop), and the above steps solved it:

When I get the chance, I’m going to test it on my slow netbook. The results from my desktop PC showed zero difference in performance and bootup time.

I applied the above steps to my old 2012 netbook, and once again, no difference in boot time nor performance.

This is an Intel Atom CPU, with only 2GB of RAM, and a cheap MMC drive. Yet not even an iota of difference in performance nor boot time with all three steps applied (vmd, nvme_load=YES, and block before autodetect.) :ok_hand:

I’m going to keep the above changes permanent on both my desktop PC and netbook, out of principle, to sort of act as if they were the defaults from a fresh installation.

I tested it on kernel 5.10, 5.13, and 5.14.-rc.

Arch is a DIY Linux - and the user is supposed to know that they have a this special NVMe device.

I would suggest a patch to the relevant packages with a note about vmd.

Yes, you’re right. I’m afraid I worded that a bit poorly. I was meant to say “I’m wondering why Arch still has that bug report open”. :slightly_smiling_face:

They can just say: “Ok, you have the chance to add the vmd module into mkinitcpio.conf at the chroot stage of the installation process. Closing bug report” :sweat_smile:

Do you mean a kernel patch? If so, that would be interesting.

For me, adding defaults to mkinitcpio.conf makes sense. I agree with the idea of adding modules there if that helps to mitigate most outstanding issues.

Another case for that would be making EKMS a default by adding the i915 and amdgpu modules there (among others). That would help a lot preventing some graphics issues, especially on optimus laptops.

Now, if there’s a point on keeping mkinitcpio.conf pristine, I wouldn’t be against that. I don’t see it at the moment, though. I might be wrong here but I think Manjaro is forking that package anyway.

No - I was referring to a patch of the packages for mkinitcpio.conf and grub.

Call it a change if you like - but adding it as a patch clarifies it is a change to the default.

1 Like

Is there any update on this? It appears this is becoming a common breaking point for new installations. :frowning:

The latest victim is using an HP All-in-One, who once again got their newly installed system running after applying the above three changes.

So it’s not occurring only with laptops. It’s not pretty to have to walk users through booting into a live USB to make the corrections in a manjaro-chroot jail. (“First impressions” of Manjaro comes to mind, and the installation was supposedly “successful”, until they’re met with a jarring surprise when they reboot.)

As @linux-aarhus alluded, this would have to be a patch against /etc/mkinitcpio.conf and /etc/default/grub, since neither of those files are in Manjaro’s GitLab, yes?

This is not something that can be done by Calamares towards the end of the installation process?

I guess it can be added here for example. Maybe someone knows how to detect Intel RST, then it can be configured if available.

Well, there is already a pull request for adding the module on Arch’s project GitHub. No decision on that matter so far. See below:

This is a different approach from what I initially thought above. Eventually, if Arch rejects the pull request, then somebody should make a similar pull/merge request on Manjaro Gitlab in the form of a patch:

I had forgotten about it after telling the team about this I’ll see if I can get something done tomorrow


Please open a separate thread under Support → Installation and Boot, since your unique system might be facing a different issue and/or a combination of issues, plus we can review the steps you took. :bowing_man:

We can continue here: Discussion about vmd module inclusion (#1) · Issues · Packages / Core / mkinitcpio · GitLab


Tomorrows build [2021-09-21] should have the fix. Please test:

Any build:

Unstable only:


Tested with an existing installation on unstable branch. No Intel NVMe hardware.

  • Installed mkinitcpio v. 30-3
  • Re-generated initramfs
  • Rebooted

As a result, the module is not even listed with a simple lsmod command.

~ >>> sudo pacman -Qi mkinitcpio | grep 'Version'; sudo lsmod | grep vmd                                                                                                                                            
Version         : 30-3

However, the directive that adds the vmd module exists under the path below on the block hook file:

>>> pwd; grep 'vmd' block                                                                                                                                                                 
    add_checked_modules 'vmd'

I know my test is not representative and probably any existing working installations won’t be either.

I guess the actual test to figure out if the issue gets resolved would be on new installations involving the affected NVMe hardware using the development images above.

1 Like

I can confirm a fresh install works on an ASUS Zenbook with vmd. Prior images had UUID errors the same as HP hardware.


21.1.4 stable ISOs should also ship now with this fix.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.