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
    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
    Commented Oct 18, 2015 at 18:35

7 Answers 7


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


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
    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
    Commented Dec 17, 2019 at 11:10
  • 1
    I had the same issue. I mounted the Linux boot partition in /boot and used the command bootctl install and sync. After rebooting my partition was showing. I would buy you a coffee if I could. Commented Oct 17, 2023 at 18:29

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
    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
    Commented Jun 15, 2020 at 20:30
  • Wow thank u very much.
    – logbasex
    Commented Jun 12, 2023 at 1:29

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.

  • I just actually did this and then found your comment. Should be top comment Commented Jun 19, 2018 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
    Commented Mar 14, 2021 at 3:37
  • This is not a valid answer. The OP stated that the linux bootloader is not available in BIOS. Commented Jun 28, 2023 at 18:23

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


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

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

Use boot-repair utility to generate a log of your system. This will give you a good overview of your system including partitions, operating systems and boot files present.

boot-repair can be found here

The boot-repair-disk can be flashed to a USB storage medium, and contains the tool in a Linux Mint live USB disk. boot-repair has a really nice automatic repair function, and generates a good log.


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .