[Bug 1876733] Re: GruB boot on full Ubuntu 20.04 LTS install tries to use efi on mbr partition

[Carl]

Dear Juhani,
Just jumped on email, saw bug bot wanting a specific package in edit for bug. Tried to go to edit site and got a permission error saying I wasn't allowed or some such pish-posh. I suppose since it was during the installation on a full install, it had to be in Gparted or the Grub Bootloader. My system crashed this AM for some Dbus error (still fighting pulseaudio and alsa... hardware hates the audio) and the report got sent to HQ with my email and Acer5250. Just so you know, I did not read your email yet, just back on here, so let me go read that... hang on..... Ok just assigned you to bug. Like I said, if you need the boot repair logs, just tell me what to scrub for privacy, and I'll send them where they need to go. Boot repair ran two logs, one on first run, then another after repairs of MBR.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1876733

Title:
  GruB boot on full Ubuntu 20.04 LTS install tries to use efi on mbr
  partition

Status in ubiquity package in Ubuntu:
  New

Bug description:
  Ubuntu 20.04 LTS on Acer 5250 laptop.

  Installed as a single operating system and told partition utility
  (Install Ubuntu) to claim entire hard drive on install.

  Install went well, but GruB was acting funny, loading the Grub Menu with a 30 Second Counter sometimes, then other times it would boot as normal.
  Decided to run Boot Repair and get report on drive boot. The program ran, but never reported what errors it found. It did find them, and prepared a set of reports, one upon install, the other after first run.

  The install utility partitioned the drive in three: 1 vfat(32), 2
  extended, 5 ext4. Using the vfat(32) as the boot sector, it wrote all
  the bootfiles and GruB to 1. It tried to use esp and efi bootfiles,
  but this device is a old style mbr boot BIOS. So Grub went into
  fallback mode.

  Boot repair did repair the issue, by reinstalling GruB and kernel to
  partition 3, setting the boot loader mode to mbr, and removing the efi
  loader and all boot related files from partition 1.

  It looks like from the error logs in Boot Repair, that the Ubuntu
  Installer "best guess" from the previous setup (before install had
  Win10 and Ubuntu Mate Dual-Boot) was that Win10 needed that vfat(32)
  partition for installing Win10 AFTER Ubuntu and made a place for the
  win10 bootfiles, then added Ubuntu boot and kernel to the vfat(32)
  partition.

  However, during the install, what ever probe system was installed in
  kernel or grub incorrectly setup Ubuntu to use the efi bootfiles in a
  mbr environment.

  If you need the boot repair logs I can send them, but need to know
  what to scrub from them before sending or adding here. Not a
  programmer, just advanced user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1876733/+subscriptions