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

[Carl]

Had some time to try to reinstall Grub and Boot files today with the
assistance of Boot Repair as a guide, but following the Grub directions
in Ubuntu on the terminal (not Boot Repair).

When using Boot Repair Advanced Menu (After program launch and probe for
setup) I noticed on my system that the program is interpreting my Bios
(Insyde EFI) as a valid UEFI BIOS when it is not. The dmicode utility
shows its name as "EFI" but the system as a standard (Old School) MBR
and BIOS. In the BIOS Menu, there is no mention of Secure Boot, TPM,
UEFI vs. Legacy, etc.

Using Grub in MBR/BIOS mode, and turning off Secure Boot and EFI
settings in Grub using Boot Repair as a guide (but following the
directions in Ubuntu/Grub ONLY) I directed the Grub to install itself
back on sda, and to include all relative locations (sda1-vfat-boot, sda5
-extended-ext4-ubuntu20.04LTS)where grub may be needed to boot.

After reload, grub determined, based on BIOS/MBR settings that the
sda1-vfat partition did not need a copy of Grub (even though the
directions in Ubuntu said to be safe and select all partitions that may
boot Grub) and placed all the boot data into sda5 where Ubuntu lives on
the hard drive. I verified the sda1 partition in sudo file manager
level. No files were loaded on the vfat (sda1) at all, but I am sure
that Grub knows it is there now.

So to be clear, I had to direct Grub to NOT USE UEFI/Secure Boot. It
sees the name of the BIOS as Insyde EFI and thinks it is UEFI. Wrong
Answer. Everything is OK now. I guess I could load Windows 10 but my
hardware is not really ready for Win10 2004, so I am not really thrilled
with the new OS upgrade from MS. (So we are clear, I do not like TPM,
Secure Boot is eh, OK, but can be difficult to manage, and if chip-
independent device, you can easily brick your device chip by playing
around with it, even the OEM has to be careful, so God help us users. No
tools to manage=don't mess with it!

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