What do mean by this? Memory collisions? Are you talking about a manufacturing defect, software defect, too much wear on the flashrom? Something specific to this model?
1 Like
No it’s the 970 chip. It ran hot, hotter in other configurations, and depending on your cpu, if it’s hot, it can miss a call, start a new one, find the old one, then it doesn’t delete the old one and smash. Idk how it works I just get the cist of it.
Those labels may or may not just be there though. If your uefi setup for your drives, uuid whatever, is not actually copied down, you won’t boot.
So one thing led to another and I installed fedora.
Having done this i unplugged all drives again:
It seems the ghost are alive…
(the udisk doubble is my fedora stick)
(yes I also cleared CMOS inbetween)
Me neither, it is intresting though.
zilch.
The situation isn’t really a problem for me, I can still boot into a drive.
Mainly because I didn’t get to use it much. :v(
Huh, neat. Im not alone.
Everyone I’m sorry to say this mysterium will remain unsolved, at least for me, unless @X8X_Foundries picks it up. His explanation isn’t really satisfying, though it is the most satisfying of the lot, but I’ve run out of patience. I seems that fedora will boot and thats better than windows anyways.
Thanks for the sugestion and ideas; this was fun. Knowing me I’ll come back with some new hardware ghosts sooner rather than later.
1 Like
Ohhhhh OK. I thought you were saying things were listed with nothing plugged in but not booting when plugged in.
My bad
That’s just uefi being… Well, old.
I reckon it’s just the UEFI registering the boot details.
Normally its a case of NVRAM loosing the record for the OS, and when booting, the BIOS reports “no media found, insert disc and reboot” even though drive is plugged in.
For windows, it requires a BCD /fixboot.
For Linux, and grub-update to repopulate the NVRAM list.
I havnt noticed old record remaining after drives removed, but not looked for them.
@Trooper_ish The ghost-ly thing here is that the boot entries were persisting even after clearing NVRAM above; @Zedicus seemed unconvinced that this was actually clearing everything, but we have heard nothing from him since. Every EFI system I have seen or read about stores its boot options in Boot____ entries of the EFI_GLOBAL_VARIABLE. Even Apple’s pre-UEFI EFI systems use this.
The only thing that makes sense to me here is that Gigabyte’s board firmware was caching some information about the boot list somewhere else, and this was no being cleared by the reset that @Young_Venus ran. Maybe @Zedicus knows something weird about this particular motherboard’s NVRAM reset that I do not?
What to do next
I am still not sure what issue @X8X_Foundries is describing, but it may be a good idea to update the firmware with Q-flash (since @BIOS is Windows-only), or at least see if you are running the most recent version. That would be the only real way to fix any true corruption.
Anyway, now that fedora is showing up (twice) in the Gigabyte firmware boot menu, I really want to see what is in efivars. Can you check both efibootmgr and the efivars directory (/sys/firmware/efi/efivars) again?
Edit: by the way, if you really want to experiment with things, it looks like your board is well supported by Flashrom; maybe you could archive its current state? Admittedly, I have not used flashrom myself, and it could be brick your motherboard if you are not careful, but if someone else is searching for this later, be aware that it may be an option.
3 Likes
Nothing new on the efibootmgr front.
[helioscultist@fedora ~]$ ls /sys/firmware/efi/efivars/
AMIMemInfo-43387991-1223-7645-b5bb-aa7675c5c8ef
AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34
EasyTuneSetupAddress-2a64d079-aceb-4ad9-afd5-252e35ba994a
FPDT_Variable-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemContext-c3a4e49f-485f-4fd6-a2ea-2bc87455ad4b
MemContextNv-c3a4e49f-485f-4fd6-a2ea-2bc87455ad4b
MemRestoreConfigId-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemRestoreCpuId-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemRestoreTime-8be4df61-93ca-11d2-aa0d-00e098032b8c
ModuleVersion-8be4df61-93ca-11d2-aa0d-00e098032b8c
MonotonicCounter-01368881-c4ad-4b1d-b631-d57a8ec8db6b
NBMemoryLength-490216c0-076a-44d3-a536-ace05c90e386
NetworkStackVar-d1405d16-7afc-4695-bb12-41459d3695a2
NewBoot0004-17a25442-7009-42df-a6c1-4760a1511ecc
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PNP0400_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0501_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0501_1_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0510_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0604_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PreviousMemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
Ps2KeyboardDetectRecord-5a47386b-4c41-43b6-a140-824b0260ca8d
Ps2MouseDetectRecord-09b5c46a-0f41-4cee-84ff-f3660a0b08d6
Setup-80e1202e-2697-4264-9cc9-80762c3e5863
Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SpdBypassData-8be4df61-93ca-11d2-aa0d-00e098032b8c
SpdBypassSerial-8be4df61-93ca-11d2-aa0d-00e098032b8c
SR5690ASetup-7e7092f3-0103-4948-a14c-9c2526ce773b
StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
Weird; either there is some kind of glitch hiding the Boot variables from the OS, or the Gigabyte firmware is implementing its boot menu in an extremely non-standard way.
We are still seeing some of those EFI_GLOBAL_VARIABLE variables:
FPDT_Variable, MemRestoreCpuId, MemRestoreCpuId, MemRestoreTime, ModuleVersion, PlatformLang, SpdBypassData, SpdBypassSerial, and Timeout; which makes the absence of Boot variables even stranger.
I used to have an am3+ board from Gigabyte. I had the same kind of issue.
Try the following:
- Update/reflash the UEFI. (this alone usually did the trick)
- Remove all power.
- Pull the cmos battery.
This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.