I have a gigabyte ga-970a-ds3p motherboard. I have reset the bios and cleared cmos. There are no drives pluged in at this moment. And yet two bootable drives show up ‘manjaro’ and ‘linux boot manager’:
Doesn’t bios only have rom? what is the battery for otherwise?
Recently the system in which it was running malfunktioned. I suspected the hard drive, as this too was old and are rumored to die prematurely compared to other hardware.
Uppon installing a new hard drive and installing a new os on it, when I tried to boot from the hard drive it didn’t work!
something something no windows installation available. Anyways thats offtopic.
Also apparently the motherboard advertises dual-bios but I don’t get how to switch it, my manual-fu returns nothing.
So what is going on? where do theese ethereal drives live?
Inside your mobo is a computer within a computer. It has its own CPU, RAM and some nand flash storage - a SoC or system on a chip. That is where the UEFI resides. The SoC has been corrupted and thinks it still has stuff connected.
This has pretty much supplanted the old BIOS model that you think your PC still operates on.
Recently the malware has reached even these as well , effectively making your PC permanently infected.
And how would gparted partition disks that dont exist? also coulden’t you use a windows usb to partition all the same?, I say this because I’d have to borrow a friends computer to write gparted on too a usb.
This is why I say: ghosts in the motherboard
(no I don’t actually believe in ghosts, still something is very confounding)
You may be right, the bios might be corrupt somehow.
The question is how.
And I am assuming that isn’t malware, because surely that wouldn’t leave such a wierd artefact?
So say one of the days I was (trying to, I have the worst luck with motherboards) installing manjaro, somehow the BIOS (no I’m not calling it UEFI, it says its called bios so I’ll call it that) ROM somehow got currupted with exactly those two ghost drives?
I have trouble believing that either. But then, I have no better explanaiton.
But you know it is a dual-bios motherboard, if only the manual explained how to switch that would be lovely.
Only on server boards, where this is a BMC; Intel tries to do something similar with its management engine, but I am not sure if it even uses its own RAM or not; regardless, UEFI code runs entirely on the CPU proper. Any ME (or AMD SP/PSP) execution is handling initialisation or tasks that the BIOS/EFI does not have access to.
What are you referring to then? From what I am reading, all EFI variables are stored in NVRAM, not in CMOS like with BIOS.
The reset that @Young_Venus appears to have done should have wiped most if not all of NVRAM. Removing the motherboard RTC battery would clear CMOS if there was any, but you are describing booting into a livecd distro and doing something from there?
Were you thinking of clearing efi variables from within Linux?
Please do call it EFI if that is what it is; BIOS is the nonstandard mess that can vary wildly from OEM to OEM; EFI/UEFI is the Intel standard that, relevant here, at least has some common interfaces to the OS.
Calling it BIOS when asking about a low level problem like this is counterproductive; just as calling your automobile a carriage is not helpful when trying to diagnose engine trouble.
In your case, my guess is that manjaro and Linux Boot Manager are leftover EFI boot entries; if you are able to live boot a linux distro from a CD/DVD/USB, could you try running efibootmgr and report back if it shows anything?
You might need to use that Boot Override if your motherboard still tries to boot the non-existent hard drive.
I should probably also include that the NVRAM that EFI uses is usually just a part of the flashROM. The CMOS storage used by BIOS was battery-powered, and therefore would be erased when the RTC battery died.
@AbstractConcept I guess I can call it UEFI of EFI. I think I was just to unsure about what it actually was to call it anything other than what it was marketed as. Still, that raises the question: why hasen’t this changed why is it still called BIOS by everyone(other than enlightened users that is)?
Back on topic, I remember that I flashed fedora ona stick a while so yes I can do that:
Timeout: 3 seconds
No BootOrder is set; firmware will attempt recovery
this was the output in both user and root.
And yes, of course, boot override mericifully works.
the UUID suffixes are like namespaces for EFI variables, the common one is 8be4df61-93ca-11d2-aa0d-00e098032b8c which is called the EFI_GLOBAL_VARIABLE; vendors can make their own variables under different namespaces, but this is the one that contains most if not all the standard variables