GRUB partition gone forever, how to install new one?

Support
,
1

Hello Guys, I think that for unknown reasons (I don’t think was my fault since I didn’t touch anything related to this, but if I am a noob who knows) my GRUB Partition is GONE forever. How to Install from scratch a new GRUB partition?
I am using a Usb Live and looking in GParted and thunar live there are still all my partitions and file, I have a dual boot between WIN10 and Manjaro
(I cannot even manually log in the partition if I open computer and press f12)

WIN10: (OS /dev/sda2 ; NTFS reserved for the WIN system 500 mb /dev/sda1)
Manjaro: (OS /dev/sda3)

I tried to create a new partition with gparted called /dev/sda4 as ext2 to create a new GRUB from “scratch”, but I don’t know well what to do or the commands to use to link my OS partitions. Anyone know how to create a GRUB from scratch if WIN and Manjaro partitions still exist , with related commands ?? Thanks, I cannot use the other PC, I don’t want to re-format all

2

Welcome to the forum! :slight_smile:

First of all, what exactly do you mean by “a GRUB partition”? Using the correct vernacular is essential.

There are two ways of installing/booting a GNU/Linux operating system on a modern x86-64 computer, namely… :arrow_down:

  • native UEFI boot
  • CSM (legacy BIOS compatibility) boot

Now, the chosen installation/boot method also has its repercussions on the type of partition table that is to be used.

Although native UEFI boot in theory supports a legacy MS-DOS/MBR partition table, in practice, not all UEFI implementations do, and therefore the advice is for such a system to use a GPT, also known as the GUID partition table. A system booting in native UEFI mode requires an EFI system partition of about 512 MiB, formatted as vfat (FAT32), marked with the boot and esp flags, and mounted at /boot/efi.

Systems that boot in legacy BIOS mode however can be installed on either a GPT-partitioned drive or an MS-DOS/MBR-partitioned drive, but there is a catch if you’re going to use GPT. In that case, a legacy BIOS installation that uses GRUB as the boot loader needs a special unformatted partition of type bios, about 2 MiB in size, and with the boot flag set. This partition is not mounted anywhere, because it doesn’t have a filesytem on it, but it is needed in order to stop GRUB from overwriting partition boundaries on a GPT-partitioned drive.

So far the theory. So which scenario applies to you? You say you have Microsoft Windows 10 on your computer, and Windows 10 requires UEFI boot. It therefore stands to reason that you have a GPT-partitioned drive, and that your system boots in native UEFI mode. By consequence, you would have an EFI system partition on your drive, not an unformatted bios partition, and if this partition is gone, then you can boot neither Microsoft Windows nor GNU/Linux, because the EFI system partition contains the UEFI boot manager entries for all installed operating systems.

Please help us help you, and provide the output of the commands… :arrow_down:

fdisk -l 
efibootmgr

