20.04 installation failure (grub error + boot repair failure)

[noob5000]

I recently installed 20.04 on a separate partition next to 18.04 (I want to try the new LTS before deleting the old one).

After installation, no booting possible. I tried reinstalling several times on different partition configurations, never worked. I tried the Boot Repair tool each time and fiddled with the BIOS but I still cannot understand the problem nor what to do (I have used Ubuntu for a decade but am at a loss here).

Here is the Boot Repair output from the last failed attempt --> http://paste.ubuntu.com/p/2sckpMdk7h/

Can you please help me figure out what to do to fix grub so I can use my PC again?

[oldfred]

You have newer UEFI based hardware. Probably because Microsoft has required vendors to install in UEFI boot mode to gpt partitioned drives since Windows 8 released in 2012.

But you show both an ESP - efi system partition for UEFI boot and now have mount of ESP in fstab for both installs.
But sda drive is the old MBR and still has a grub in MBR for BIOS boot which then will not work.
While Microsoft has required gpt, Ubuntu has allowed UEFI install to MBR (and probably should not).
I do not think they have changed to require gpt, but have seen another post with issues when trying to use MBR with UEFI.

Check that you have settings in UEFI to boot in UEFI mode but with Secure boot off. Do not boot in BIOS/CSM/legacy mode.
CSM - UEFI Compatibility Support Module (CSM), which emulates a BIOS mode
Settings in UEFI only are for installed systems. Boot mode of live installer from USB is a choice in the UEFI boot menu each time you boot live system.

It looks like your system should boot in UEFI mode.
But better to plan on conversion to gpt. Just conversion with gparted will erase drive, so good backups required.
You can use gdisk to convert in place, but total reinstall of grub required and maybe other changes such as fstab entries as UUIDs will change.

And sdb is gpt which is also required for all drives over 2TiB, but shows this:

sdb may have broken partition table.
Post this:
sudo gdisk -l /dev/sdb
repair gpt:
http://www.rodsbooks.com/gdisk/repairing.html
Converting to or from GPT - must have good backups.
http://www.rodsbooks.com/gdisk/mbr2gpt.html

[noob5000]

Thank you for your reply!


You have newer UEFI based hardware. Probably because Microsoft has required vendors to install in UEFI boot mode to gpt partitioned drives since Windows 8 released in 2012.

But you show both an ESP - efi system partition for UEFI boot and now have mount of ESP in fstab for both installs.
But sda drive is the old MBR and still has a grub in MBR for BIOS boot which then will not work.
While Microsoft has required gpt, Ubuntu has allowed UEFI install to MBR (and probably should not).
I do not think they have changed to require gpt, but have seen another post with issues when trying to use MBR with UEFI.
I understand maybe half of it, I will have to google some stuff (e.g. "gpt"). But I fear some of it might just be beyond my reach. For example, I do not comprehend the difference between UEFI and EFI even after googling it... My grasp is very limited, I only use Ubuntu with the graphic surface as a windows alternative, but am not versed in programming or linux architecture at all.



Check that you have settings in UEFI to boot in UEFI mode but with Secure boot off. Do not boot in BIOS/CSM/legacy mode.
CSM - UEFI Compatibility Support Module (CSM), which emulates a BIOS mode
I tried. The bios menu offers enable/disable/auto for Legacy USB. When I chose "disabled", NOTHING boots. I need to enable it to boot from live-USB to access the computer at all. Should it work in disabled mode, too, and is this perhaps a different or additional problem?



Settings in UEFI only are for installed systems. Boot mode of live installer from USB is a choice in the UEFI boot menu each time you boot live system.

Is the UEFI boot menu a boot menu with the same options as in grub, but with a slightly different design? Greyish instead of the strict black and white one on grub? I had that on the 18.04 install and was wondering about the different look after grub on the previous install some years ago.
When I boot from the live USB stick, I get no boot menu to choose from at all.



It looks like your system should boot in UEFI mode.
But better to plan on conversion to gpt.
I do not understand. gpt is "GUID Partition Table"? Is this not a part of every hdd?


Just conversion with gparted will erase drive, so good backups required.
I cannot backup the 18.04 install because some of the files cannot be copied............


You can use gdisk to convert in place, but total reinstall of grub required and maybe other changes such as fstab entries as UUIDs will change.
Convert what exactly? I dont understand :(
Both UEFI and non-UEFI boot methods boot from the harddisk, right? Do I need to convert the MBR (LBA0) of the hdd? (I looked on wikipedia, still dont understand tbh)



And sdb is gpt which is also required for all drives over 2TiB, but shows this: "sdb may have broken partition table. "

Is it possible at all to fix a broken partition table without entirely wiping the hdd?




Post this:
sudo gdisk -l /dev/sdb

Ok here:


GPT fdisk (gdisk) version 1.0.5

Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present

Creating new GPT entries in memory.
Disk /dev/sdb: 7814037168 sectors, 3.6 TiB
Model: WDC WD40EFRX-68N
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 1D0B63CA-B93A-45D3-B083-C34AA8E1C43D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 7814037101 sectors (3.6 TiB)

Number Start (sector) End (sector) Size Code Name
ok I see, MBR not present, GPT not present. I dont know what BSM and APM are but I take it all 4 are different ways to form a partition table.

I think I get it now - I will need to put a partition table on dev/sdb and you recommend the gpt method. I shall try to read through those links and report back with either success or failure.

[oldfred]

If drive is over 2TiB, you have to use gpt partitioning or you convert drive to 2TB as that is the largest MBR can be.

Lots, perhaps too much, info on UEFI in link below in my signature. At least skim read it and on things you do not know click on the links with more info. Also Acronyms at bottom of post expands things.

Intel developed EFI and Apple adopted it for it computers when it converted to Intel chips years ago. Then Intel turned it over and it became UEFI and EFI become UEFI v1. Microsoft required UEFI in 2012 with gpt partitioning.
From my link below:
Acronyms:
UEFI https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface
ESP/efi - Efi System Partition http://en.wikipedia.org/wiki/EFI_System_partition

[noob5000]

Thank you for the pointers!

I realized I gave the gdisk -l for the wrong harddrive because the 4 TB magnet drive listed above is meant only for data storage (which is why it has no boot section). the actual boot drive for linux to run on is a 120 GB SSD. I disconnect all but the intended system drive now.

gdisk -l for the ssd:


GPT fdisk (gdisk) version 1.0.5

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present


************************************************** *************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
************************************************** *************

Disk /dev/sda2: 1048576 sectors, 512.0 MiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 69EAE2B7-10CE-4215-9B96-0E4594D004C1
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1048542
Partitions will be aligned on 2048-sector boundaries
Total free space is 1048509 sectors (512.0 MiB)

Number Start (sector) End (sector) Size Code Name


Also, here is a screenshot of gnome disks showing the partition table...

287160

... because I wonder if this EFI partition type on the MBR could be why gdisk finds an "invalid GPT", and if the screwed up partitioning is also a factor in the boot failure? I know it is a mess, I tried to preserve the original 18.04 install (stored on partition 1) and moved that partition to the end of the partition table in order to free the space at the beginning of the table.

From what I think I understand of your massive "UEFI Installing - Tips" page and the Rod Smith texts (which are above my level of comprehension tbh) I need to convert the MBR on /dev/sda2 to GPT using a series of gdisk commands in a terminal with parameters pieced together from this list http://www.rodsbooks.com/gdisk/gdisk.html in order to
1. backup the existing MBR
2. convert the MBR data into a GPT structure
...something I have never done and dont half understand. I also dont understand why the 20.04 installer would make a mbr instead of a gpt in first place, unless this is perhaps dependent on the BIOS configuration. But if I disable USB legacy support, nothing at all boots (neither Boot Repair nor a Linux live USB...

Sorry if I am asking too much.

I also ran another few instances of Boot Repair to see if the results change. They did a little, but the last three instances all ran into the same problem and the pastebin output is identical. This is the latest instance: https://paste.ubuntu.com/p/Bn6K9SwxVw/

[noob5000]

In desparation I wiped the partitions aside from sda1 and installed 20.04 anew in the blank space. when trying to boot from the harddisk it gave the grub error:

file "/boot/grub/i386/pc/normal.mod" not found

(with a live session I checked on the harddisk, neither of the two partitions has the /boot/grub/i386-pc/ folder, only /boot/grub/x86_64-efi/)

I ran Boot Repair over it, and the end result is here: https://paste.ubuntu.com/p/qPVmhZ23J7/
(running it again has the same result: "Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes." and failure of the repair procedure from "Generating grub configuration file" on)

sudo gdisk -l /dev/sda2 result:


GPT fdisk (gdisk) version 1.0.5

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present


************************************************** *************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
************************************************** *************

Disk /dev/sda2: 1048576 sectors, 512.0 MiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): C13F1505-602D-4408-AE2B-1F99C41A3CBA
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1048542
Partitions will be aligned on 2048-sector boundaries
Total free space is 1048509 sectors (512.0 MiB)

Number Start (sector) End (sector) Size Code Name
...so I seem to be stuck with needing to convert the boot partition from mbr to gpt.

[oldfred]

Windows incorrectly converts a gpt drive to MBR. It leaves the backup gpt partition table.
Windows does not seem to care, but Linux sees backup gpt partition table at end of drive and only MBR at beginning of drive and gets confused.

The only time you now need MBR(msdos) is if you have to or insist on booting Windows in BIOS boot mode.
Windows also only boots in UEFI mode from gpt (since 2012).

GPT Advantages (older 2010 but still valid) see post#2 by srs5694:
http://ubuntuforums.org/showthread.php?t=1457901 &
https://wiki.archlinux.org/index.php/GUID_Partition_Table#Advantages_of_GPT
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
http://askubuntu.com/questions/629470/gpt-vs-mbr-why-not-mbr

I converted my first drive to gpt in 2010 for Ubuntu. Still has XP in BIOS/MBR boot mode.
Now all my drives except some I use on my old 2006 laptop (mostly retired) may be MBR for install. But I converted its drive to gpt also.

[CelticWarrior]

In the live session open GParted, select the drive and then Devices menu > New partition table... Select GPT.
Then, and only then, proceed to the installation.

It's not a matter of "boot partition" or conversion, it's a matter of partition table, something that is there before the partitions themselves.

[noob5000]

Ok thanks again for your help, but yesterday I had enough and simply gave up on preserving the old 18.04 and wiped the disk, then blank-installed 20.04. This time it worked, I have a functioning PC again, so i guess this thread is obsolete.