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