On Wed, May 29, 2019 at 7:01 PM CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
I have upgraded three VMware images previously running Fedora 29 to Fedora 30 using system-upgrade. All the images are running on the same ESC hardware and, so far as I know, use the same VMware foundation. The first worked flawlessly. Both the second and third failed in exactly the same way: they failed to reboot successfully after the upgrade.
When the reboot occurred, VMware reported a "alloc magic" error immediately and froze. Not being a VMware expert, I referred the issue to someone who is and he discovered that the MBR, master boot record, on the image was corrupt. After installing a new MBR, the system booted and the upgrade showed no further problems.
Not sure what would corrupt it but there is competition for LBA 0, the MBR, in that there's a bootloader portion in the first ~440 bytes and then a partition table from that point until the 512th byte. So whenever something changes a partition or a boot flag (active bit) or bootloader jump code, there's a risk. This was such a well known problem it directly affected GPT. For one, don't use LBA 0. Two, make two copies in two totally different locations. Three, checksum everything. Four, give the bootloader its own home, no sharing.
While investigating, we were sidetracked by the content of grub.cfg. It appears that grub no longer includes a section for each possible system to be booted. Not seeing any, we thought grub.cfg was corrupt also. But that is apparently not the case. After the MBR fix, the generated grub.cfg works properly.
Normal behavior, new feature. https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault