QUOTE (colddiver @ Sep 19 2009, 07:51 PM)

DigitalDreamer: would highly recommend that you modify your script to avoid updating these values without the user knowing.
Colddiver
This is being fixed, but update is not available, yet.
Revamped platform/hardware UUID setup:- UUID injector kexts (UUID.kext or PlatformUUID.kext) are synced with UUID string in smbios.plist, if present. This will make it easy to update your UUID injectors – keep the SMUUID string current in smbios.plist
- However, if no UUID is present in the smbios.plist, any UUID string present in the injectors is left alone
- If you wish to have a new UUID generated, you have two options:
- 1. Use the script to generate a new UUID for the smbios.plist (SMUUID key). This UUID string will be copied to injectors.
- 2. Or, remove any UUID strings from injectors (do not remove key and string tags!) and smbios.plist. Script will generate a new one.
I've thought long and hard on a solution that will be the most flexible and proper, trying to fit in with everyone's wishes: You can ignore it and it'll be taken care of, or you can add it and it'll preserve it.
Again, if you wish to carry over your existing UUID, add it to the smbios.plist and that will be synced to the installed kexts on each install. Or, if you don't want to bother with the smbios.plist, you can simply add it manually to your PlatformUUID.kext (ideally, the one in your script's folders, so that it'll be available on each install) and make sure there isn't one in the smbios.plist. That UUID will be preserved.
I know the smbios.plist is supposed to be a injector, too, but the UUID portion doesn't work for everyone, hence the kexts. Additionally, I find editing the UUID in the smbios.plist the easiest and the most visible, compared to digging two levels into the kexts. The install.log will always show the UUID on every install, as well, should you be interested in knowing what it is and it's not being based on the smbios.plist.
The injector kexts usually already have a fixed UUID inserted, which will be the same on all systems that don't have it modified - not a great solution, as it's supposed to be unique.
I propose to release this script update without the UUID string present in the kext or smbios.plist. This will allow one of two things to happen: User can add his UUID to the smbios.plist via script (or manually), which will be synced to kexts
or a new and unique UUID will be generated and inserted by script if user doesn't add one. In the latter case, the UUID will get copied to kext in the script folder and smbios.plist, so that a new UUID isn't generated every time a kext gets installed. This method will prevent a different UUID from being introduced into the system should the user replace his existing PlatformUUID.kext with another one from who-knows-where, or if the user deletes the SMBIOS key/string from the smbios.plist.
If this process appears too complicated (welcome to my world and the world of computers, where an endless variety of variables and scenarios can come into play and must be decided on), just add the UUID to the PlatformUUID.kext and be done with it. Just make sure if you ever copy another PlatformUUID.kext from somewhere else, it's going to have the same UUID. Most people don't care to look.
Sorry that this has been an issue, due to a misunderstanding on my part. I realize that each time one attempts to change the UUID now, the script will change it back on a install or update.

It'll be released by midweek.
EDIT: If you want to know what the previous UUID was that your system was using prior to it be changed, it's usually the apple-installed software in the Preferences/ByHost folder, like iCal, AddressBook, iTunes, Mail, etc.
QUOTE (luh3417 @ Sep 20 2009, 06:53 AM)

Not to put too fine a point on things but, where do you get the dsdt.aml to start with that you apply the CMOS reset fix to? I guess I don't understand why blackosx goes to such a mess of detailed complicated trouble to get the DSDT happy, while the your DD script, you just run one option and you're done. Here is his DSDT guide
http://redirectingat.com/?id=292X457&u...p%3Fmmqy2nzmgzd and here is his thread about it.
http://www.insanelymac.com/forum/index.php?showtopic=177497 I mean you can spend hours just on DSDT there, while here it takes seconds, what's up with that?
Maybe the DD script is easier because its only for one board and all those boards have the same DSDT? But that doesn't make sense, first of all blackosx's primary concern is with one single board too, and second of all you could just ship out the one standard GA-EX58-UD5 dsdt with the script and not even need to run the sed script fix every time.
Lastly, wondering what your take is on the above "SL is happier when installed from SL, not when installed from 10.5". I know you do lots of installs, could it be that you are generally always fortuitously installing from SL to SL? Just wondering.
The difference is that he is editing the file by hand, manually. I spent the time to script a solution after having edited it by hand to form a solution. I did the hard work already with the user benefiting from a fast solution. Not everyone is going to script or code a solution, it's just not their thing. But, I find this the perfect task to script for and is just what computers do best.
This solution should work for all boards, if they have the same scope "Device (RTC)". It'll break if the scope is slightly different, say "Device (_RTC)" or "Device (/RTC)". I don't know exactly what the code looks like on other boards, so I'm taking a chance that it may work.
The "SL is happier when installed from SL, not when installed from 10.5" comment is certainly true, which is why one has to resort to building caches in Single-User mode or installing x86_64 kexts in /System, have Unix files that don't get hidden automatically unless fixed in SL, and have file permissions repair broken unless fixed in SL.
Part of the reason for this is that we are trying to install from Leo and the only way to do that is to bypass the main installer application (which would force you to reboot into SL on the DVD which will not run on our Macs), and run one of the embedded installers, OSInstall.mpkg. Doing so skips the BSD.pkg install and other scripts, like hide Unix files.
For the last two months, I've installed SL from Leo many dozens of times. It's only been in the last 3 days I've setup a second SL install. Things are, indeed, much easier when using it as a maintenance drive, instead of Leo. The best install method is the USB install, where the SL ISO and bootloader is installed and booted into. In this case, one is installing from SL to SL, an ideal situation. I'm trying to incorporate this technique (Thanks, Proengin!) in the script as an option. This technique has been alluded to several times in this thread. It would simplify the installation process.
regards,
MAJ