After formatting the same usb key a lot of time, I carelessly formatted my /dev/sda1 to ext4. My system is composed of Windows 8 (sda3) with a data partitions (sda5) and I added Ubuntu 16.04 (sda6) on its side, with home on another partition (sda8). Finally I installed BunsenLabs on another partition (sda9). The three were working perfectly fine with Grub before my mistake.

I believe I was careful to install them all to boot through uefi.

Once I formatted it, I rebooted to be sure of my terrible mistake. Indeed, nothing listed in the boot order list. I am now using a live usb on Lubuntu booted via uefi.

What I tried so far :

  • Use testdisk after my mistake. Launched a deep search but didn't manage to find the lost partition, and was afraid to make any action I didn't fully understand on my partitions.
  • Install boot-repair and try a default repair, and get this error :

GPT detected. Please create a BIOS-Boot partition (>1MB, unformatted filesystem, bios_grub flag). This can be performed via tools such as Gparted. Then try again.

  • Last resort is to ask here with a paste of what boot-info reported.

Here is the boot-info report : http://paste.ubuntu.com/25439367/

I don't see the point of creating this bios flagged partition, and don't want to dig a deeper hole. I will then be deeply grateful to anyone understanding how to solve this issue, Thanks !

  • 1
    Boot-Repair does not seem to see the new FAT32 ESP - efi system partition to offer to re-install grub in UEFI boot mode. The request for bios_grub partition is only for BIOS boot which you do not want.New sda1 has different UUID than that in fstab, so that it does not show anything may be correct, but sometimes script does not show files. Have you tried sudo dosfsck -t -a -w /dev/sda1 ? And then see if you can reinstall all of grub-efi-amd64 from advanced options in Boot-Repair, not auto fix nor grub-pc(bios). – oldfred Aug 31 '17 at 16:48
  • @oldfred Thanks for your time ! Indeed the UUID for automount in fstab is changed. Does that mean I need to change fstab file accordingly in the two linux OS ? What about Windows ? Here is the output of the command you gave : fsck.fat 3.0.28 (2015-05-16) > /dev/sda1: 0 files, 1/524256 clusters . Finally I don't see any options with grub-efi-amd64 in the advanced options. – Renon Lift Aug 31 '17 at 17:21
  • Is this answer suitable for my case ? superuser.com/questions/376470/how-to-reinstall-grub2-efi – Renon Lift Aug 31 '17 at 17:57
  • Your Windows bootloaders are gone too, and will have to be reinstalled or copied from another machine/disk. Do you have any backups or other copies of the sda EFI partition? – ubfan1 Aug 31 '17 at 18:52
  • 1
    Your link to full chroot should work. Not sure if Boot-Repair is using old UUID in fstab and not finding it is why it is not working. Full reinstall of grub will add correct UUID entry into fstab, but do not know if it leaves old entry. Best to check and make sure you do not have two entries. Another UEFI chroot. askubuntu.com/questions/53578/… Main difference over many other chroot instructions is with UEFI you must also mount the ESP/efi system partition. – oldfred Aug 31 '17 at 19:01

If you've got a full system backup, or even just a backup of your EFI System Partition (ESP; /dev/sda1 in your case), you should be able to restore the ESP and everything should be fine. (You'll need to edit /etc/fstab to refer to the ESP's new serial number ["UUID," which it really isn't.])

Failing that, it's best to restore Windows to bootability first. This is because Windows tends not to play nice with other OSes, so if you restore Ubuntu first and then restore Windows, the computer will end up booting straight to Windows. This problem is not difficult to fix if you know how, but it's easier to restore Windows first and then deal with Ubuntu. As to how to restore Windows to bootability, you should ask about that on a Windows forum. You'll need a Windows emergency recovery disk for your Windows version, though. You can probably find one of these online, or create one from another computer that runs the same version of Windows.

As to restoring Ubuntu to bootability, there are several ways to do this. The two easiest are:

  • Boot Repair -- The Boot Repair tool can install a fresh copy of GRUB on the ESP. The trouble you encountered with it most likely means that you booted in BIOS/CSM/legacy mode rather than in EFI/UEFI mode; or maybe if you tried running it when /dev/sda1 used ext4fs, that could have thrown it off. Controlling the boot mode (BIOS vs. EFI) of a removable disk can be tricky if you don't know what you're doing. The best way to do what you want is to go into your firmware settings and disable the CSM (aka "legacy boot support" or "BIOS boot support"), but details of how to do this vary greatly. If you boot the external medium by using a boot menu, it may have two options to boot your medium, one of which includes the string "UEFI" and the other of which does not. Pick the option that includes "UEFI" to boot in EFI mode. See my page on the CSM for more on this topic.
  • rEFInd -- You can download a USB flash drive or CD-R version of my rEFInd boot manager and prepare a boot medium from it. When you boot from that medium, it should give you options to boot both your Linux distributions. (If you do this after you get Windows booting, rEFInd should also show you a Windows boot option.) If you boot into Ubuntu, you can then install the rEFInd Debian package or PPA; or you can simply use this as a way to boot into EFI mode and then run Boot Repair. If you install rEFInd to your hard disk, it will take over as your primary boot manager, bypassing GRUB.

I've never before heard of BunsenLabs Linux. In theory, either of the above methods should pick it up and present it as a boot option; however, it's possible that this won't work correctly. If you have problems, you could try the other recovery method or work to fix the problem in whichever boot manager you decide to use.

Moving forward, you may want to back up your ESP to make for easier recovery from such problems in the future. Ubuntu normally mounts the ESP at /boot/efi, although you'll need to edit /etc/fstab to get your modified ESP to mount there by default. (When you created a fresh filesystem, that changed its serial number, which is called a "UUID" in /etc/fstab. Your current ESP has a serial number of 71B1-C511, according to your Boot Repair output.) A file-level backup, using tar, zip, cp, or other tools, should work fine. Copy everything to a USB flash drive and you'll be able to restore it all pretty easily should you run into a similar problem in the future.

|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.