You are not logged in.
Hello everyone,
I'm recently being affected by a very particular issue with my grub UEFI boot entry that I haven't been able to find anyone else having.
I was having the problem of my entries randomly disappearing. The commonly suggested solution to run the grub installer with the
--removableflag seemed to do the trick, however...
On reboot, the motherboard fails at POST since it is unable to find any valid boot entries. However, the second I simply hit the power button and then once more to do a "cold" boot, everything is well. Simply running
powerofffrom inside Arch and then manually pressing the power button to boot works fine as well. It is only on running
rebootfrom inside Arch that I experience this.
The solution that worked for the person at the end of this post didn't work for me and neither does the wiki's suggestion, since I seem to already have the
BOOTx64.EFIfile in said directory. The motherboard is pretty old (Asus M5A99X EVO R2.0) so there aren't really any BIOS updates to speak of in the past 10 years.
I could by all means simply manually reboot every time with the button, but what I am running is a headless machine, so being able to reboot it remotely is pretty important to me.
It is my first time posting, so please excuse me if my board etiquette isn't ideal.
Thank you in advance for your help!
Last edited by Koko210 (2024-08-12 19:52:37)
Offline
although it's a weird behaviour as this is what the fallback path was meant to solve you could also enable wake-on-lan and restart the system over network after poweroff without the need to press the power button
also: as this hints to incompatibility: what type of boot drive is it and is it connected? if sata: have you tried changing the sata-port?
also also: this could be related to some issue with the power supply (don't ask me how - but we had several threads of this kind which were solved by a new power supply)
could also be hardware failure due to age like a blown cap or resistor
in any case - although there's no new version of tge bios available - I wuuld give re-flashing the latest version a try - maybe combined with an nvram flush by removing the battery
Offline
although it's a weird behaviour as this is what the fallback path was meant to solve you could also enable wake-on-lan and restart the system over network after poweroff without the need to press the power button
also: as this hints to incompatibility: what type of boot drive is it and is it connected? if sata: have you tried changing the sata-port?
also also: this could be related to some issue with the power supply (don't ask me how - but we had several threads of this kind which were solved by a new power supply)
could also be hardware failure due to age like a blown cap or resistor
in any case - although there's no new version of tge bios available - I wuuld give re-flashing the latest version a try - maybe combined with an nvram flush by removing the battery
Thank you for the response!
Sadly, it doesn't seem like any of the steps you suggested did the trick. I tried different SATA ports, reflashed the BIOS, reset the CMOS, but to no avail. Although now that I opened up the case I do notice that the BOOT_DEVICE_LED remains on during POST, which I am not sure how to interpret since the device is obviously ok and functioning (when you do a cold boot). There don't seem to be any blown caps or resistors on the motherboard upon close inspection with a flashlight, but obviously it may not be possible to tell with the naked eye.
Wake-on-lan is an option for sure, but I've just had bad experiences with it in the past and I've come to the conclusion that it is rather unreliable.
I suppose if there aren't any other suggestions I may have to invest in a new PSU. It will take a while, but I will come back to report if it helped.
Offline
cryptearth wrote:although it's a weird behaviour as this is what the fallback path was meant to solve you could also enable wake-on-lan and restart the system over network after poweroff without the need to press the power button
also: as this hints to incompatibility: what type of boot drive is it and is it connected? if sata: have you tried changing the sata-port?
also also: this could be related to some issue with the power supply (don't ask me how - but we had several threads of this kind which were solved by a new power supply)
could also be hardware failure due to age like a blown cap or resistor
in any case - although there's no new version of tge bios available - I wuuld give re-flashing the latest version a try - maybe combined with an nvram flush by removing the batteryThank you for the response!
Sadly, it doesn't seem like any of the steps you suggested did the trick. I tried different SATA ports, reflashed the BIOS, reset the CMOS, but to no avail. Although now that I opened up the case I do notice that the BOOT_DEVICE_LED remains on during POST, which I am not sure how to interpret since the device is obviously ok and functioning (when you do a cold boot). There don't seem to be any blown caps or resistors on the motherboard upon close inspection with a flashlight, but obviously it may not be possible to tell with the naked eye.
Wake-on-lan is an option for sure, but I've just had bad experiences with it in the past and I've come to the conclusion that it is rather unreliable.
I suppose if there aren't any other suggestions I may have to invest in a new PSU. It will take a while, but I will come back to report if it helped.
Well, it seems I hadn't done my research as thoroughly as I had thought. I decided to investigate more and found this older post. The final response suggests playing around with the GRUB_CMDLINE_LINUX_DEFAULT parameters in /etc/default/grub, namely the reboot one. The suggestion to set it to pci didn't work for me, though. The link the person provided is not available anymore, but it is archived in the Wayback Machine right here.
At the end of the article, the writer suggests to set reboot to
reboot=warm,cold,bios,smp,triple,kbd,acpi,efi,pci,forcein order to have grub try them all out and to then narrow down which one does the trick for you if the problem is solved.
I don't have the time to do that last part right now, but I will update this post when I get to narrowing down which one fixed it for me.
Offline
is arch the only OS on this system or do you dual-boot with windows?
if dual-boot with windows: https://wiki.archlinux.org/title/Dual_b … ibernation
Offline
Thanks for the suggestion, but nah. No Windows in my household.
Offline