You are not logged in.
Pages: 1
Hello Arch community,
I'm hoping to get some expert insight on a likely firmware issue that I triggered after a manual Arch install. I believe I have diagnosed the root cause, but I'm looking for confirmation and potential software-based solutions before I resort to opening my laptop.
My System:
Laptop: Acer Aspire A315-56
Setup: Dual boot Windows 11 / Arch Linux on a single NVMe SSD.
Sequence of Events:
System was a stable Windows / Ubuntu dual boot. BIOS access via F2 worked perfectly.
I formatted the Ubuntu partitions and performed a clean, manual installation of Arch Linux following the wiki.
After successfully booting into my new Arch install, I can't access to BIOS anymore.
Current Symptoms:
Pressing F2 on boot results in an indefinite freeze on the Acer logo screen.
The F12 Boot Menu works flawlessly. I can select and boot both Windows and Arch from it.
Crucially: Any new changes made with efibootmgr (e.g., deleting other entries, changing the boot order) are not persistent. They revert to the old, corrupted state after a reboot.
Troubleshooting I've Performed:
Hardware Check: Ran smartctl -a on the NVMe drive. The result is PASSED with 0 errors. The drive is perfectly healthy.
File System Check: Ran ntfsfix and fsck.ext4 from a live environment. No errors were found on any partition.
Firmware: The laptop is already on the latest BIOS version available from Acer's support site. Re-flashing from Windows fails due to a file signature error.
Reset Attempt: I have used the battery reset pinhole on the bottom of the case. This did not solve the issue.
My Questions for the Community:
Has anyone experienced similar behavior on Acer or other laptop brands?
Is there any known software-based command or advanced utility within the Arch ecosystem that can force-clear or reset a corrupted NVRAM, as a final attempt before I proceed with a physical CMOS reset (opening the case and disconnecting the battery)?
Thank you for reading this long post. Any advice would be greatly appreciated.
Last edited by Imnotapro (2025-07-27 08:13:32)
Offline
from the numbers of topics about using linux on an acer laptop I guess it's fair to day: unless you're up to an adventure just keep linux away from any acer laptop - they seem to be one oem who screws up thier firmware implementation really hard
one maybe goes a step further with "just stay away from altogether"
anyway - I'm not aware of prebuilt tools able to cause the same effect as what a hard cmos reset causes
in fact a "hard" reset done via a jumper/button or more classic by disconnecting the rtc battery can result in a variety of states that the firmware recognizes as "reset by disconnect of cmos bat" that are not reproducable by software
for instance when software writes to the nvram usually the checksum protecting is also updated by hardwired circuit - a "hard" reset usually results in a checksum failure which in turn usually causes the firmware to restore to default
you could also try to just remove the nvme drive first - most uefi implementations usually check for and remove no longer valid boot entries - removing the drive could result in a wipe of possible bad boot entry regranting you access back into the firmware
overall try to use linux on a mobile not specifically designed for and tested with linux often results in issues as the firmware seem to be somewhat stripped down or otherwise incompatible or faulty
Offline
Thank you again for the fantastic and detailed explanation. Your analysis of the Acer firmware issue and the technical reasons why a hard reset is superior to software methods makes complete sense.
Unfortunately, I'm currently in a situation where I don't have the tools or confidence to open the laptop case. This means that your excellent suggestions of removing the NVMe drive or physically disconnecting the battery are not options for me at this moment.
Given this constraint, my final plan of action will be to try the only hardware-level reset available to me one more time, as thoroughly as possible:
I will use the battery reset pinhole again.
This time, I will press and hold the button for a longer period (30-60 seconds).
After that, I will let the machine rest, completely unplugged, for at least 30 minutes before trying to boot into the BIOS again.
If that still doesn't work, I believe you are correct that the problem is unsolvable without physical intervention. In that case, I will have to accept the issue and live without F2 access, knowing exactly what the root cause is, thanks to your help.
I will report back with the final result. Thank you again for sharing your expertise; it's been extremely helpful in understanding the true nature of this problem.
Offline
sharing from my experience with mobile devices:
- take your time ! - to me this is the most important one; don't rush things - mobile devices are often built quite fragile and can have unexpected latches, screws, clips, cables and over stuff
- second but about as important: don't use force! if something feels like it might break when you keep pulling on it - it usually will - most stuff is made out of cheap briddle plastics and can be glued - this is most important around the battery - as any damage can cause shorts, fires or even worse - this is not a joke!
- if you feel uncomfotable dismantle your device yourself seek for professional help - it is worth paying a few bucks for someone exerienced have a look at it who is able to get it back together than you ripping apart your device and end up with a brick - because a new laptop likely will cost you way more
pitfalls to watch out for:
- keyboard: to take apart a modern laptop it almost always involves some hidden screws beneath the keyboard
it's common to have some screws in the back holding in the keyboard which needs to go first - then lift the keyboard to access the hidden screws - to then finally take apart the case
other times the keyboard can be clipped in (usually three or more spring loaded small hooks to be moved by something flat) and has to be taken out first
- short ribbon cables: devices like the keyboard, trackpad and sometimes additional stuff like card rwaders or usb sockets are on small daughter boards connected via fragile ribbon cables - it's easy to rip them or damage the connectors
- tight fitted cables: this goes mostly for the display cable and the wifi antannas somehow tightly snugged into the hinch area - its easy to damage them which in fact can damage the display panel or the motherboard (happened to - uncool)
along with all this hardware stuff - software can bight you, too
for some stpuid reason many of the big tech companies design for and test with thier devices primarily windows focused and - as you leraned - they somewhat "break" as soon as you try something else
don't waste your time with contact customer support - I even got back "we don't support linux" from hp-enterprise for a device specifically marketed for linux
unless you're Linus "LTT" Sebastian or Stephen "TechJesus / GN" Burke with pretty good connections to thech gurus it's not even worth trying - the big ones don't care if one customer out of thousands sold units has some weird issue
I onced had to blacklist an update on a friends system because it kept failing even following official resolution guide
yes - computers are some nice toys - but sometimes thier manufactures just don't play by thier own rules
Offline
Thank you so, so much for taking the time to write down all this practical advice. This goes way beyond a simple technical answer, and I genuinely appreciate you sharing your hard-earned experience.
Your warnings about patience, not using force, and the dangers around the battery are incredibly valuable, and I will take them very seriously. You've also perfectly captured my frustration with manufacturers who don't seem to fully adhere to their own firmware standards.
Based on your advice and my current situation (not having the proper tools), I've decided it's wisest not to risk opening the case myself. I will try the battery reset pinhole one last time, very thoroughly. If that fails, I will either live with the issue or seek professional help as you suggested.
Thank you again for being so helpful and for looking out for a fellow user. It's people like you that make the Arch community so great.
Offline
Hello everyone,
I'm back with a final update and a complete solution. The problem is now solved. I can access my BIOS with F2, and my Arch/Windows dual boot is working.
A huge thank you to everyone who offered advice. You were all correct: the root cause is a bug in the Acer firmware. It incorrectly handles UEFI boot entries, causing a freeze when trying to access the BIOS setup. I also found another user on the Acer community forums who confirmed this exact behavior.
Here is the step-by-step workaround that fixed my Acer Aspire A315-56, for anyone who finds this thread in the future.
The Problem: The F2 key freezes on the Acer logo. This is caused by a bug in the Acer firmware, triggered when it tries to read a valid Linux EFI boot entry.
The Workaround That Fixed the F2 Freeze:
Force the Acer Firmware to Delete the Problematic Entry: The goal is to make the "arch" boot entry's target file temporarily disappear, which causes this specific firmware to remove the entry from its boot list.
Boot into Windows.
Open Command Prompt as Administrator.
Mount the EFI partition: mountvol S: /S
Navigate to the Arch bootloader directory: S: then cd EFI\arch
Temporarily rename the bootloader file: ren grubx64.efi grubx64.efi.bak
Verify the Fix: After renaming the file, reboot and press F2. The BIOS should now be accessible because the firmware has removed the entry that was causing it to freeze.
Restore the Arch Boot Entry:
I booted into a GParted live environment.
First, I renamed the file back to its original name (grubx64.efi).
Then, using efibootmgr, I created a brand new boot entry for Arch, since the old one was deleted by the firmware.
The Final Result and Secure Boot Status (This is important):
After creating a new boot entry for Arch, the F2 freeze bug does NOT return! The BIOS remains accessible, which is a huge success.
However, this leads to the final choice that all users will have to make:
Option A (Secure Boot OFF): If I disable Secure Boot in the BIOS, I can boot into my restored Arch Linux perfectly. This is the simplest path to a working system.
Option B (Secure Boot ON): If I enable Secure Boot, the system shows a "Reset system" error when I try to boot Arch. This is the expected behavior because the standard GRUB is not signed. To make this work, one would need to proceed with the full sbctl/shim process to create and enroll their own keys.
So, the critical F2 freeze is fixed permanently. The remaining issue is just the standard challenge of making a manual Linux install work with Secure Boot.
Thank you all again for your help in tracking down this very frustrating firmware bug.
Offline
well, as for SecureBoot:
my personal opinion is: don't bother with it - there's nothin that really requires it (aside from a few game anti-cheats - but if a game becomes that intrusive even require secureboot to be enabled I would just stop playing such game to not further support that)
currently SecureBoot only protects boot code, kernel and drivers (both Linux and windows) - but that's it - when you reach user land you can execute any code anyway
SecureBoot COULD be a useful tool - but only if it would go further than just the os core but also into user land so only signed and authorized applications would be allowed to be executed
unless it's used in such a way it's just some marketing bullshit mostly microsoft pushed to get thier foot back into earning from hardware sells - as that's still what they rely on since back of the original ibm/ms-dos deal - same as with all that TPM fuzz: a regular user just can't make proper use of one
anyway - glad you were able to fix the issues and many thanks for such an extensive reply so it might can help others with similar issues
Offline
Pages: 1