I just installed Manjaro onto a new laptop that uses Intel VMD by default. The installer detects the drive and installs fine, but on first reboot it is unable to find the partition and fails to an emergency shell.
Some googling came up with the solution: adding vmd to MODULES in mkinitcpio.conf andregenerate.
Is this something the installer should/could do for the user if it detects VMD in use?
https://bugs.archlinux.org/task/68704
So does this task belong to the Manjaro installer or mkinitcpio?
It would be mkinitcpio.
The proposal there is to add a default hook for vmd.
In my opinion, the problem is that not all hardware needs such a hook.
I guess we can just keep an eye on whatever happens upstream. 
Boy did this bite me HARD right in the buttocks!
I nearly pulled out all of my hair installing Manjaro for a friend that has an Intel VMD drive, and after much stressing out and banging my head on the wall, did I discover that the vmd module is needed!
Nowhere during the Calamares setup did anything warn me about the drive selected for installation.
I absolutely believe the vmd module should be added if such a drive is detected.
In fact, a few extra defaults are dearly needed if such a drive is detected:
vmd added to MODULES in /etc/mkinicpio.conf
nvme_load=YES added to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub
Under /etc/mkinitcpio.conf HOOKS, block must come before autodetect. This is especially important for those using encryption.
After correcting the above three items, their system boots flawlessly now. (Prior to that, they could not boot no matter what we tried.)
So basically you guys are asking that mkinitcpio.conf and the boot loader default configuration should be customized depending on the hardware detected at installation time, right?
Hi @Chrysostomus, do you think the implementation of such a feature is feasible for Calamares?
PS. I usually donāt allow bumping old threads. However, since this is a limitation that has been around for a while, it would be nice to hear an opinion from the maintainer.
I think this would be crucial to protect the end-user experience, especially for āfirst-timersā. Such storage media is not uncommon for premium HP laptops.
I considered starting a new thread, but it would have been a duplicate of what @sour posted (and nothing has changed since June 2021.) I found this thread after solving the problem, to see if anyone else reported it here.
nvme_load=YES and the vmd MODULE would save much stress from users who have such hardware.
While itās not particular to this problem, placing block before autodetect (in HOOKS) can relieve some users who face odd issues during bootup of an encrypted system partition or with finicky storage devices.
I nearly gave up and thought perhaps that it was impossible to boot into a successful installation. After gnawing through Google, Reddit, and the Arch Linux BBS, I discovered the above (three items) that solved the boot issue. I assumed that if the installer did not complain about the Intel VMD storage then it means it should boot just fine. 
Lesson learned.
Possible maybe, but probably not feasible because of dearth of resources.
However, the suggested items do not seem like they would cause problems on other installations, so adjusting defaults to match those might be more simple? At worst that would add a few milliseconds of boot time for everyone.
Thanks for your feedback @Chrysostomus 
I took a closer look at the bug reports for other distributions (attached to the Arch bug report).
It seems that the other distros just added the vmd module in the dracut defaults file to fix that issue.
I wonder why Arch hasnāt added the module as default in the modules section of mkinitcpio.conf yet. 
Although Iām not affected by that issue, I will add the module to my default mkinitcpio configuraron to see if there is any impact.
I will report back once Iām done.
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. 
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.) 
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ā.
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ā 
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.
Is there any update on this? It appears this is becoming a common breaking point for new installations. 
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: