3

I am to a dead end with a bricked laptop. Yesterday after a boosted fan madness and unresponsive desktop, the laptop would not start again properly; dpkg does not repair anything nor it is recognized when typed in the command line provided by the bricked laptop. Booting even in safe mode is impossible as the display starts to glitch.

I run a live medium to try to reinstall the boot method using bootloader since it appears to be the cause. I run it successfully but I still do not have access to Linux Mint cause it does not have a grub.

The problem is that I was following the procedure in this link askubuntu but I cannot since I do not have /mnt/boot/efi folder (I assume I did not have grub before?)

This is my partition table enter image description here

enter image description here

EDIT: after successfully running all commands provided in answer, this is the result without pressing anything and launching the machine as is when booting

enter image description here I got this when booting via UEFI, same as before, glitches and unable to select dpkg or anything.

enter image description here

SOLUTION: I found the Culprit, I modified the FSTAB configuration with broken samba share link, everything is backed on.

Improve this question
1
  • With UEFI, you want to always boot in UEFI boot mode. Only a few systems used to require Legacy on, but select UEFI to boot. Most now require legacy off. Usually better (for now) to have UEFI Secure Boot off. If considering multiple booting better to have data partition(s), not separate /home. I have multiple Ubuntu installs with same data in all. askubuntu.com/questions/1013677/… & askubuntu.com/questions/1058756/…
    – oldfred
    Apr 29, 2020 at 14:52

2 Answers 2

Reset to default
2

The "This GPT partition label contains no BIOS boot partition" message suggests that you may have booted your live media in legacy BIOS style, and as a result, you'll wind up trying to install a BIOS version of GRUB onto a GPT-partitioned disk.

/dev/sda2 seems to be your EFI System Partition (ESP), which should get mounted to /mnt/boot/efi. Because ESP exists on your disk, it indicates your system was previously booting in the native UEFI way.

/dev/sda3 is a swap partition.

The remaining three partitions, sda1, sda4 and sda5 are all ext4. One of these is your root filesystem. Another might be a separate /boot filesystem. What is in the remaining one?

First, you'll need to boot your recovery live media using the same boot style (either BIOS or UEFI) as was used by the system you're trying to repair; by default, the GRUB installer will auto-detect the type of bootloader to install according to the way the system is currently booted. And installing a UEFI version of GRUB requires access to UEFI NVRAM variables, which will only be available if the system is booted in native UEFI mode.

You can verify the current boot mode by running sudo efibootmgr -v: if it outputs a list of boot settings, the system is booted in UEFI native mode. If it displays an error message "EFI variables are not supported on this system", you have most likely booted the system in legacy BIOS compatibility mode.

If your installation had /boot as a separate filesystem, you'll need three steps:

  1. Mount the root filesystem to /mnt in the live medium. After that, /mnt/boot should now exist (among other things).
  2. Mount the /boot filesystem to /mnt/boot in the live medium. After that, /mnt/boot/efi and /mnt/boot/grub directories should now exist.
  3. Mount the ESP to /mnt/boot/efi in the live medium. After that, a directory path like /mnt/boot/efi/EFI/ubuntu should now exist, assuming that traces of previous installation of Ubuntu's UEFI GRUB are still there. Yes, it is normal to have .../efi/EFI/... in the directory structure. And since the ESP is a FAT32 filesystem which is designed to be case-insensitive, the case of the names of directories and files under /mnt/boot/efi may vary.

Once this is completed, you can proceed with the remaining steps:

for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sdX
update-grub
Improve this answer
5
  • the last partition is the /home partition. Would you recommend such partition division? I would like to find a partition division that will facilitate me distro hopping and dual bootign the most but that is another topic.
    – Alessio_110
    Apr 29, 2020 at 14:40
  • I always remember to log through the BIOS ugly looking boot system rather than UEFI. is that possible? Lastly, I should select the live medium under the UEFI section in the picture I have just attached to have run all those command, is that right?
    – Alessio_110
    Apr 29, 2020 at 14:47
  • Updated question with results, I fear it is not related to UEFi and booting afterall, after running all the instructions I even received a nice without error result from the commands launched
    – Alessio_110
    Apr 29, 2020 at 16:16
  • Thanks for this great explanation. What’s so damn weird here is efibootmgr -v shows the content just fine, and yet running grub-install shows “Installing for i386-pc platform” and the "This GPT partition label contains no BIOS boot partition" error.
    – Steven Lu
    Mar 16, 2021 at 16:32
  • It is possible to install both BIOS and UEFI versions of GRUB files at the same time. You might need to explicitly specify you want the UEFI version with the --target option, e.g. grub-install --target=x86_64-efi /dev/sdX
    – telcoM
    Mar 16, 2021 at 17:00
0

I just encountered precisely this issue on Ubuntu Server 18.04 configured for EFI boot mode (not BIOS / legacy / CSM). After booting without incident, it began persistently booting only to the GRUB shell. After booting the OS manually from the GRUB shell, and running

# update-grub

attempting then to reinstall GRUB failed.

Apparently, the problem was that the EFI version of GRUB (grub-efi) was not installed on the system but the BIOS version (grub-pc), was. All it took to fix the problem was:

# apt install grub-efi
# update-grub
# grub-install

The clue was that, beforehand, update-grub insisted on a device specification, throwing the above error when it got one. The update-grub command does not take a device specification on EFI systems, however.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.