6

I use Lenovo y500 and after buying a 250 gb Samsung SSD, I decided to use dual OS consisting of Arch Linux and Windows 8.1. In order to prevent boot problems, I installed Arch later. I used UEFI and selected systemd-boot for the installation. Linux boot loader worked fine. However, for some reason, the boot screen was not aligned for my screen correctly and I decided to update my BIOS (which I regret doing because it did not fix the problem) since the issue, according to my search, is about the firmware.

After that, in boot options, I could not see the Linux boot loader. There was only Windows boot loader. Checking the EFI partition, I found that systemd-boot files do exist without any change.

I couldn't understand why my PC cannot see the Linux boot loader. There was no information about this in the Internet, either. So my questions are:

  • How can a BIOS update affect my EFI boot?
  • If the problem is about update indeed, should I try to roll it back?
  • For my problem, is it possible to repair EFI by using Arch Linux live USB? If it is, how?

I feel impelled to say that BIOS update re-enabled Secure Boot. I disabled it, nevertheless, that did not work. The update might have done something to EFI when it re-enabled Secure Boot but I'm not sure.

1
  • 1
    Hi, it might help if you gave us some more details. Which version of Arch have you installed and did you regularly update your system (as strongly recommended by the Arch community)? What exactly is your boot process? Did I understand you correctly that you use systemd-boot to load the windows boot loader? If yes, does this still work? How did you boot into Linux, are you using an additional boot loader next to boot-systemd? Last but not least, how did you partition the disk? – vic Oct 18 '15 at 18:35
4

I had the same issue with systemd-boot. After recent bios patch for MSI gs40, systemd bootloader was gone from bios options. Yet grub2 (ubuntu's loader) and ms-boot (windows') are still detected ok. Updating systemd-boot, toggling secure boot or some other random clicking in bios didn't help either. As for your questions:

  1. How can a BIOS update affect my EFI boot? The issue seems to be related to systemd-boot support for new EFI bios versions. There's still no issues in bugtrackers and I'm too lazy to create any.
  2. If the problem is about update indeed, should I try to roll it back? Nope, In my practice flashing old bios version can turn your laptop into a brick. You won't be able to firmware bios back without special programmer. Note that's not always, but I wouldn't risk
  3. For my problem, is it possible to repair EFI by using Arch Linux live USB? If it is, how? Just switch to grub2 or any other bootloaders. Archlinux usb livecd should still be bootable in UEFI mode. @younes answer will do fine. For more information see wiki

EDIT:

Ok, I was finally able to boot from systemd-boot. For me recreating efi structure helped for some magical reason. Here're steps to fix:

  1. Boot from any linux livecd (archlinux will do fine)
  2. mount your boot partition, backup all data from it somewhere
  3. Erase all files from boot partition (only file, no need to do some operations with partition)
  4. Install systemd boot again bootctl install, since you're already boot in efi mode and boot partition is mounted
  5. execute sync command to flush cache and reboot into BIOS. systemd boot should appear in UEFI loader. Mark it as first. Now after rebooting systemd boot should be available!
  6. Restore your old UEFI structure from livecd. (Copy your backed up /boot to new installed files in partition overriding them.)
  7. Reboot again and boot from your system.

I hope this help you.

1
  • 1
    I got this today after upgrading the BIOS on my Gigabyte Aorus X570. It was enough to run bootctl --path=esp install without recreating the ESP partitions file structure. – lubosz Dec 17 '19 at 11:10
3

Open Elevated Command Prompt (press Windows Key > type CMD > Right Click on Command Prompt > select Run as administrator) and enter the following:

bcdedit /set {bootmgr} path \EFI\<<LINUX OS>>\grubx64.efi 

(In the above command, replace <<LINUX OS>> with debian for Debian OS and ubuntu for Ubuntu OS. example: bcdedit /set {bootmgr} path \EFI\debian\grubx64.efi )

1
  • 1
    This worked for me. NOTE: You literally put in {bootmgr}. I thought that was a variable you need to replace with something. But, it's not. :) – stuckj Jun 15 '20 at 20:30
2

