On 2018.07.21 13:46, Mick wrote:
Hi All,
A slightly off-topic question arising from a different distro, which
may
replicate itself on Gentoo.
I installed Mint-Linux, in a VM. The host PC MoBo has a legacy BIOS
system.
I used a GPT scheme to create partitions on the virtual disk. The
first 1M on
the virtual disk was left empty by gdisk. I thought GRUB can use
this for its
core image. Note, I did not create a partition in this 1MB empty
space at the
start of the disk.
While running the Mint Installer I got a warning from its partition
manager
telling me I had not specified a BIOS_grub partition and the
installation may
fail. I ignored the warning and continued with the installation,
which
completed successfully.
A few weeks later I ran an update which among other packages updated
grub2-
common. An ncurses menu popped up warning me:
"The GRUB boot loaders was previously installed to a disk that is no
longer
present, or whose unique identifier has changed for some reason".
It offered to install in /dev/vda, /dev/vda1, or /dev/vda2. I
selected /dev/
vda which represents the virtual disk. It failed to install in
/dev/vda
because the device did not contain a BIOS_grub partition.
I tried 'grub-install --force' and --boot-directory options, but in
all cases
it failed to install. At the end I had to create a new 1M partition
with
gdisk and set its type to ef02 (BIOS boot partition), before grub
would
install its core image successfully.
QUESTIONS:
Why/how the initial installation succeeded without an ef02 partition,
but a
grub package update would not proceed without it? Where did the Mint
installer store the grub core image to be able to continue with the
installation?
Are you sure this wasn't fallout from the recent grub problems in the
Mint ISO? (https://blog.linuxmint.com/?p=3620) I thought I got the
link to that on this list, but I can't find the relevant message, so
I'm not sure where I saw it. However, it seems like the issue was that
installing Mint messed up Grub and left the PC unbootable.
Jack
