Can't enter BIOS after Debian Install - Swift 3 sf314-52

GasparB123 · April 2021

I have an Acer Swift 3 sf314-52 with a 256 GB SSD. I recently bought a new 256 GB SSD to add into the extra M.2 slot. It works fine and was recognized in BIOS. After this I installed Windows 10 and after it Debian, each OS on a different SSD.

The problem now is, that I want to change the boot order so that Debian starts first, so it can give me the choice of what to boot from using GRUB, but I cannot access the BIOS anymore. Pressing F2 leaves me with a black screen and a white dash on the top left corner. Luckily I activated the F12 boot menu and that works fine. I opened each OS separtely and they both work without any problems as far as I can see.

I've tried opening BIOS from windows advanced settings, from GRUBs option as well, it all gives me the black screen with white dash.

I don't know what the problem is. I rarely enter BIOS but I don't want to have to press f12 everytime I want to boot Debian. If anyone can give me a hand it'd be much apreciated.

//Edited the content to add model name on title.

Gawain · April 2021

i found this from a previous thread about 10/deb bios issue. I had a similar issue a few years back after installing suse 42 on a swift and the bios is a tad odd. But have a read 'cause it makes sense to me:

I want to share how I fixed this and what I learned about the issue.

To summarise, The Acer firmware has a fault where the existence of certain entries in the UEFI boot list prevent the UEFI setup from loading, and it crashes on F2. It doesn't interfere with actual booting, so if you have no reason to get back into the UEFI setup, well maybe you don't mind. It also doesn't interfere with the F12 boot menu if that was enabled before this happened.

First, what you DON'T need to do:

- You don't need to reflash firmware. Doing that carries inherent risk, and in this case isn't the cause of the issue.
- You don't need to disable secure boot. In fact, the secure boot setting appears not to have any effect on my system, but perhaps that's because the UEFI already trusts the boot executables. I'd like to think it's that, and not that Secure Boot simply doesn't work. In any case, some of the below steps require secure boot to be ON, so I'd recommend leaving it on, unless you need to turn it off temporarily to boot your installation media.
- You may find instructions online for configuring your distro to place a boot entry into the *fallback* directory in your EFI partition. This is designed to work around some buggy UEFI implementations, but is not a solution to this and isn't recommended here.

For me, it was Debian GNU/Linux that I was installing but this should be relevant for most Linux distros, indeed it appears that it's the boot entry that Grub-EFI inserts into the firmware that it has a problem with. For other distros, where I refer to "debian" it will simply say something else instead.

After installation, you should notice that booting into the new system is successful, but loading UEFI setup on F2 fails (crashes with a cursor in the top left).

Steps to fix:

