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

[Carl]

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.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1876733/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Carl (cfitz347)]

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.

[Carl (cfitz347)]

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!

[Carl (cfitz347)]

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?