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