Use live CD or USB, then chroot into your Archlinux which is on the hard drive, and then update-grub, also you may need to run grub-install /dev/sda && update-grub.

If you can give more informations about your hard drive (partitions table, type and parts scheme ...) the stdout of lsblk and sudo fdisk -l

1
  • OP clearly stated that he is using systemd-boot. I don't see how your Grub commands will help. – vic Oct 18 '15 at 18:31
2

There's a simpler way. Just enter the UEFI firmware settings from Windows boot options. Change the boot order and make Linux boot first. Save changes and exit. Upon reboot grub will load and you'll be able to boot into either of the two OSes.

2
  • I just actually did this and then found your comment. Should be top comment – Tasos Anesiadis Jun 19 '18 at 1:20
  • I think this should be an acceptable answer. This is exactly the perfect answer. It's even technically correct. Just Changing the boot ordered fixed the issue in my case. – Rajendra Mar 14 at 3:37
0

How can a BIOS update affect my EFI boot?

In UEFI, each installed OS is supposed to have their own boot variable stored in the NVRAM used for firmware settings. I've seen some UEFI firmware updates cause those NVRAM variables to be lost. It should not happen; yet, you should be aware that this can happen and know how to fix it.

Most Linux distributions that are capable of booting in UEFI mode will also include the efibootmgr command, which is designed for viewing and manipulation of the boot variables. If you have a UEFI system running Linux, it would be a good idea to run efibootmgr -v as root and save the output onto some external media, or even print it. Although the missing boot variable information is usually not too difficult to figure out, having a print-out of a known-good state is extremely helpful when you need to recover.

If the problem is about update indeed, should I try to roll it back?

If the reason was that the NVRAM variables were reset to factory defaults as part of the update, rolling it back will not help: most likely returning to a previous firmware version would just cause another NVRAM variable reset.

For my problem, is it possible to repair EFI by using Arch Linux live USB? If it is, how?

Yes, assuming the live USB is booted in UEFI style, and not in legacy BIOS style. Access to UEFI NVRAM boot variables from the running OS is only possible when the system is booted in UEFI style. If the boot from USB uses legacy BIOS-style boot process, the UEFI standard interface for changing the NVRAM variables will be hidden away to maximize compatibility with the traditional BIOS.

You should first mount the EFI System Partition that contains the installed OS's bootloader to its customary location (usually /boot/efi or /boot, depending on distribution). Chrooting to the existing OS installation should also work, if the EFI System Partition is then mounted within the chroot.

Using the efibootmgr command, you can write the lost NVRAM boot variable like this:

efibootmgr --create --disk /dev/sdX --part Y --loader "\EFI\systemd\systemd-bootx64.efi" --label "Linux Boot Manager" --verbose

Note that the --loader pathname uses Windows pathname conventions and is relative to the root of the EFI System Partition. Because it uses backslashes, you must either quote the path or double the backslashes or else the shell will mis-interpret it.

The --part Y option is only needed if you have multiple EFI System Partitions on a single disk or your EFI System Partition is not the first partition on the disk.


If you can get into Windows, it can also be used to recover the UEFI boot variable for Linux. However, Nabeel Kirmani's method in another answer is slightly incomplete: it overwrites the path in Windows's UEFI boot variable with the pathname of the Linux bootloader. It might work with Windows 8.x, but Windows 10 will detect the "tampering" and will write its own value back in as an attempt to "self-heal". Instead, you'll need to create an independent UEFI boot variable for Linux:

Start a Windows Command Prompt as an Administrator. Then run this command

bcdedit /copy {bootmgr} /d "Linux Boot Manager"

This will create a new UEFI boot variable, name it appropriately, and output a GUID string, which you will need to use in the second command:

bcdedit /set {guid} path \EFI\systemd\systemd-bootx64.efi

Replace {guid} above and in the next command with whatever was returned by the first command. This second command will configure the new boot variable to start the Linux systemd-boot bootloader instead of the Windows one.

Finally, set the new boot variable as the first one in the system boot order:

bcdedit /default {guid}

(Windows instructions from Arch Wiki.)

-2

Go into your BIOS and select the Ubutu boot loader to load first.

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.