1 |
On Tuesday, 24 July 2018 15:38:35 BST Mick wrote: |
2 |
> On Tuesday, 24 July 2018 15:14:32 BST Philip Webb wrote: |
3 |
> > 180723 Neil Bothwick wrote: |
4 |
> > > On Fri, 20 Jul 2018 09:04:26 -0400, Philip Webb wrote: |
5 |
> > >> Linux Mint 19 leads you along to a point where you've told it |
6 |
> > >> where to install, you click 'proceed' & it chugs along nicely, |
7 |
> > >> then it says it's trying to install a bootloader |
8 |
> > >> without asking whether you want it to or where to do it. |
9 |
> > > |
10 |
> > > For future reference, start the Mint installer with "ubiquity -b", |
11 |
> > > then it doesn't install a boot loader at all |
12 |
> > > and you can add it to your Gentoo bootloader after rebooting. |
13 |
> > |
14 |
> > I started the Mint installer by clicking on its desktop button. |
15 |
> > What is 'ubiquity' & how would I use it ? |
16 |
> > |
17 |
> > > WinErr 018: Unrecoverable error - System has been destroyed. |
18 |
> > > Buy a new one. Old Windows licence is not valid anymore. |
19 |
> > |
20 |
> > That's how I felt for 30 min after Mint played its dirty trick above |
21 |
> > (grin). |
22 |
> |
23 |
> See attached screenshot. |
24 |
> |
25 |
> Meanwhile I'm still at a loss why on a BIOS with GPT system GRUB installed |
26 |
> fine without any mishaps, but upon a GRUB update some days later it refused |
27 |
> to install without me creating a new protective MBR partition marked as |
28 |
> ef02. |
29 |
> :-/ |
30 |
|
31 |
I just noticed when I start the VM using the aqemu GUI, the system identifies |
32 |
its virtual hard drives as /dev/sda, while when I start it with qemu-system- |
33 |
x86_64 on the CLI it identifies the hard drives as /dev/vda. This is the |
34 |
reason of GRUB refusing to update itself ... I installed with aqemu, then some |
35 |
days later I tried to update GRUB running the VM via the CLI. |
36 |
|
37 |
So much for thinking aqemu is a just a simple GUI for running qemu VMs. It |
38 |
evidently does its own tha'ng. |
39 |
-- |
40 |
Regards, |
41 |
Mick |