Use the </> button in the toolbar of the editor and paste the output of both commands above between the two lines of backticks (```).

3 Likes
3

Hello and thank you for welcome and the really informative reply! : )

Yes I totally think you got it and my scenario is the one you are supposing at the end of your reply, the casistic of “UEFI boot mode” and as you said this EFI partition is gone and can’t boot neither Windows10 and GNU/Linux; therefore I think I need as a consequence to do this part somehow and link the OS to that " A system booting in native UEFI mode requires an EFI system partition of about 512 MiB, formatted as vfat (FAT32), marked with the boot and esp flags, and mounted at /boot/efi ."

Here the output of the commands :

fdisk -l

`Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors

Disk model: TOSHIBA DT01ACA1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x7b1d3d1a

Device Boot Start End Sectors Size Id Type /dev/sda1 2048 1026047 1024000 500M 7 HPFS/NTFS/exFAT /dev/sda2 1026048 979146751 978120704 466.4G 7 HPFS/NTFS/exFAT /dev/sda3 979146752 1953318911 974172160 464.5G 83 Linux /dev/sda4 1953318912 1953523711 204800 100M 83 Linux

Disk /dev/sdb: 14.42 GiB, 15487991808 bytes, 30249984 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x6d6a07e4

Device Boot Start End Sectors Size Id Type /dev/sdb1 * 0 4499903 4499904 2.1G 0 Empty /dev/sdb2 180 131251 131072 64M ef EFI (FAT-12/16/32)

Disk /dev/loop0: 2.03 GiB, 2174554112 bytes, 4247176 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes

efibootmgr
EFI variables are not supported on this system.

the /sda/4 is just one partition as I said that I just created before posting to try to solve the problem as i said in my previous post (so assume it doesn’t exist, i can delete that)

4

Try again but this time paste after you run sudo fdisk -l | xclip because your formatting makes the whole unreadable…
Although after a little squiking with eyes and reformating a part of it it shows:

/dev/sda1 2048 1026047 1024000 500M 7 HPFS/NTFS/exFAT
/dev/sda2 1026048 979146751 978120704 466.4G 7 HPFS/NTFS/exFAT
/dev/sda3 979146752 1953318911 974172160 464.5G 83 Linux
/dev/sda4 1953318912 1953523711 204800 100M 83 Linux
/dev/sdb1 * 0 4499903 4499904 2.1G 0 Empty
/dev/sdb2 180 131251 131072 64M ef EFI (FAT-12/16/32)

Which shows that your ESP is on /dev/sdb2…
Did you perhaps change disks or added a new one to your machine?

PS: There is no such thing as a “Grub partition” :wink:

That just means you did not boot in UEFI mode…

2 Likes
5

Thank you for the reply!! I tried your command but sadly the USB live has no internet function in live modality and output is xclip is not installed (I am typing here from another device), in any case what you typed after squiking is indeed correct

About last part I did not change disks, the only similar thing I can think is when I open computer it says System FAN Failure press F1 to continue, but this is something I have since some time, usually when I press it everything worked normally and GRUB opened(have to change FAN)

6

Ohhhh then /dev/sdb must have been your USB-Stick with the Live Version.
Which means if combined with the non-UEFI boot, that you would lack an MBR to boot with.

It’s been way to long for me to remember how to fix the MBR for Legacy BIOS mode, so maybe @Aragorn or someone else can take over and help further…

1 Like
7

Yess /dev/sdb is the USB Live. So if it says “EFI variables are not supported on this system.” it means it is non-UEFI modality, or can be EFI but that everything just disappear and so is missed not supported

Thank you for everything : )

8

You have a msdos parted disk, there was no space inbetween your existing partitions for any other partition → You have a BIOS/MBR system. :tada:

Boot into a live ISO in BIOS (legacy) mode (don’t select the boot entry with UEFI in it).

Enter

sudo manjaro-chroot -a  (enter 1 if selection is 0 or 0)
parted -l

(Check if /dev/sda is still your partition with Windows and Manjaro)

If yes:

grub-install --recheck /dev/sda
update-grub
exit

and reboot. This will restore the grub bootloader. Should be fixed then.

2 Likes
9

can you boot on USB iso manjaro
open a terminal and browser on this topic
and return

inxi  -Fxza
test -d /sys/firmware/efi && echo efi || echo bios
sudo efibootmgr -v
sudo parted -l

use [ code ] and [/ code ] ( suppress space between [] ) for each report

1 Like
10

@stephane, no need, all answers to determine BIOS or UEFI have already been posted. :wink:

11

UEFI[legacy] or MBR format partition cant let you install or restore /boot/efi manjaro

12

To be honest I don’t understand what you intend to say, @stephane .

For me the proofs are:

This combination is only reasonable if the system is BIOS/MBR. The start and end sectors of the partitions make clear that there was never any partition inbetween. So there was no space for an EFI partition which would be strange for an msdos parted disk anyhow.

1 Like
13

waiting inxi -Fza

14

Thank you so much this in my case is the solution and helped to fix the problem : )

Thank you to all people that helped and spared some time here !! all very kind and fast

2 Likes
15

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.