Such thing does not exist. You were requested one time password to enroll the generated certificate in MOK, to enable successful verification of kernel modules signed by the corresponding key. If you did not
(which BTW was shown by the MokManager) most likely your VirtualBox modules would have been successfully loaded.
is an incorrect way to put it.
As explained above, unsigned modules like Nvidia drivers and virtual drivers and stuff for Virtualbox, are prevented from loading by Secure Boot. Users can - and must if they want to keep Secure Boot enabled - manually sign those modules to authorize them for Secure Boot. Thatâs what the password is for, thereâs no mystery, no additional layer of stuff, nothing, it simply is how the system works. Youâre making a mountain out of a molehill.
Not sure about that in light of kernel lockdown, see my link above.
Iâll say, do your friends and customers a solid and (tell them how to) generate and enroll a new MOK, so they can take advantage of the full SB experience, if they want it. Disabling it is totally fine, but that should be predicated on an informed decision by the actual user of the machine.
Simply running dpkg-reconfigure -plow dkms might do it, but I cannot say for certain. Existing DKMS modules may need to be signed with the new MOK as well, but that can probably be done by forcing a rebuild of all of them.
Kernel lockdown (as implemented by downstream patches in some distributions) prevents loading of unsigned (and signed by untrusted keys) kernel modules if Secure Boot is active. Trusted keys include build time key (for which certificate is embedded in the kernel) and keys corresponding to the certificates in the UEFI db and MOK. If the certificate had been imported in MOK, modules verification should have been successful.
But it wasnât, which is why the screen stayed black. The VB modules never figured, because those only load, once they are used. I donât know, if they are even required for anything on a bare metal machine, but they might get installed regardless, in case the machine gets migrated to a VM. But, then again, itâs been a minute since Iâve last used VB, so donât nail me on that. 
The SecureBoot password is not tied to a specific user on the Linux systemâŠ. therefor I see it that it is a password for the entire system.
About making a mountain out of a molehill⊠Letâs play out a scenarioâŠ
I as a consultant set a password âSnuffleupagusâ for SecureBoot.
I tell the client what it is.
Since they do not need to use the âSnuffleupagusâ password on a regular basis, it slips their mind.
Some Ubuntu update comes along, asks for the SecureBoot password. WHAM!!!
My consulting style to my clients is to âwork myself out of a jobâ. Clients having to contact me to inquire what I set the SecureBoot passoword to when I set up the machine for them does NOT further that goal.
Earlier this year, one of my Linux clients was suddenly back in touch with me. Nine years prior, I had reloaded their used home Windows computer to Xubuntu Linux. I recommended and took care of upgrading the RAM in the system, and installed an Nvidia graphics card. That system worked flawlessly for the nine years. It went through multiple LTS upgrades on its own.
Finally the Nvidia drivers had somehow gotten uninstalled. They had also managed to get screen magnification enabled⊠resulting in a 320 x 240 screen resolution. I offered to swing by and consult to heal the computer. Client agreed, I ended up visiting on Saint Valentines day of all days.
I purged off the excess of built up unused Kernel packages, got the Nvidia binary drivers loaded again, found the spot to switch off resolution magnification in XFCE, IPLâed off of the LiveDVD to run xfs_repair on the HDD. I told them âSee you in another 10 years!â
This client was near retirement nine years ago. They operate on retirement savings. They need their funds stretched. I reminded him of his hesitation of investing in the hardware upgrades to the used computer (RAM and Nvidia board) nine years priorâŠ. added that the capital investment made possible the nine years of successful use of the computer.
They thought the two hour consulting charge for nine years of successful use of the computer was a very reasonable expense, which he quickly paid.
I never want to burden clients such as this with needing to remember an additional password they only seldom need for burping SecureBoot.
I am thankful,
One final note, it must be said that using DKMS modules on an unencrypted device is a huge backdoor risk, for anyone with physical access can just extract the private part of the MOK from DKMSâs configuration data[1]. Thatâs another major downside of out-of-tree kernel modules. But it can be nullified by disk encryption.
On an untainted system, i.e. powered only by software signed by Canonical, including, but not limited to, the kernel and itâs in-tree modules, no such risk exists, because the private key is kept secret in Canonicalâs âVaultâ and the public one is signed by Microsoft, so the chain of trust is unbroken.
if DKMS doesnât ask for a password to unlock the private key at module build time, anyone can read it, for it must be stored in plaintext somewhere â©ïž
The SecureBoot password is never re-asked and expected to be the same as previously set at one time in the past? I thought it would be, and likely lost or forgotten by then.
What is so hard for my friend that:
SecureBoot is disabled in the Dell BIOS
System IPLâed successfully after doing so
Grub menu miraculously returned!
System does not prompt for a SecureBoot password
VirtualBox package was able to complete installing, starts a VM ported from the prior computer.
I was concerned in setting a SecureBoot password that likely will be forgotten since it is not routinely asked for by the system.
This in-fighting within the Linux community is wearisome.
I suppose I would also be under attack for choosing the XFS file system for the past 22 years of consulting with Linux. The fact that systems benefit from xfs_repair being periodically run off of an alternate boot media might be one gasp point of others in the Linux community.
And, and, andâŠ
I see a client having successfully avoided expense for nine years of computing being accomplished as an achievement not to shrug off. Nine years of not paying any tax to Micro$oft. 
âIt is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.â
Theodore Roosevelt
Except from: âCitizenship in a Republicâ speech given by Theodore Roosevelt at the Sorbonne in Paris, France, on April 23, 1910
Considering that this topic was marked as solved, I think we can safely view this discussion closed.
Thanks to all those who participated.
Any further discussions should be taken to the Lounge, which is the proper place for more general conversations.
Closed.