can't enter bios on Acer Aspire A515-44 - bios very long loading(?)

hukt

On fresh notebook, i could enter bios just fine.
After I installed Win10 and EndeavourOs, i tried: pressing F2, entering by grub loader UEFI firmware settings menu entry, entering by Win10 Recovery-Troubleshooting-UEFI firmware settings.

If notebook supposed to enter bios, it activates fans and at least for hour displays ACER logo without loading bios.

Boot menu at F12 loads without problems.

hukt

megatux said:

PlanetMercury said:

Hi everyone, sorry for resurrecting an "old" topic but this is coming up in Google for people with the same problem.

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:

1. 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:
2. Boot into your Linux install.  From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
3. 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).
4. Delete that entry with *efibootmgr -b 0001 -B*  (where 0001 is the number of the boot entry from the previous step).
5. 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).
6. 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:
7. 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.
8. When prompted if you want to add a boot entry for this, select Yes.
9. 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.

Due to messing around I ended up with some extra entries in the boot order, but that's ok because the one that works is there and is used first.  You can use efibootmgr to further clean up boot entries if you know what you're doing.

Note that the problem may re-appear if you ever need to do a "grub reinstall" in the future, though normal updates just to grub configuration or patches to grub *should* not affect it.

To be clear, there is nothing wrong with the boot entry that Debian or Grub added - the issue was that the Acer device's firmware doesn't seem to like it, not because they don't want you to use alternative OSes but they probably just didn't test it extensively with operating systems other than Windows.

That post helped me. i leave that post there in case someone will struggle with same problem. 

 

Thank you! I didn't ever think that grub bootloader can cause such issues.

JackE

Temporarily disconnect the boot drive as the Grub bootloader sometimes causes this issue. Then try to enter the BIOS with F2 key on startup. The ubuntu forums have recommendations for modifying the bootloader to avoid this problem so I recommended that you join the ubuntu forums and post the issue there.

Easwar

hukt,

Try to do power drain and enter the BIOS again.

hukt

megatux said:

PlanetMercury said:

Hi everyone, sorry for resurrecting an "old" topic but this is coming up in Google for people with the same problem.

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:

1. 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:
2. Boot into your Linux install.  From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
3. 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).
4. Delete that entry with *efibootmgr -b 0001 -B*  (where 0001 is the number of the boot entry from the previous step).
5. 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).
6. 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:
7. 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.
8. When prompted if you want to add a boot entry for this, select Yes.
9. 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.

Due to messing around I ended up with some extra entries in the boot order, but that's ok because the one that works is there and is used first.  You can use efibootmgr to further clean up boot entries if you know what you're doing.

Note that the problem may re-appear if you ever need to do a "grub reinstall" in the future, though normal updates just to grub configuration or patches to grub *should* not affect it.

To be clear, there is nothing wrong with the boot entry that Debian or Grub added - the issue was that the Acer device's firmware doesn't seem to like it, not because they don't want you to use alternative OSes but they probably just didn't test it extensively with operating systems other than Windows.

That post helped me. i leave that post there in case someone will struggle with same problem. 

 

Thank you! I didn't ever think that grub bootloader can cause such issues.

JackE

Thanks for reporting back. Another perhaps easier or quicker workaround is to simply disconnect the boot disk temporarily. This way, the BIOS can't see the problem file in the efi partition and thus can then  be accessed normally with F2 on startup to make other changes.

monkey21

you should be able to enter your uefi just by pressing f12. my laptop came with the bonus of looking for USB bootable flash drives first before proceeding to boot to the ssd so maybe try insert a bootable flash drive

ahiles

hukt said:

megatux said:

PlanetMercury said:

Hi everyone, sorry for resurrecting an "old" topic but this is coming up in Google for people with the same problem.

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:

1. 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:
2. Boot into your Linux install.  From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
3. 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).
4. Delete that entry with *efibootmgr -b 0001 -B*  (where 0001 is the number of the boot entry from the previous step).
5. 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).
6. 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:
7. 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.
8. When prompted if you want to add a boot entry for this, select Yes.
9. 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.

Due to messing around I ended up with some extra entries in the boot order, but that's ok because the one that works is there and is used first.  You can use efibootmgr to further clean up boot entries if you know what you're doing.

Note that the problem may re-appear if you ever need to do a "grub reinstall" in the future, though normal updates just to grub configuration or patches to grub *should* not affect it.

To be clear, there is nothing wrong with the boot entry that Debian or Grub added - the issue was that the Acer device's firmware doesn't seem to like it, not because they don't want you to use alternative OSes but they probably just didn't test it extensively with operating systems other than Windows.

That post helped me. i leave that post there in case someone will struggle with same problem. 

 

Thank you! I didn't ever think that grub bootloader can cause such issues.

same problem with Aspire A317-53