Voodooprojects
Chameleon => General Discussion => Topic started by: gmacman on April 24, 2009, 05:41:12 PM
-
Pardon the noob question but I've been searching high and low looking for what things I can add to the SMBIOS.plist. I found some items which have been very helpful (mainly about system type (i.e., iMac/Mac Pro) and memory speed, type, etc.).
But I am trying to resolve the UUID issue (error 35's) that I had fixed when I was using Chameleon v1 with Superhai's SMBIOSResolver.kext. However, I was lead to believe that I no longer should be using it or any SMBIOS injector (I think that's the right term).
Again, I'm a noob so I'm trying to piece together how and where to apply the fix. I believe what I need to do now is add something to the SMBIOS.plist, the question is what. I've been searching constantly within Insanelymac forums for anyone else who has my exact problem but all the posts are from people prior to April (and thus prior to Chameleon v2).
Any help would be greatly appreciated, but I am a noob so please talk slowly. ;)
Moderator Edit: Changed title to reflect the actual topic being discussed. Please write your titles accordingly and help keep the forums coherent so we can all come back and find useful information & solutions.
Moderator Edit 2: Thread cleaned, irrelevant posts removed. This is the most popular thread in the forum, started with a misleading title, and now (as of the current version: 2.0RC-r431) contains 3 solutions to overcome the UUID errors. For anyone watching it since its previous title: the Dev.Team confirmed that UUID from SMBIOS is not a solution.
Please post only verified-working solutions. Not all hacks are built alike. Most of the times, a complete solution would include both UUID.kext and EFI/hex strings.
-
Hi,
to solve your UUID issue (sorry lost the link ::)), you have to edit your /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist.
-- add the missing FireWire Networkinterface, which is causing this error ---
<dict>
<key>BSD Name</key>
<string>en3</string>
<key>IOBuiltin</key>
<false/>
<key>IOInterfaceType</key>
<integer>6</integer>
<key>IOInterfaceUnit</key>
<integer>3</integer>
<key>IOLocation</key>
<string></string>
<key>IOMACAddress</key>
<data>
ABbPoF5V
</data>
<key>IOPathMatch</key>
<string>IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/P0P3@1C,2/
IOPCI2PCIBridge/pci14e4,4311@0/AirPort_Brcm43xx/IO80211Interface</string>
<key>SCNetworkInterfaceType</key>
<string>IEEE80211</string>
</dict>
PS.: <string>IOService: ... is one line till next </string>
<string>en3</string> //en3 depends on the number of Networkinterfaces in you computer
greetings
-
Thanks. I've seen that solution before but I never it got it to work in my other machine and went with the SMBIOSResolver (at least I think that's what fix my problem with the machine running Chameleon v1). Regardless, my ultimate goal is to try to keep things as vanilla as possible on my system and (hopefully) just use the /Extra/Extensions folder with Chameleon v2 to help resolve this issue.
-
I got this solved placing UUID.kext into /Extra/Extensions folder.
Don't know if it's the best solution, but at least seems cleaner.
Cheers!
-
I got this solved placing UUID.kext into /Extra/Extensions folder.
Don't know if it's the best solution, but at least seems cleaner.
Cheers!
Many thanks! Definitely the "cleaner" solution I was looking for. I took a minor additional step and used a little app I found called UUID Generator to create a unique one and then copy and pasted it into the Info.plist within the UUID.kext. Probably not necessary but I have two hackintoshes and thought there might be something screwy if they both used the same UUID.
For anyone else looking to solve UUID error 35's, mine were exclusively at boot and caused (IMO) by the use of a pci NIC card, here are those two files (UUID Generator app and the UUID.kext). Not positive that this is the cause of UUID errors but I read somewhere that OS X generates a specific UUID (there are several, one for each HD, one for each user account, etc.) by using the MAC Address of the onboard NIC. Since I don't use the onboard NIC, I'm thinking that's why I'm getting all the errors.
Regardless, this solution got rid of the errors and does not seem to have any side effects, so once again thanks skydrone!!! :)
-
I too am missing instructions howto manual or such that explains what exactly the SMBIOS.plist is for and what it can be used for.
But also, what are these UUID.kext and the UUIDGenerator.app generates a UUID for what device/property?
I can run it, and I get a UUID string, but I wouldn't know what it's for, or where to put it...
-
But also, what are these UUID.kext and the UUIDGenerator.app generates a UUID for what device/property?
I can run it, and I get a UUID string, but I wouldn't know what it's for, or where to put it...
The issue for me (and why I posted those) were because I was constantly getting UUID errors during my boot. I believe (but am not sure) that the UUID error was caused by the fact that OSX generates a UUID from the onboard NIC's MAC Address. Because I use a NIC card and ignore the onboard NIC of my motherboard this caused a problem.
The UUID.kext resolves this problem. It has a UUID within it's Info.plist. I took a step further by generating my own unique UUID and put it in the Info.plist (in essence modifying the kext). This is not really necessary and you can merely use the UUID.kext without doing this if it sounds too much like voodoo (pardon the pun).
However, if you are not getting any UUID errors during boot, there is no need for this kext.
-
Thanks for the explanation. Is that UUID suposed to be unique to a specific INSTALL, or for a specific to a piece of HARDWARE?
-
Thanks for the explanation. Is that UUID suposed to be unique to a specific INSTALL, or for a specific to a piece of HARDWARE?
Keep in mind I'm not an OSX engineer (although I suppose none of the hackintosh folks can classify themselves as even been close to that), but I believe the specific UUID that causes errors during the boot process is for the installed version of OSX but it is created by utilizing unique hardware (i.e., it's based on some random information, the MAC address, of the onboard's NIC).
-
Thanks for the explanation. Is that UUID suposed to be unique to a specific INSTALL, or for a specific to a piece of HARDWARE?
Keep in mind I'm not an OSX engineer (although I suppose none of the hackintosh folks can classify themselves as even been close to that), but I believe the specific UUID that causes errors during the boot process is for the installed version of OSX but it is created by utilizing unique hardware (i.e., it's based on some random information, the MAC address, of the onboard's NIC).
When I verbose boot, I see some messages about UUID stuff, but the system works just fine. So is there anything that didn't work without that kext, or is this just a cosmetic thing to get rid of meaningless error messages?
Ronald
-
Is that UUID suposed to be unique to a specific INSTALL, or for a specific to a piece of HARDWARE?
- Wikipedia: Universally Unique Identifier (http://en.wikipedia.org/wiki/Universally_Unique_Identifier)
- Apple Technical Note: Uniquely Identifying a Macintosh Computer (http://developer.apple.com/technotes/tn/tn1103.html)
When I verbose boot, I see some messages about UUID stuff, but the system works just fine. So is there anything that didn't work without that kext, or is this just a cosmetic thing to get rid of meaningless error messages?
No, it's not only cosmetic. The onboard NIC on my hack kind of works OK out of the box after a retail installation. No UUID errors @ boot time.
Upon further investigation and by observing the system.log, I found out that while basic networking was OK, I was experiencing various hiccups with AFP permissions, Bonjour (mDNS) not starting, etc. The UUID.kext seems to fix that.
Here's a (newbie-friendly, step-by-step) guide to make use of UUID.kext (adapted from a post somewhere inside insanelymac's labyrinth):
red = Terminal command
01) Download UUID.kext.zip from this thread, unzip it and place it on your desktop
02) Find your Ethernet MAC address (there's a zillion ways to do this), one of the simplest is to find it in System Profiler-->Network:
(http://i39.tinypic.com/2d8oz9x.png)
03) Right-click on UUID.kext and take a look inside:
(http://i39.tinypic.com/35luop4.png)
04) Open Info.plist with your favorite editor:
(http://i43.tinypic.com/1418tbt.png)
05) Paste/type your Ethernet MAC address in the corresponding string (last batch of numbers) without the semicolons, under <key>UUID</key>:
(http://i41.tinypic.com/2cxb5w4.png)
06) Exit your editor and copy your own modified UUID.kext to your /Extra folder
07) Fix permissions for the UUID.kext, from Terminal:
sudo chown -R root:wheel /Extra/Extensions/UUID.kext
chmod -R 755 /Extra/Extensions/UUID.kext
(Feel free to make a kextcache (/Extra/Extensions.mkext) if you like, otherwise you're ready to boot)
08) Verify that UUID errors are history by either:
• booting with -v (verbose mode) and observing the messages flying by
• booting normally and typing sudo dmesg from the Terminal
• booting normally and observing the messages of Utilities-->Console-->system.log
Aside from the errors @ boot time, UUID.kext should also fix misc. AFP (FileSharing) & Bonjour (mDNS) errors usually visible only from system.log
-
See this other thread (http://forum.voodooprojects.org/index.php/topic,315.0.html), it seems chameleon can also do UUID injecting on smbios.plist, I havent tried it yet (not on my OS X comp right now) but it may help fix those UUID error 35 messages...
-
See this other thread (http://forum.voodooprojects.org/index.php/topic,315.0.html), it seems chameleon can also do UUID injecting on smbios.plist, I havent tried it yet (not on my OS X comp right now) but it may help fix those UUID error 35 messages...
That (SMUUID) is a different thing, not related to the issue being discussed here, because OS X uses the MAC of the built-in NIC to generate it and it doesn't get it from SMBIOS
But one could make use of it, *if* you have a good implementation of SMBIOS in your firmware.
-
See this other thread (http://forum.voodooprojects.org/index.php/topic,315.0.html), it seems chameleon can also do UUID injecting on smbios.plist, I havent tried it yet (not on my OS X comp right now) but it may help fix those UUID error 35 messages...
That (SMUUID) is a different thing, not related to the issue being discussed here, because OS X uses the MAC of the built-in NIC to generate it and it doesn't get it from SMBIOS
But one could make use of it, *if* you have a good implementation of SMBIOS in your firmware.
Hm, the SMBIOS spec v2.6.1 describes the structure of the SMBIOS UUID, and it does refer to the MAC address.
So IF (and I don't know if) MacOS use SMBIOS properties, the SMBIOS use and the fact that the MAC address is used is no contradiction.
In fact, the original spec for UUID always had the MAC of the generating computer there, and the front was time based. Some applications of UUIDs however asked for privacy rather than for identification of hardware, so that's when a pseudo-random number based UUID standard was published. The two coexist, and if you read up on UUIDs e.g. on wikipedia, you see how you can identify which kind of UUID you're using.
I was planning to use the UUID generator available here: http://www.hsoi.com/hsoishop/software/
which has an option to generate MAC/time based UUIDs, or are you saying Apple is using "time zero" in their UUIDs, or were you just "too lazy" to fill in the front, and left them all zero? From the wikipedia article, there are issues with all zero UUID components, because they have special meaning.
I still think, if it's not yet happening, that the proper way of dealing with this would be if this were taken from the SMBIOS, and if MacOS doesn't do it, then this kext should be written in such a way that instead of taking the UUID from the plist, it should request it from the BIOS. Just my $0.02
-
See this other thread (http://forum.voodooprojects.org/index.php/topic,315.0.html), it seems chameleon can also do UUID injecting on smbios.plist, I havent tried it yet (not on my OS X comp right now) but it may help fix those UUID error 35 messages...
That (SMUUID) is a different thing, not related to the issue being discussed here, because OS X uses the MAC of the built-in NIC to generate it and it doesn't get it from SMBIOS
But one could make use of it, *if* you have a good implementation of SMBIOS in your firmware.
Sorry but I dont understand fully, lets see if I can make all this clear:
- superhai's SMBIOS enabler kext had a UUID field injecttion that fixed those error 35 gethostuuid when booting.
- SMUUID injection done by chameleon doesnt fix it (for me at least).
- chameleon's & superhai's injected values are different UUID entities even though named the same?
Is that correct?
Can we use the SMUUID injected in chameleon to fix error 35 get uuid from host failed errors?
-
Again;
... OS X uses the MAC of the built-in NIC to generate it and it doesn't get it from SMBIOS
SM in SMUUID stands for SMBIOS. IOPlatformUUID is generated from the MAC address not from the UUID present in the SMBIOS (SMUUID key in Chameleon/smbios.plist).
Don't get confused/misled by modified AppleSMBIOS kexts (or SMBIOSResolver for that matter) setting the IOPlatformUUID.
-
So both uuid.kext and the SMUUID value in smbios.plist do the same function? :-\
thanx for the help kabyl and all the other programmers/repliers!
-
Do make this easy to everybody, forget the UUID from SMBIOS. It is not used for anything. What matter is the IOPlatformUUID or also called HostUUID. I think part of this confusion is because when I added the PlatformUUID fix to SMBIOSResolver, many come to believe it was related to SMBIOS which it is not.
-
hmm, not sure why you still keep setting UUID both from smbios.plist + UUID.kext since (as far as Chameleon is concerned), the devs confirmed that SMBIOS does not matter.
hacks have a fake EFI and totally different (butchered) firmware than Macs, as you tried before, issuing nvram -p from a Mac and a Hack, return totally different results
Well, that's not even the issue. Sinve I set the UUID to be exactly the same both in smbios.plist and UUID.kext.
So I'm not sure that both are setting it or only the UUID.kext.
What I'm wondering is where that stray IOPlatformUUID comes from that has no resemblance to anything I set, or for that matter, to any MAC address present in my system (and I compared it to AirPort, ethernet and BT PAN MAC addresses).
Further, whatever sets it, seems to place it into a different spot than where UUID.kext or smbios.plist values end up, and also seems to be the source of information for what nvram -p uses, because these two UUIDs look rather similar (formatting issues aside).
That's because Chameleon sets it (creates the /options node, you can check the FireWire thread (http://forum.voodooprojects.org/index.php/topic,200.0.html)), and again this is not SMUUID it is hardcoded in the booter which shouldn't happen, the booter shouldn't create the /options node in the first place (it creates issues, sometimes causes a kernel panic) because it's the job of AppleEFINVRAM.
This is a serious bug we knew and know about, but it went into the sources anyway. It is now been removed, so you shouldn't have issues with it in the next release(s).
(Added live link)
-
Just for those people who have error 35: if you have a working ethernet card - it seems that it needs to be set as "inbuilt" for the mac address from it to be used. THis can be done through EFI strings which set this argument (see timemachine fixes).
-
Another way to fix the UUID 35 error is to patch your NIC into your DSDT.
If your NIC is not supported by OS X' own drivers, you'll still need a legacy.kext or modified plugin in IONetworkingFamily.kext to get it to work as usual.
But patching it in the DSDT sets the NIC as EN0 and internal (no device property string with tmfix needed) and gets rid of the UUID 35 error.
Koalala's ACPIPatcher works with some NICs. There's a solution for Marvell 88E8056 in the thread as well (thanks to Krazubu).
http://www.insanelymac.com/forum/index.php?showtopic=142434
-
Hmm i still have problems understanding the DSDT patching.... Is it possible to patch these ethernet options (inbuilt, etc) in Dsdt.aml (loaded by chameleon) or do they have to be patched straight into the BIOS dsdt?
-
Just to clear things up a bit - when talking about a patched BIOS, we're talking about patching the DSDT tables in the BIOS.
DSDT.aml is a file containing those DSDT tables, it lives on your hard drive and is loaded by Chameleon before OS X starts. If you're using DSDT.aml you don't need to flash your motherboard with a patched BIOS.
It's your choice if you want to flash your BIOS or use DSDT.aml. The end result is the same.
The DSDT section of my motherboard BIOS has been modified to remove CPU aliases only. This is necessary on my motherboard - otherwise it can't boot any OS X media (retail/OSX86/DVD/HDD) that doesn't already have a DSDT.aml on it.
Everything else is patched in DSDT.aml for easy access if I want to add or change something.
Dive in to the thread I linked to above and start reading. Then, just for fun, you can try extracting a DSDT.aml from your BIOS, decompile it and look at it in a text editor.
-
OK, I did some experimenting trying the different ways to solve this issue.
Using the UUID.kext gets rid of the errors, but in a "brute force" way, it will NOT set en0 to be recognized as "built-in"
Patching the BIOS' DSDT tables doesn't help in my case, because my built-in ethernet is not one that Apple uses.
Putting an EFI string into /Extra/com.apple.boot.plist gets the en0 recognized as built-in AND it sets the IOPlatformUUID to the proper value *without* UUID.kext being present.
So it would seem that the last approach is the best EXCEPT for one problem: all it does seems to happen too late in the boot process. As a result, early during the boot, there's a bunch of these Error 35 incidents. They stop later. But I'm not sure, if at that point "the damage is done" or not, i.e. can these early error 35 incidents be safely ignored or not.
Using both the UUID.kext AND the EFI string approach gets rid of all Error 35 incidents and it gets the ethernet adapter recognized as "built-in". So currently I use this double-whammy approach to be on the safe side, until someone can confirm that the error 35 early in the boot can be ignored and that these things self-heal once the IORegistry has the proper IOPlatformUUID value set. In that case, I could get rid of the UUID.kext.
But in any case, it seems, that the UUID.kext will at best be only part of the solution, but not the whole solution, while the EFI string approach might be a complete solution.
The SMUUID value, as said before, right now contributes nothing. Would be nice if a future version of Chameleon could take that value, do some "magic" and allow us to get both rid of the EFI string and the UUID.kext. Just dreaming... ;)
-
@Beerkexd: Thanks for the heads-up.. Much appreciated :)... All the info floating around forums about DSDT patching is hard to understand. So once again : thanks mucho =) Anyway I think ill just go with the dsdt.aml file... Im still wary of patching my bios :P
@rfca: glad to see everything is working :)
I also dream of these two fixes being incorporated into chameleon. But right now the devs are working their asses off, and thats what counts... lol
-
To fix UUID error without kext (PlatformUUID.kext, UUID.kext, SMBIOSResolver.kext) and other hacks
replace this file in Chameleon source (i386/libsaio/).
It just add system-id to /efi/platform
after that IOPlatformExpert in kernel get this property and create PlatformUUID key based on system-id value.
Please provide a patch or a file which applies to the a Chameleon released code source. the file you posted is probably from pc_efi.
I had to remove your post because I can't remove the attachment alone, please repost.
Thanks.
-
To fix UUID error without kext (PlatformUUID.kext, UUID.kext, SMBIOSResolver.kext) and other hacks
replace this file in Chameleon-2.0-RC2-r640 source (i386/libsaio/).
It just add system-id to /efi/platform
after that IOPlatformExpert in kernel get this property and create PlatformUUID key based on system-id value.
-
Thanks, nice find!
And here is the relevant code from "iokit/Kernel/IOPlatformExpert.cpp"
void IOPlatformExpert::registerNVRAMController(IONVRAMController * caller)
{
OSData * data;
IORegistryEntry * entry;
OSString * string = 0;
char uuid[ 36 + 1 ];
entry = IORegistryEntry::fromPath( "/efi/platform", gIODTPlane );
if ( entry )
{
data = OSDynamicCast( OSData, entry->getProperty( "system-id" ) );
if ( data && data->getLength( ) == 16 )
{
SHA1_CTX context;
uint8_t digest[ SHA_DIGEST_LENGTH ];
const uuid_t space = { 0x2A, 0x06, 0x19, 0x90, 0xD3, 0x8D, 0x44, 0x40, 0xA1, 0x39, 0xC4, 0x97, 0x70, 0x37, 0x65, 0xAC };
SHA1Init( &context );
SHA1Update( &context, space, sizeof( space ) );
SHA1Update( &context, data->getBytesNoCopy( ), data->getLength( ) );
SHA1Final( digest, &context );
digest[ 6 ] = ( digest[ 6 ] & 0x0F ) | 0x50;
digest[ 8 ] = ( digest[ 8 ] & 0x3F ) | 0x80;
uuid_unparse( digest, uuid );
string = OSString::withCString( uuid );
}
entry->release( );
}
if ( string == 0 )
{
entry = IORegistryEntry::fromPath( "/options", gIODTPlane );
if ( entry )
{
data = OSDynamicCast( OSData, entry->getProperty( "platform-uuid" ) );
if ( data && data->getLength( ) == sizeof( uuid_t ) )
{
uuid_unparse( ( uint8_t * ) data->getBytesNoCopy( ), uuid );
string = OSString::withCString( uuid );
}
entry->release( );
}
}
if ( string )
{
getProvider( )->setProperty( kIOPlatformUUIDKey, string );
publishResource( kIOPlatformUUIDKey, string );
string->release( );
}
publishResource("IONVRAM");
}
This was only added in recent versions of XNU.
Now we need to auto-generate it somehow or, first thing I can think of is having a key/value pair in the Boot.plist. Using the UUID from SMBIOS wouldn't be a good idea since you can't be sure your board/BIOS has a proper implementation of SMBIOS.
-
Hello everybody and thank you for all this stuff
Using UUID.mkext are not working for me.
@rcfa
What I have to do to put "EFI string into /Extra/com.apple.boot.plist gets the en0 recognized as built-in AND it sets the IOPlatformUUID to the proper value *without* UUID.kext being present"
Can you be a little more explicite ?
greatings
Moderator Edit: if i'm getting you right, you need to search for basic things like EFI strings, EFI Studio. Also hope that you're not confusing kexts with mkext (FAQ #11 (http://forum.voodooprojects.org/index.php/topic,754.msg3304.html#msg3304)).
-
You can use gfxutil to create the ethernet device properties string. Google netkas' forum to find it and read more about what it is and how to use it.
You can also use OSX86Tools or EFIStudio - both use gfxutil but inside a point and click interface.
-
Thank both of you
I was just a little tyred about .mkext, .kext; no confusing...
@Gringo
I've created the ethernet device properties string with EFIStudio like you said and added to com.apple.boot.plist in my EFI partition (just like I did for my graphic card). The problem now is : after reboot I loose my video resolution. It's seems to be a conflict between the two "device properties string" in my com.apple.boot.plist.
Can I do something about this ?
kind regards
-
Ok,
I've find a old thread where it's explain how to merge the contents of the two files.
I still get plenty of "CFGetHostUUIDString: unable to determine UUID for host. Error: 35" in my Console, but I can make now a bootable copy of my system, what I wasn't able to do before.
Thank you again for your patience
regards
-
What network hardware are you trying to set as EN0/Internal and what driver are you using for it?
Maybe all you need is to delete your preference files, this will reshuffle the available ethernet devices and set your patched device as EN0.
Go to /Library/Preferences/SystemConfiguration and delete
com.apple.network.identification.plist
NetworkInterfaces.plist
preferences.plist
com.apple.smb.server.plist.
Reboot and start Network preferences.
Let me know if it helps.
-
hi Gringo
I use an Asus F3Jc T5500 laptop under 10.5.6 (retail Munky's method and Chameleon RC2)
EFI partition - KEXTS USED - AppleDecrypt, Disabler, SMBIOSResolver, HDAEnabler, OpenHaltrestart, ACPIBattery, VoodooPS2Controller, ClamshellDisplay, EHCISleepEnabler, VoodooPower, LegacyAppleAHCIPort, IOSDHCIBlockDevice
In S/L/E I have ALC861 for the sound and VoodooPS2Controller.kext and Efi string NVS_QE for my Go 7300 in the com.apple.boot.plist
Two days ago I added UUID.kext to the EFI/Extra/Extensions folder and EFI ethernet string to com.apple.boot.plist
Everything was fine to me excepte when I wanted to make a bootable copy of my system. Maybe one thing : repair permisions take a verry, verry long time, one hour.
Well, thank you again