On Tuesday, 24 July 2018 15:38:35 BST Mick wrote:
> On Tuesday, 24 July 2018 15:14:32 BST Philip Webb wrote:
> > 180723 Neil Bothwick wrote:
> > > On Fri, 20 Jul 2018 09:04:26 -0400, Philip Webb wrote:
> > >> Linux Mint 19 leads you along to a point where you've told it
> > >> where to install, you click 'proceed' & it chugs along nicely,
> > >> then it says it's trying to install a bootloader
> > >> without asking whether you want it to or where to do it.
> > > 
> > > For future reference, start the Mint installer with "ubiquity -b",
> > > then it doesn't install a boot loader at all
> > > and you can add it to your Gentoo bootloader after rebooting.
> > 
> > I started the Mint installer by clicking on its desktop button.
> > What is 'ubiquity' & how would I use it ?
> > 
> > > WinErr 018: Unrecoverable error - System has been destroyed.
> > > Buy a new one. Old Windows licence is not valid anymore.
> > 
> > That's how I felt for  30 min  after Mint played its dirty trick above
> > (grin).
> 
> See attached screenshot.
> 
> Meanwhile I'm still at a loss why on a BIOS with GPT system GRUB installed
> fine without any mishaps, but upon a GRUB update some days later it refused
> to install without me creating a new protective MBR partition marked as
> ef02.
> :-/

I just noticed when I start the VM using the aqemu GUI, the  system identifies 
its virtual hard drives as /dev/sda, while when I start it with qemu-system-
x86_64 on the CLI it identifies the hard drives as /dev/vda.  This is the 
reason of GRUB refusing to update itself ... I installed with aqemu, then some 
days later I tried to update GRUB running the VM via the CLI.

So much for thinking aqemu is a just a simple GUI for running qemu VMs.  It 
evidently does its own tha'ng.
-- 
Regards,
Mick