ProductKey clique aqui para descobrir o serial do windows! click here to discover the windows serial!
Para usuários da comunidade inglesa, espanhola, francesa e alemã, usarei o google tradutor!
Cannot access BIOS my new A515-55-564P laptop
laserboy417
Member Posts: 11
Tinkerer
I installed openSUSE linux on my new A515-55-564P laptop alongside Windows10 and as part of the installation allowed openSUSE to create it's own EFI partition, in addition to the Windows EFI partition. Everything worked well. On start up I got the openSUSE standard grub menu which allowed me to choose to boot either openSUSE or Windows. I could access the BIOS on startup using the F2 key and I could also access the UEFI boot menu using the F12 key. Today I decided that I'd like to try Fedora32 linux and so installed it alongside the other 2 operating systems, choosing to use the existing openSUSE created EFI partition mounted on /boot/efi. On restarting after installation, I now got the Fedora grub menu, showing options to boot Fedora, Windows or openSUSE. Fedora booted up fine, so did Windows, but openSUSE wouldn't boot. If I restarted using the F12 key to access the UEFI boot menu and chose openSUSE the openSUSE grub menu appeared and I could boot openSUSE or Windows but not Fedora. I accessed the BIOS and set the UEFI boot menu order with Fedora at No.1. Since doing that I can no longer access the BIOS using the F2 key, all I get is the Acer logo splash screen and it hangs with fan working fairly hard, indicating that the CPU is doing something. I can still use the F12 key to access the UEFI boot menu. Can anyone offer any suggestions on how I can get back into the BIOS. The only option I can think of is to delete all my linux created disk partitions and then run Windows recovery, but is this likely to do the trick? And is there a less drastic option?
{ edited the title to add model name }
{ edited the title to add model name }
0
Best Answer
-
Nice to hear from you again egydiocoelho, but I didn't take your advice, which sounded a bit too drastic!JackE, thanks for pointing me to that link, it provided the answer to my problem. I won't go through the process that I followed in detail. In essence this is what I had to do:Deleted the Fedora disk partition (after having these problems I didn't want to persist with Fedora at this time).In openSUSE deleted the /boot/efi/EFI/fedora folderRestarted. Still couldn't access BIOS. Boot Manager Menu shows: 1.openSUSE 2.opensuse-secureboot 3.Windows Boot Manager. The openSUSE entry, which is the default, won't boot, with a message saying that the vmlinuz file has an invalid signature.Booted openSUSE from opensuse-secureboot. Deleted all the old kernel files from /boot so that they are not confusing things. Checked efibootmgr and found that the entry for openSUSE points to /boot/efi/EFI/opensuse/grubx64.efi, whereas opensuse-secureboot points to a shim.efi file. Remembered seeing something about needing to use shim.efi files in a secure boot environment (I have secure boot enabled in the BIOS), so renamed grubx64.efi to make it inactive and deleted the openSUSE entry in boot manager using efibootmgr.Rebooted and hey presto up came the openSUSE grub boot menu. Rebooted, pressing F2 and the BIOS manager appeared. So I am now back to where I was before I installed Fedora. I wonder if it would have been better to have created a separate EFI partition for Fedora in addition to the ones for openSUSE and Windows? Maybe I'll check that out another time.Once again thanks for your help guys - another win for the community!2
Answers
-
The least drastic way is to disconnect the ssd or hdd and then execute the changes to the bios? Now, after pressing f12, can you also start windows?Oi! Eu não sou sou a cortana! Mas estou aqui para ajudar! Hi! I'm not the cortana! But I'm here to help!
Se você gostou da minha resposta, marque como solução clicando em sim! If you liked my answer, mark it as a solution by clicking on yes!
Aceite somente a resposta que ajudou a solucionar o seu problema! Please accept only the response that helped to solve your problem!
Detection tool click here to find the serial number or partnumber of your model!
egydiocoelho
TrailblazerFor users of the English, Spanish, French and German community, I will be using google translator!
ProductKey clique aqui para descobrir o serial do windows! click here to discover the windows serial!
Para usuários da comunidade inglesa, espanhola, francesa e alemã, usarei o google tradutor! 0 -
A reported fix for similar Debian boot manager interference with accessing the BIOS . https://community.acer.com/en/discussion/comment/912766/#Comment_912766Jack E/NJ
Jack E/NJ
0 -
Nice to hear from you again egydiocoelho, but I didn't take your advice, which sounded a bit too drastic!JackE, thanks for pointing me to that link, it provided the answer to my problem. I won't go through the process that I followed in detail. In essence this is what I had to do:Deleted the Fedora disk partition (after having these problems I didn't want to persist with Fedora at this time).In openSUSE deleted the /boot/efi/EFI/fedora folderRestarted. Still couldn't access BIOS. Boot Manager Menu shows: 1.openSUSE 2.opensuse-secureboot 3.Windows Boot Manager. The openSUSE entry, which is the default, won't boot, with a message saying that the vmlinuz file has an invalid signature.Booted openSUSE from opensuse-secureboot. Deleted all the old kernel files from /boot so that they are not confusing things. Checked efibootmgr and found that the entry for openSUSE points to /boot/efi/EFI/opensuse/grubx64.efi, whereas opensuse-secureboot points to a shim.efi file. Remembered seeing something about needing to use shim.efi files in a secure boot environment (I have secure boot enabled in the BIOS), so renamed grubx64.efi to make it inactive and deleted the openSUSE entry in boot manager using efibootmgr.Rebooted and hey presto up came the openSUSE grub boot menu. Rebooted, pressing F2 and the BIOS manager appeared. So I am now back to where I was before I installed Fedora. I wonder if it would have been better to have created a separate EFI partition for Fedora in addition to the ones for openSUSE and Windows? Maybe I'll check that out another time.Once again thanks for your help guys - another win for the community!2
-
>>> I wonder if it would have been better to have created a separate EFI partition for Fedora in addition to the ones for openSUSE and Windows? Maybe I'll check that out another time.Congrats on your success on getting back to square 2. I think you should go for square 3 again now. Jack E/NJ
Jack E/NJ
1 -
Hmm..... I've playing around with efibootmgr, the BIOS and files in /boot/efi/EFI and also doing some more research into the UEFI boot process.This is what I've found based on the InsydeH20 BIOS on my Aspire A515-55-564P laptop and the openSUSE Tumbleweed Linux I have installed alongside Windows10:Changing things in efibootmgr, for example changing the boot order or deleting an entry does not always change what comes up in F12 Boot Manager after a reboot.It looks as though, on start up, the BIOS EFI boot manager searches for certain EFI boot files in order to generate the menu of boot options irespective of what is shown in efibootmgr.I have now installed both openSUSE Tumbleweed and Manjaro (both with their own EFI disk partition) and in both cases a folder with the name of the distro is created in /boot/efi/EFI (e.g. /boot/efi/EFI/opensuse) that contains (among others) the file grubx64.efi. In both cases if this file exists, then on reboot I cannot access the BIOS via F2 (or any other means). So this would seem to be an Acer or Insyde (the provider of the BIOS) glitch, unless this is a deliberate 'feature' for some non-apparent security reason.So now I know what to do to get back into the BIOS.However, every time that grub-install runs in openSUSE (haven't tried Manjaro yet), it puts a grubx64.efi file into /boot/efi/EFI/opensuse, which means that I have to go in and rename or delete it, which is a pain.The interesting thing is that I can boot both distros without the presence of the grubx64.efi in their respective EFI sub-folders, so why are they there?Both openSUSE and Manjaro, as part of the grub-install probing process, will find the other distro and write what looks like perfectly valid entries for the other distro (as well as the Windows chain loader) into the grub menu, but if I run, say, the Manjaro grub menu (choosing Manjaro in the F12 BIOS Boot Manager opens the Manjaro grub boot menu), then choose openSUSE it will not boot because it says it can't find a kernel at the location specified. The same thing happens if I choose openSUSE in the F12 Boot Manager, then choose Manjaro from the openSUSE grub menu. This is annoying because if I don't want to run the distro I have chosen as default in the BIOS, I have to remember to hit the F12 key on startup, rather than waiting for the grub menu to appear and choosing the distro I want. If anyone out there knows the answer to this conundrum I love to hear it
0 -
>>>I can boot both distros without the presence of the grubx64.efi in their respective EFI sub-folders, so why are they there? >>>They're there for machines that won't boot without grubx64.efi being present.>>>choosing Manjaro in the F12 BIOS Boot Manager opens the Manjaro grub boot menu), then choose openSUSE it will not boot because it says it can't find a kernel at the location specified. The same thing happens if I choose openSUSE >>>Seems like each distro's grub is looking at its own grub configuration file in boot/grub. Right now each only accomodates an alternate WIN boot, not the other distro boot. And the kernel locations in the two grub.cfg files are different. So I'd guess that the two grub.cfg files would need to be modified to accomodate the additional alternate distro boot.Jack E/NJ
Jack E/NJ
0 -
A schoolboy error on my part. When I installed Manjaro I was so keen to see if I could boot it and whether it would affect my ability to access the BIOS, that I didn't install the post installation updates. I booted openSUSE and ran grub install (actually the bootloader application in Yast) to include Manjaro in the openSUSE grub menu. Once I'd checked out how everything was behaving, I then booted Manjaro and did the post installation updates, which included a new kernel. So then the openSUSE grub menu was pointing to the old (deleted) kernel and so Manjaro would not boot from the openSUSE grub menu - doh! I've now fixed it and Manjaro will boot from the openSUSE grub menu and, of course, the boot manager menu.I still can't boot openSUSE from the Manjaro grub menu and have checked that it is pointing to the correct openSUSE kernel, so it needs more investigation.Manjaro will only boot if Secure Boot is disabled (they do not provide a shim.efi file) and I can only access the BIOS if the Manjaro grubx64.efi file is renamed. Interestingly when I look at efibootmgr -v the Manjaro entry points to the renamed grubx64.efi file (I named it xgrubx64.efi), so Manjaro does need the grubx64.efi file, but it does not have to be named that. Not altogether surprising, as the /boot/efi/EFI/Manjaro folder only contains that one file. My guess is that distros that can operate under Secure Boot and provide a shim.efi file, use that to point to another efi file (/boot/efi/boot/bootx64.efi??) and that the /boot/efi/EFI/distro-name/grubx64.efi is there for if there is no shim file i.e. a sort of default or fallback option provided by grub.Is there anywhere a document that describes in detail the whole secure boot, uefi, grub process from start to finish, using reasonably simple layman's terms? The grub manual doesn't fit the bill nor does the very interesting Rod's Books document https://www.rodsbooks.com/efi-bootloaders/secureboot.html. For me both assume too much prior knowledge on the part of the reader.
0 -
A schoolboy error on my part. When I installed Manjaro I was so keen to see if I could boot it and whether it would affect my ability to access the BIOS, that I didn't install the post installation updates. I booted openSUSE and ran grub install (actually the bootloader application in Yast) to include Manjaro in the openSUSE grub menu. Once I'd checked out how everything was behaving, I then booted Manjaro and did the post installation updates, which included a new kernel. So then the openSUSE grub menu was pointing to the old (deleted) kernel and so Manjaro would not boot from the openSUSE grub menu - doh! I've now fixed it and Manjaro will boot from the openSUSE grub menu and, of course, the boot manager menu.I still can't boot openSUSE from the Manjaro grub menu and have checked that it is pointing to the correct openSUSE kernel, so it needs more investigation.Manjaro will only boot if Secure Boot is disabled (they do not provide a shim.efi file) and I can only access the BIOS if the Manjaro grubx64.efi file is renamed. Interestingly when I look at efibootmgr -v the Manjaro entry points to the renamed grubx64.efi file (I named it xgrubx64.efi), so Manjaro does need the grubx64.efi file, but it does not have to be named that. Not altogether surprising, as the /boot/efi/EFI/Manjaro folder only contains that one file. My guess is that distros that can operate under Secure Boot and provide a shim.efi file, use that to point to another efi file (/boot/efi/boot/bootx64.efi??) and that the /boot/efi/EFI/distro-name/grubx64.efi is there for if there is no shim file i.e. a sort of default or fallback option provided by grub. Having read https://www.rodsbooks.com/efi-bootloaders/principles.html I now realise that it is exactly that, a fallback.
0 -
I have an Aspire R3-431T and am trying to install "CloudReady" OS but I cant find the boot menu key on my machine. User manual not much help.
0 -
If the F12 boot option is enabled in the BIOS menu, you insert the bootable CloudyReady installation stick, turn on the machine and immediately start tapping the F12 key to boot from the stick.
Jack E/NJ
0 -
A schoolboy error on my part. When I installed Manjaro I was so keen to see if I could boot it and whether it would affect my ability to access the BIOS, that I didn't install the post installation updates. I booted openSUSE and ran grub install (actually the bootloader application in Yast) to include Manjaro in the openSUSE grub menu. Once I'd checked out how everything was behaving, I then booted Manjaro and did the post installation updates, which included a new kernel. So then the openSUSE grub menu was pointing to the old (deleted) kernel and so Manjaro would not boot from the openSUSE grub menu - doh! I've now fixed it and Manjaro will boot from the openSUSE grub menu and, of course, the boot manager menu.I still can't boot openSUSE from the Manjaro grub menu and have checked that it is pointing to the correct openSUSE kernel, so it needs more investigation.Manjaro will only boot if Secure Boot is disabled (they do not provide a shim.efi file) and I can only access the BIOS if the Manjaro grubx64.efi file is renamed. Interestingly when I look at efibootmgr -v the Manjaro entry points to the renamed grubx64.efi file (I named it xgrubx64.efi), so Manjaro does need the grubx64.efi file, but it does not have to be named that. Not altogether surprising, as the /boot/efi/EFI/Manjaro folder only contains that one file. My guess is that distros that can operate under Secure Boot and provide a shim.efi file, use that to point to another efi file (/boot/efi/boot/bootx64.efi??) and that the /boot/efi/EFI/distro-name/grubx64.efi is there for if there is no shim file i.e. a sort of default or fallback option provided by grub. Having read
0 -
Hi BrianBernon,As you can see, my original post and subsequent comments were related to installing Linux distros and they way they work with EFI.If JackE's comment does not solve your problem and you have Linux installed, then take a look in /boot/efi/EFI, find the folder named for your Linux distro and if there is a filed named grubx64.efi in that folder then rename it to e.g. xgrubx64.efi. Restart your computer and you should be able access the BIOS using the F2 key. As JackE points out, if you insert a bootable usb stick, then start the computer and repeatedly press F12 you should get into the BIOS EFI start menu which should have an entry for the USB stick, which you can choose to boot the operating system on the stick. This should work irrespective of whether there is a grubx64.efi file already in the /boot/efi/EFI folders.Hope this helps.0
