As I understand it, what seemed to be specific to Red Hat and CentOS distributions seems to also be happening on Ubuntu and Debian systems, as well. So…don’t upgrade your kernel and grub until the upstream vendors sort out the issue.
I know Virtualmin offers to update any available packages, but it’s not us recommending you do so, it’s just Virtualmin informing you about available updates (and normally we do recommend you stay on top of updates for security reasons…sometimes updates break things, though rarely this badly, but the risk of not updating regularly is usually much higher). But, please stop blaming us. We didn’t break your system, your OS provider did. (But don’t blame them, either, they were trying to protect you from a serious security bug.)
UPDATE 8/15/20: I’m reasonably confident this has been fixed everywhere. I’ve done numerous upgrades spread across CentOS and Ubuntu versions (and Fedora, though that doesn’t matter for most Virtualmin users) using UEFI boots and they’ve been working fine for the past week. I don’t have links to changelogs, but I’m sure more documentation exists. I think it’s safe to just assume this whole sordid episode is behind us and get back to regularly updating our systems as though it were a religion.
debian/postinst.in: Avoid calling grub-install on upgrade of the grub-pc
package, since we cannot be certain that it will install to the correct
disk and a grub-install failure will render the system unbootable.
LP: #1889556.
I believe it has been fixed upstream, but I’d like to see confirmation of that from the OS vendors to be sure. I know I saw a news item a day or two ago saying it was fixed for CentOS/RHEL, so it is probably fixed everywhere…but, maybe check with your OS vendor.
I went through this, but I ALWAYS do a AWS Snapshot back up prior to ANY server level updates. No exceptions. It’s just a given that I do this and IMO, good practice for recovery reasons.
This definitely saved me on this one, reverted back and all is/was good.
