Contribute
Register

<< Solved >> How to reset System Information back to default mobo values

Status
Not open for further replies.
Yeah that’s the crazy thing - all drives are removed except the Ubuntu usb. And memtest86 is still pulling in Apple SMBIOS info. I’ll boot into Ubuntu later and see what it has to show. If it shows in Ubuntu then the board has something modified.

It may not have been clover that did that, as I’ve hacked this rig multiple times over the years, even before clover was a thing.

One last arm wave...

Does memest write any config file that it then looks for on later runs?

Like what if you ran mentest under an injected loader and it made some helpful notes to itself and put them in a file on some partition, then you changed to a more benign loader but when memtest starts it picks up the notes for previous config.

...This is truly just wild guessing

Best luck
 
Okay... here's the deal. I flashed the BIOS four times... FOUR TIMES. I put Ubuntu on a fresh, clean, never-before-used USB. Booted into Ubuntu and opened Terminal. dmidecode. This lists out all the hardware that's relevant. Everything is showing APPLE! There's something effed with this mobo.
ubuntu@ubuntu:~$ sudo dmidecode
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
75 structures occupying 2899 bytes.
Table at 0x000E96E0.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: MultiBeast.tonymacx86.com
Release Date: 11/14/2017
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 4096 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Apple Inc.
Product Name: iMac13,3
Version: 1.0
Serial Number: [redacted]
UUID: [redacted]
Wake-up Type: Power Switch
SKU Number: Default SKU#
Family: iMac

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Apple Inc.
Product Name: Mac-F42C88C8
Version: To be filled by O.E.M.
Serial Number: SOMESRLNMBR
Asset Tag: Default Asset Tag#
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: Apple Inc.
Type: Sub Chassis
Lock: Not Present
Version: To Be Filled By O.E.M.
Serial Number: SOMESRLNMBR
Asset Tag: Default Asset Tag#
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: To be filled by O.E.M.
 
I am not able to provide a solution but curiosity got me digging for info for a few minutes:

The lore on this is that DMI/SMBIOS data is a board-maker defined capability, which some provide user-access support and others don't. The way it's supported (or not) is completely up to the mainboard maker and BIOS supplier.

Look for a stackexchange.com article on "How to Change OEM Vendor Info" which surveys the topic.

At some point, you must have wittingly or unwittingly used a tool that can write DMI info. Maybe you chose that board because at that time hacks depended on this capability? But then, if you knew that, you wouldn't have to ask questions here?

I saw a Windows tool called RWEverything, which is no longer maintained, and it looks like it has a steep learning curve, but if nothing else the thinking might lead you to additional resources. Clearly there is a culture that groks this stuff, but having been a regular on this board for a year, I haven't come across any discussion about it.

While searching I came across hackintosh articles from Pike's Universum, for whom the WEG "pikera" boot option gets its name... Since OpenCore, and the modularity and ease with which it and supporting modules offer to hackintoshers, it looks like a the level of lore you need has been sequestered. Might need to learn google search tricks to uncover old lore.
 
I am not able to provide a solution but curiosity got me digging for info for a few minutes:

The lore on this is that DMI/SMBIOS data is a board-maker defined capability, which some provide user-access support and others don't. The way it's supported (or not) is completely up to the mainboard maker and BIOS supplier.

Look for a stackexchange.com article on "How to Change OEM Vendor Info" which surveys the topic.

At some point, you must have wittingly or unwittingly used a tool that can write DMI info. Maybe you chose that board because at that time hacks depended on this capability? But then, if you knew that, you wouldn't have to ask questions here?

I saw a Windows tool called RWEverything, which is no longer maintained, and it looks like it has a steep learning curve, but if nothing else the thinking might lead you to additional resources. Clearly there is a culture that groks this stuff, but having been a regular on this board for a year, I haven't come across any discussion about it.

While searching I came across hackintosh articles from Pike's Universum, for whom the WEG "pikera" boot option gets its name... Since OpenCore, and the modularity and ease with which it and supporting modules offer to hackintoshers, it looks like a the level of lore you need has been sequestered. Might need to learn google search tricks to uncover old lore.
Thanks for that. I will do some digging. Back when hacks first started coming around, you'd have to patch DDSTs. Maybe I had to do that... IDK it's been a decade!
 
Last edited:
SOLVED!!! I loaded the backup bios and thankfully it wasn’t messed with! Apparently a decade ago when I first hacked my pc I had to use DSDT edits to patch the BIOS and I’ve forgotten/don’t know how to remove them. If all else fails load the backup bios!! Ctrl+F10 at POST will allow you to copy backup UEFI to the main bios chip (Use the F12 key for legacy BIOS). And if you ever want to backup your UEFI, use Alt+F10 on boot, or again use F12 key for legacy bios).

If you’re in a Gigabyte boot loop like I was where you can’t get to POST or BIOS, the pc just gets power shuts down and repeats, your BIOS/UEFI is corrupt. To get the system to boot from the backup BIOS, you need to remove the power cable from the power supply (or flip the switch off), plug it back in (or turn power supply switch on), press AND HOLD the power button to turn your pc on, continue holding until the pc shuts itself off, wait 10 seconds, and press the power button to turn pc on. You will get a message that say main bios is corrupt and it will automatically move the backup bios to the main chip and reboot. If this doesn’t happen, repeat procedure a few times.
 
Last edited:
Genius!
Brilliant!
 
Status
Not open for further replies.
Back
Top