[SOLVED] Zorin OS 15 Ultimate Grub Repair

13- · 01-22-2020, 07:50 PM

Boot Repair Pastebin - http://paste.ubuntu.com/p/j3QGRxKdxZ/

I use Windows 10 for most of my general needs, but occasionally, there's just things that work better in Linux. However, sometimes Windows acts the fool and needs to be formatted (in such cases that there's service pack or update issues).

This was one such case, however, I, as many users have, forgot that taking my Windows partition also takes Grub with it. No big deal though, right?

I thought that'd be the case when I started up boot repair. Then I'm hit with this message - "Please enable a repository containing the [grub-efi-amd64-signed] packages in the software sources of Zorin OS 15 (sde2). Then try again."

This is the part where I get pretty confused, and would like to be walked through what I should do. I've attempted this on my own a few times over the past few months, even going so far as to send my pastebin in to a few places, to no avail. I've attempted to do this via my Zorin OS install USB through terminal, no dice there either.

Thanks in advance.

mrmazda · 01-23-2020, 11:20 PM

There are two ways to avoid having Windows significantly disrupt booting Linux, or simplify repair when it becomes necessary:

Neutral MBR (don't put Grub on MBR of MBR disks)
Use UEFI/GPT on all disks

When either of these methods is employed:

Disruption is less likely
Disruption, when it occurs, is easier to repair

When Grub is installed to an MBR, it's doing the same thing that Linux users complain about Windows doing: replacing the existing MBR code with something else. Linux doesn't need Grub code on the MBR. Putting it there is inviting Windows to replace it. With Grub on a primary partition on an MBR disk instead of on the MBR, boot control selection is a simple matter of where the boot flag is present in the MBR partition table, and easy to move with any of tens of tools whether booted to Windows or Linux or DOS.

With UEFI/GPT, Windows has no proclivity to overwrite anything installed by Linux that cannot be simply and quickly repaired, if it somehow gets corrupted. Its ESP partition was designed to be shared by any number of coexisting operating systems.

yancek · 01-24-2020, 08:32 AM

You have a UEFI/GPT install of windows 10 which is standard but boot repair shows no EFI files for Zorin. I don't use Zorin myself but if it is similar to the other Ubuntus, it should have a directory named ubuntu in one of the EFI directories which it does not. If you have an EFI install of any Linux, you need the proper EFI files for Linux on an EFI partition.

Quote:

This was one such case, however, I, as many users have, forgot that taking my Windows partition also takes Grub with it. No big deal though, right?

No, it doesn't and never has. There should never be any Grub code on a windows partition. Grub code on older computers is in the MBR as well as on the Linux partition and on newer EFI installs the EFI boot files are on the EFI partition in a separate directory and windows should not overwrite them. Some windows updates will rewrite the partition table and leave out any non-windows partitions. You situation is complicated by the number of drives you have and the number of partitions. You have windows EFI files on sdd2 but no EFI files for Zorin so I would not expect it to boot.

You have a second EFI partition on sde1 and the Zorin install appears to be on sde2. Boot repair was going to install the EFI files on the EFI partition (sde1) on the Zorin drive but you don't have the correct repositories enabled on the installed Zorin (sde2). See lines 1205-1207 in boot repair.

13- · 01-24-2020, 04:48 PM

@mrmazda - I used the default installation configuration. Very informative, though. Took a couple of reads to absorb, but I think I understand.

@yancek - Thanks for the clarification on GRUB. From what I can tell, it's based on Ubuntu, so we've got that going for us, at least.

I'll take a look at getting the repos installed again and report back if I have any issues.

mrmazda · 01-24-2020, 05:54 PM

Quote:

Originally Posted by 13-

From what I can tell, it's based on Ubuntu, so we've got that going for us, at least.

It's as much a for as an against, in a UEFI multiboot context at least. Most derivatives use the same directory on the ESP as Ubuntu, /boot/efi/EFI/ubuntu, making multibooting Ubuntu and any derivative complicated to achieve and maintain. Post-installation this is correctable via a GRUB_DISTRIBUTOR= edit, but AFAICT, not before.

colorpurple21859 · 01-24-2020, 08:36 PM

Based on this from your past bin

Quote:

... sde2/etc/fstab:...
# /boot/efi was on /dev/sdd2 during installation
#UUID=F2FD-532A /boot/efi ....
"blkid" output...
/dev/sdd2 62EF-5F1E

I believe that the update reformated the efi partition for some reason.

To reinstall grub in efi mode
boot the zorin install usb
open a terminal
check to see if /sys/firmware/efi directory exist

Code:

cat /sys/firmware/efi

If the directory doesn't exist you booted in legacy mode and will need to reboot live usb in efi mode.
Once booted in efi mode
from a terminal

Code:

sudo mount /dev/sde2 /mnt
sudo mount /dev/sdd2 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
chroot /mnt
grub-install
update-grub
exit
reboot

You will also need to edit your fstab
change this line

Code:

 #UUID=F2FD-532A  /boot/efi ....

to

Code:

UUID=62EF-5F1E  /boot/efi ....

and either delete or add a # to the beginning of this line

Code:

UUID=0527-926B	/boot/efi..

..

13- · 01-26-2020, 02:12 PM

@mrmazda - Sorry if I don't have anything of substance to add. I'm not particularly familiar with Linux, and as such, a lot of it's just jargon to me. However, given my experience thus far, I'm at least inclined to agree to the complexity of maintaining a dual boot!

@colorpurple - That's a pretty concise set of instructions. I appreciate y'all a bunch! I've been swamped with work and haven't had time to do any of this, but I'll make time during the week again.

I'll let you all know if I have further complications.

13- · 02-20-2020, 10:55 PM

An update: I ultimately deferred to someone with far more Linux knowledge and background than me and we both ended up reaching a long, drawn out conclusion that something was very wrong with the install. Suffice to say, since I have way more faith in Ubuntu, I ended up going back to the latest LTS Ubuntu. I ended up just salvaging my important data from my backups and moved on.