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.
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.
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.
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?
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:
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.
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.