On Wed, May 29, 2019 at 7:01 PM CLOSE Dave
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.