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

[Carl]

Never mind what I wrote. I was seeing so many differences in the boot
load that I went ahead and wiped the drive clean, set the zero fill
option, reset the MBR and reformatted as ext4. Grab the up to date ISO,
and re-installed 20.04 LTS. I let the install run as a normal full
install, and the partitions that completed were as first noticed. sda1
vfat, sda2 extended, sda5 ext4. So that IS the default installer
locations. Had never seen that arrangement on Ubuntu ever, so I assumed
the arrangement were based on a previous Win10 partition. I was
incorrect and apologize for the bug tracker. I guess the real answer
here is to not run boot repair on a new install, as it will put the boot
files in the wrong place and effect booting. In closing, as stated above
"the reporter is confused".

Can we know why this partition arrangement was needed?

** Changed in: ubiquity (Ubuntu)
       Status: New => Invalid

** Converted to question:
   https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/690540

-- 
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:
  Invalid

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