You need to get the UEFI boot entry out of the firmware. You can do this in either of two ways. One is to temporarily remove vendor files in your EFI partition from a Live USB. But, probably a better one is to use the *efibootmgr* tool in Linux to remove the boot entry, if only because it may prevent the need to boot to a Live USB:
Boot into your Linux install. From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
Note the number of the boot entry you want to delete. It'll be the big long one that ends in something like *File(\EFI\debian\shimx64.efi)* where "debian" is the vendor of your Linux (eg it might be "Ubuntu", etc).
Delete that entry with *efibootmgr -b 0001 -B* (where 0001 is the number of the boot entry from the previous step).
You may need to do the same if you have other Linux or grub related entries in there, but any generic looking entries are probably OK to leave, and entries that refer to Windows can also be left if Windows is still installed as well (you may have additional difficulties dual booting, but that's not relevant to this issue).
Reboot the system into the UEFI setup using F2. It should work. Now though your firmware won't know how to boot into Linux, but you can do the following:

Make sure secure boot is on, and go into the setting where you add a trusted executable to secure boot. This will guide you through browsing your EFI partition, where you should navigate to HDD0 -> EFI -> debian -> shimx64.efi (or equivalent). Note that on distros that use a shim bootloader (shimx64.efi) you may see multiple entries including a "grubx64.efi" as well, but in this case "shimx64.efi" is what you want. If only grubx64.efi is listed, that's probably what you want, though I haven't tested on such a distro.

When prompted if you want to add a boot entry for this, select Yes.
Save settings and boot. It should work.

If you're unable to get everything booting again after step 4, you can get back to where you were at the start using a Live USB, mounting everything in a chroot and running a grub reinstall (there are instructions for this online) but that just gets you back to where you were at the start and UEFI setup probably won't work again.

Gawain · April 2021

can you enter the bios if you remove (physically) one or both drives?

GasparB123 · April 2021

Gawain said:

can you enter the bios if you remove (physically) one or both drives?

I have wiped either one of the drives and it solves the issue, but then again I can't dual boot.

I will try to physically remove them, but I believe it will have the same result as wiping it

GasparB123 · April 2021

Gawain said:

can you enter the bios if you remove (physically) one or both drives?

Just removed one drive and then the other and it works fine. It all goes wrong when both of them are in, with both OSes installed on each drive.

Gawain · April 2021

I take it deb was installed with the 10 drive in place, so what you were expecting on boot up would be a screen with the option of either 10 or deb? if that was the case, and you don't mind using f12 on boot to select a drive, personally i'd have 10 reinstalled on one (with the other physical drive removed), then once thats working, remove that drive, put the other one in and install deb on that - once thats installed then re-add the first drive too - use f12 to select the drive you want to boot from (and that way, you get grub well away from any messed up MS update that screws it up in the future).

Gawain · April 2021

forgot to mention the rationale behind this - when you install deb on drive 2, the installer see's a efi partition already exists and therefore doesn't create an additional one, and i think thats what creates the little hissy fit. but by removing the ms drive, the install allows a specific /efi on the deb drive, which'll give you two totally separate /efi partitions, and no hissy fit. totally separate complete installs.

GasparB123 · April 2021

Gawain said:

I take it deb was installed with the 10 drive in place, so what you were expecting on boot up would be a screen with the option of either 10 or deb? if that was the case, and you don't mind using f12 on boot to select a drive, personally i'd have 10 reinstalled on one (with the other physical drive removed), then once thats working, remove that drive, put the other one in and install deb on that - once thats installed then re-add the first drive too - use f12 to select the drive you want to boot from (and that way, you get grub well away from any messed up MS update that screws it up in the future).

When you boot up from deb, GRUB starts up a screen that lets you select what you want to boot from, along with some other advanced options. What I was trying to do was change the boot order so deb starts first, thus allowing me to choose windows or deb with the GRUB menu, without having to use F12.

Plus I was told in a deb forum that theoretically once deb is installed after windows 10, it should put itself automatically before windows in the boot order. But i doesn't seem to do that.

As a last resort I'll use F12, but it's not ideal.

Gawain said:

forgot to mention the rationale behind this - when you install deb on drive 2, the installer see's a efi partition already exists and therefore doesn't create an additional one, and i think thats what creates the little hissy fit. but by removing the ms drive, the install allows a specific /efi on the deb drive, which'll give you two totally separate /efi partitions, and no hissy fit. totally separate complete installs.

I understand the idea now, but trying this gives the same result as before. Can't enter BIOS to change the boot order with both m.2 slots used, and only F12 and selecting works.

GasparB123 · April 2021

Something I didn't mention before was that this Acer originally came with a Micron 256GB M.2 SATA and now I have added a WD 256GB Nvme M.2. I'm trying to install windows on the Western Digital Nvme, and deb on the Micron SATA.

I don't believe that should be an issue, but I mention it just in case.

Gawain · April 2021

i'm a bit confused - if buster was installed without the first 10 drive plugged in, 10 as an option shouldn't show up in grub (unless grub was manually updated after the 10 drive was plugged back in). I'm guessing grub was updated after the install.

GasparB123 · April 2021

Gawain said:

i'm a bit confused - if buster was installed without the first 10 drive plugged in, 10 as an option shouldn't show up in grub (unless grub was manually updated after the 10 drive was plugged back in). I'm guessing grub was updated after the install.

Yes, I updated GRUB after the install in an attempt to be able to boot deb, and choose what I want in the GRUB menu.

But that is all in vain if the boot order isn't changed. Even before and after updating GRUB, it still won't let me enter BIOS.

Commodore_1995# · April 2021

When you disconnect both ssds, can you access the bios? Have you also tried to reset the battery?

Gawain · April 2021

i found this from a previous thread about 10/deb bios issue. I had a similar issue a few years back after installing suse 42 on a swift and the bios is a tad odd. But have a read 'cause it makes sense to me:

I want to share how I fixed this and what I learned about the issue.

To summarise, The Acer firmware has a fault where the existence of certain entries in the UEFI boot list prevent the UEFI setup from loading, and it crashes on F2. It doesn't interfere with actual booting, so if you have no reason to get back into the UEFI setup, well maybe you don't mind. It also doesn't interfere with the F12 boot menu if that was enabled before this happened.

First, what you DON'T need to do:

- You don't need to reflash firmware. Doing that carries inherent risk, and in this case isn't the cause of the issue.
- You don't need to disable secure boot. In fact, the secure boot setting appears not to have any effect on my system, but perhaps that's because the UEFI already trusts the boot executables. I'd like to think it's that, and not that Secure Boot simply doesn't work. In any case, some of the below steps require secure boot to be ON, so I'd recommend leaving it on, unless you need to turn it off temporarily to boot your installation media.
- You may find instructions online for configuring your distro to place a boot entry into the *fallback* directory in your EFI partition. This is designed to work around some buggy UEFI implementations, but is not a solution to this and isn't recommended here.

For me, it was Debian GNU/Linux that I was installing but this should be relevant for most Linux distros, indeed it appears that it's the boot entry that Grub-EFI inserts into the firmware that it has a problem with. For other distros, where I refer to "debian" it will simply say something else instead.

After installation, you should notice that booting into the new system is successful, but loading UEFI setup on F2 fails (crashes with a cursor in the top left).

Steps to fix:

You need to get the UEFI boot entry out of the firmware. You can do this in either of two ways. One is to temporarily remove vendor files in your EFI partition from a Live USB. But, probably a better one is to use the *efibootmgr* tool in Linux to remove the boot entry, if only because it may prevent the need to boot to a Live USB:
Boot into your Linux install. From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
Note the number of the boot entry you want to delete. It'll be the big long one that ends in something like *File(\EFI\debian\shimx64.efi)* where "debian" is the vendor of your Linux (eg it might be "Ubuntu", etc).
Delete that entry with *efibootmgr -b 0001 -B* (where 0001 is the number of the boot entry from the previous step).
You may need to do the same if you have other Linux or grub related entries in there, but any generic looking entries are probably OK to leave, and entries that refer to Windows can also be left if Windows is still installed as well (you may have additional difficulties dual booting, but that's not relevant to this issue).
Reboot the system into the UEFI setup using F2. It should work. Now though your firmware won't know how to boot into Linux, but you can do the following:

Make sure secure boot is on, and go into the setting where you add a trusted executable to secure boot. This will guide you through browsing your EFI partition, where you should navigate to HDD0 -> EFI -> debian -> shimx64.efi (or equivalent). Note that on distros that use a shim bootloader (shimx64.efi) you may see multiple entries including a "grubx64.efi" as well, but in this case "shimx64.efi" is what you want. If only grubx64.efi is listed, that's probably what you want, though I haven't tested on such a distro.

When prompted if you want to add a boot entry for this, select Yes.
Save settings and boot. It should work.

If you're unable to get everything booting again after step 4, you can get back to where you were at the start using a Live USB, mounting everything in a chroot and running a grub reinstall (there are instructions for this online) but that just gets you back to where you were at the start and UEFI setup probably won't work again.

GasparB123 · April 2021

egydiocoelho said:

When you disconnect both ssds, can you access the bios? Have you also tried to reset the battery?

Yes, and yes. DIsconnecting just one of them let's me enter BIOS. Both of them even more so.

I unscrewed the top and the baterry to disconnect it and the CMOS battery. And it reset. After that, weirdly the deb boot entry dissapered.

GasparB123 · April 2021

Gawain said:

i found this from a previous thread about 10/deb bios issue. I had a similar issue a few years back after installing suse 42 on a swift and the bios is a tad odd. But have a read 'cause it makes sense to me:

I want to share how I fixed this and what I learned about the issue.

To summarise, The Acer firmware has a fault where the existence of certain entries in the UEFI boot list prevent the UEFI setup from loading, and it crashes on F2. It doesn't interfere with actual booting, so if you have no reason to get back into the UEFI setup, well maybe you don't mind. It also doesn't interfere with the F12 boot menu if that was enabled before this happened.

First, what you DON'T need to do:

- You don't need to reflash firmware. Doing that carries inherent risk, and in this case isn't the cause of the issue.
- You don't need to disable secure boot. In fact, the secure boot setting appears not to have any effect on my system, but perhaps that's because the UEFI already trusts the boot executables. I'd like to think it's that, and not that Secure Boot simply doesn't work. In any case, some of the below steps require secure boot to be ON, so I'd recommend leaving it on, unless you need to turn it off temporarily to boot your installation media.
- You may find instructions online for configuring your distro to place a boot entry into the *fallback* directory in your EFI partition. This is designed to work around some buggy UEFI implementations, but is not a solution to this and isn't recommended here.

For me, it was Debian GNU/Linux that I was installing but this should be relevant for most Linux distros, indeed it appears that it's the boot entry that Grub-EFI inserts into the firmware that it has a problem with. For other distros, where I refer to "debian" it will simply say something else instead.

After installation, you should notice that booting into the new system is successful, but loading UEFI setup on F2 fails (crashes with a cursor in the top left).

Steps to fix:
You need to get the UEFI boot entry out of the firmware. You can do this in either of two ways. One is to temporarily remove vendor files in your EFI partition from a Live USB. But, probably a better one is to use the *efibootmgr* tool in Linux to remove the boot entry, if only because it may prevent the need to boot to a Live USB:
Boot into your Linux install. From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
Note the number of the boot entry you want to delete. It'll be the big long one that ends in something like *File(\EFI\debian\shimx64.efi)* where "debian" is the vendor of your Linux (eg it might be "Ubuntu", etc).
Delete that entry with *efibootmgr -b 0001 -B* (where 0001 is the number of the boot entry from the previous step).
You may need to do the same if you have other Linux or grub related entries in there, but any generic looking entries are probably OK to leave, and entries that refer to Windows can also be left if Windows is still installed as well (you may have additional difficulties dual booting, but that's not relevant to this issue).
Reboot the system into the UEFI setup using F2. It should work. Now though your firmware won't know how to boot into Linux, but you can do the following:
Make sure secure boot is on, and go into the setting where you add a trusted executable to secure boot. This will guide you through browsing your EFI partition, where you should navigate to HDD0 -> EFI -> debian -> shimx64.efi (or equivalent). Note that on distros that use a shim bootloader (shimx64.efi) you may see multiple entries including a "grubx64.efi" as well, but in this case "shimx64.efi" is what you want. If only grubx64.efi is listed, that's probably what you want, though I haven't tested on such a distro.
When prompted if you want to add a boot entry for this, select Yes.
Save settings and boot. It should work.
If you're unable to get everything booting again after step 4, you can get back to where you were at the start using a Live USB, mounting everything in a chroot and running a grub reinstall (there are instructions for this online) but that just gets you back to where you were at the start and UEFI setup probably won't work again.

I thought this could be the problem, but I had no idea how to solve it. Thank you, I'll give this a try and let you know.

GasparB123 · April 2021

Gawain said:

i found this from a previous thread about 10/deb bios issue. I had a similar issue a few years back after installing suse 42 on a swift and the bios is a tad odd. But have a read 'cause it makes sense to me:

I want to share how I fixed this and what I learned about the issue.

To summarise, The Acer firmware has a fault where the existence of certain entries in the UEFI boot list prevent the UEFI setup from loading, and it crashes on F2. It doesn't interfere with actual booting, so if you have no reason to get back into the UEFI setup, well maybe you don't mind. It also doesn't interfere with the F12 boot menu if that was enabled before this happened.

First, what you DON'T need to do:

- You don't need to reflash firmware. Doing that carries inherent risk, and in this case isn't the cause of the issue.
- You don't need to disable secure boot. In fact, the secure boot setting appears not to have any effect on my system, but perhaps that's because the UEFI already trusts the boot executables. I'd like to think it's that, and not that Secure Boot simply doesn't work. In any case, some of the below steps require secure boot to be ON, so I'd recommend leaving it on, unless you need to turn it off temporarily to boot your installation media.
- You may find instructions online for configuring your distro to place a boot entry into the *fallback* directory in your EFI partition. This is designed to work around some buggy UEFI implementations, but is not a solution to this and isn't recommended here.

For me, it was Debian GNU/Linux that I was installing but this should be relevant for most Linux distros, indeed it appears that it's the boot entry that Grub-EFI inserts into the firmware that it has a problem with. For other distros, where I refer to "debian" it will simply say something else instead.

After installation, you should notice that booting into the new system is successful, but loading UEFI setup on F2 fails (crashes with a cursor in the top left).

Steps to fix:
You need to get the UEFI boot entry out of the firmware. You can do this in either of two ways. One is to temporarily remove vendor files in your EFI partition from a Live USB. But, probably a better one is to use the *efibootmgr* tool in Linux to remove the boot entry, if only because it may prevent the need to boot to a Live USB:
Boot into your Linux install. From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
Note the number of the boot entry you want to delete. It'll be the big long one that ends in something like *File(\EFI\debian\shimx64.efi)* where "debian" is the vendor of your Linux (eg it might be "Ubuntu", etc).
Delete that entry with *efibootmgr -b 0001 -B* (where 0001 is the number of the boot entry from the previous step).
You may need to do the same if you have other Linux or grub related entries in there, but any generic looking entries are probably OK to leave, and entries that refer to Windows can also be left if Windows is still installed as well (you may have additional difficulties dual booting, but that's not relevant to this issue).
Reboot the system into the UEFI setup using F2. It should work. Now though your firmware won't know how to boot into Linux, but you can do the following:
Make sure secure boot is on, and go into the setting where you add a trusted executable to secure boot. This will guide you through browsing your EFI partition, where you should navigate to HDD0 -> EFI -> debian -> shimx64.efi (or equivalent). Note that on distros that use a shim bootloader (shimx64.efi) you may see multiple entries including a "grubx64.efi" as well, but in this case "shimx64.efi" is what you want. If only grubx64.efi is listed, that's probably what you want, though I haven't tested on such a distro.
When prompted if you want to add a boot entry for this, select Yes.
Save settings and boot. It should work.
If you're unable to get everything booting again after step 4, you can get back to where you were at the start using a Live USB, mounting everything in a chroot and running a grub reinstall (there are instructions for this online) but that just gets you back to where you were at the start and UEFI setup probably won't work again.

I tried it yesterday.... and it worked!!! Not only is the boot order correct, I can also access the BIOS without any problems!!

Thank you so much for this, you saved my M.2 investment