Re: [gentoo-user] [OT] MBR + GPT + GRUB
180721 Mick wrote: > On Saturday, 21 July 2018 19:47:25 BST Jack wrote: >> Are you sure this wasn't fallout from the recent grub problems >> in the Mint ISO : https://blog.linuxmint.com/?p=3620 ? >> 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. > I posted this blog entry on another thread, but the GRUB problem > described there breaks EFI installations when the live session > is connected to the Internet. There were 2 different issues re Mint + Grub, the one above & my own gruesome half-hour after the installer for Mint 19 overwrote my MBR without warning & forced me to use System Rescue, fiddle with some files & run Lilo to restore the MBR to what it sb. All is well with the new Mint 19 now, but there is no simple way to send a bug report to the Mint developers. Well, not quite all : Mint suggests the new user update some pkgs, but when you say "ok", it pokes around, then says it can't connect to its repositories. Gentoo has its irritating features -- Portage output 1st among them -- , but a few brief hours with Mint reminds me how much better it is than all those pre-cooked binary distros which are the alternative. And all of them are far better than trying to live in the Microsoft Motel. (smile for now) -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] [OT] MBR + GPT + GRUB
On Saturday, 21 July 2018 19:47:25 BST Jack wrote: > 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 Thanks Jack, I posted this blog entry on another thread, but the GRUB problem described there breaks EFI installations when the live session is connected to the Internet. Mine installed fine at the time. So, I don't think the blog entry is related to my case above. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] MBR + GPT + GRUB
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
[gentoo-user] [OT] MBR + GPT + GRUB
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? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
