[GUIDE] Scripted Yosemite/Mavericks Install on Gigabyte Mobos

[CruiSAr]

Hi CruiSar ,

 

Am also trying to get this developer version of Lion to work on my hackintosh. Netkas first said that Chameleon didn't support booting from a file (from root fs), which is now necessary because Lion doesn't do a full install when installed from withing mac os x... But now netkas seems to have crossed out these words :s... Chameleon trunks haven't been updated for 11 days, so don't really understand this... Do you have anymore progress ?

Sorry Windows04, I sadly have no more progress, Chameleon indeed doesnt support lion, at least not for now. I just get random restarts when the bootloader attempts to load the install disc. I guess its a waiting game for now.

 

I see posts about people using carbon copy to clone a LION install from a mac hoping that chameleon will boot it...waste of time. I am still googling around. Will keep you guys posted as always.

 

EDIT: No more restarts but instant KP, something to do with the ACPI platform, I will run some more tests and post a screenshot soon..maybe tomorrow.

 

Cheers

[Windows04]

Sorry Windows04, I sadly have no more progress, Chameleon indeed doesnt support lion, at least not for now. I just get random restarts when the bootloader attempts to load the install disc. I guess its a waiting game for now.

 

I see posts about people using carbon copy to clone a LION install from a mac hoping that chameleon will boot it...waste of time. I am still googling around. Will keep you guys posted as always.

 

EDIT: No more restarts but instant KP, something to do with the ACPI platform, I will run some more tests and post a screenshot soon..maybe tomorrow.

 

Cheers

 

How exactly did you manage to boot lion (even with KP)? Using modified version of chameleon or carbon copy?

[epitaphic]

Just wanted to take the opportunity to thank all involved in this spectacular effort to keep us all ticking along with our i7's for over two years and counting! Many heart felt thanks especially to Maj and Charles, you guys kick ass. I don't think I'm alone in thinking that we'd be lost without you guys!

 

Manly hugs

[Cosmin Petre]

Just wanted to take the opportunity to thank all involved in this spectacular effort to keep us all ticking along with our i7's for over two years and counting! Many heart felt thanks especially to Maj and Charles, you guys kick ass. I don't think I'm alone in thinking that we'd be lost without you guys!

 

Manly hugs

 

What he said.

 

Here's hoping Lion works too.

[jhrfc]

What he said.

 

Here's hoping Lion works too.

 

Yes me too, and many thanks to d00d as well for his DSDT work!

Will probably wait until chameleon has beta support for lion before I start a test install.

Maj did a fantastic job getting the snow leopard version of the script out within a couple of days of release.

[CruiSAr]

Just wanted to take the opportunity to thank all involved in this spectacular effort to keep us all ticking along with our i7's for over two years and counting! Many heart felt thanks especially to Maj and Charles, you guys kick ass. I don't think I'm alone in thinking that we'd be lost without you guys!

 

Manly hugs

Awww many hugs...lol, I am touched. Well, I learnt a lot when I joined this forum and I am still gaining more knowledge. I have had small success with Lion but I havent installed it yet.

 

Main reason is due to time, I just got a new job and it seems to eat up all the little time I used on here.

 

Anyways [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] is an EFI based bootloader that can be used to boot and install Lion.

 

I have successfully managed to install the bootLoader on a usb drive and it recognises all my OS X partitions. The nest step is to restore the dmg to another usb drive and then proceed to install from there.

 

There seems to be a chameleon bootLoader rumoured to boot Lion. I tried this and my system keeps on rebooting. Some people will ask why dont we just wait until a 100% compatible bootLoader is released.

 

Answer is very simple, I am curious, I may not find the answer but someone might and I'd rather get acustomed to problems now than when Lion becomes available in summer at which time trouble shooting issues will be a piece of cake.

 

Like always, I will keep you guys posted.

 

Cheers

[digital_dreamer]

I'll have an script update out soon with Lion support. Tomorrow, hopefully, if my internet connection cooperates. I haven't been able to connect for a couple days, let alone upload a multi-megabyte file. Right now it takes 5 minutes or more just to load a webpage. Additionally, I had part of this reply ready to go yesterday!

 

The script is a big update with lots of goodies, but I'm not completely done with boot cache build changes. Here's what's to come, however:

 

FUTURE UPDATE: version 5.2

• Added Mac OS X 10.7 Lion support: Script can create a USB boot disk for installation, plus some other housekeeping tasks to make booting into Lion possible. While in Lion, the script will create a prelinked kernel or kernelcache, as it doesn't appear Lion supports kext caches anymore. This also means, at least for the time being, that all modified kexts need to be installed in /System. Creating a kernelcache from SL doesn't work properly, so I've updated the Buildcache shell alias to make this possible in Single-User mode, if it's ever needed.
   
  
• Added ability to detect the presence of the Chameleon-based Stage-0 (boot0) and Stage-1 (boot1h) booter installations, in addition to the existing Stage-2 boot file installation. This will be helpful in cases where one may erase and restore/clone a OS X installation with the previous script versions indicating the bootloader is still "installed" (boot file at root) when the Stage-0 and Stage-1 booters were actually destroyed. Now, their presence is accurately determined.
   
  
• Added ability to install the special Stage-0 booter (boot0hfs) which makes it possible to boot from a non-active OS X partition that has a Windows installation on the same volume, thus allowing the Windows installation to remain the active partition and permit proper sleep behavior in Windows 7. Unlike the normal Stage-0 booter that prefers active partitions first, this one prefers bootable HFS partitions first. The script will prompt the user for this option when it detects a Windows installation on the volume. Only the Chameleon RC5 bootloader has this option available. Many thanks to the developers' untiring efforts in making this possible.
   
  
• Added three additional bootloaders (and removed a few others):
  PC-EFI 10.6 Lion - Netkas modifications for Mac OS X 10.7 Lion compatibility.
  Chameleon v2.0-RC5 r700 - Kabyl's modifications. Includes support for ATI HD4xxx and HD5xxx cards.
  AnVAL v5.1.4 r709 - Andy's and Valv's ACPI Loader. Includes Sandy Bridge support.
   
  
• Added 64-bit version of ATY_Init.kext (finally!).
   
  
• Added ability to extract kernel info, such as "Darwin Kernel Version" and 64-bit capability, and display this info for Kext/Kernel Installer.
   
  
• Added Growl notification for some lengthly script operations. This can be enabled/disabled via preferences. Growl needs to be installed and running for this to function.
   
  
• Added a help menu for the Kext Installer and Boot Cache routines.
   
  
• Made an additional improvement to the RAID installation routine when the OS attempts to update the boot cache on more than one helper partition. Previously, the script only anticipated one helper partition to have the OS support files and this is true most of the time. However, I have run into, at least, one case where both helper partitions on a two-drive Apple RAID setup had the system boot cache installed and the OS insisted on updating them both. The script will now recognize this situation and wait for OS to finish updating all partitions before resuming with RAID copies.
   
  
• Fixed a custom kernel install issue.
   
  
• Fixed a possible RAID restore issue involving custom kernel names.
   
  
• Fixed a minor bug where kexts may not get uninstalled from /System if there were no kexts in the Misc_Patches folder.
   
  
• Fixed a minor bug where MBR partitions would be unmounted after it was set active.
   
  
• Fixed a minor bug where the kext architecture was incorrectly displayed or ignored in the Kext/kernel installer and Boot cache updater. This would happen because some kexts do not have a binary that matches the kext's name. Rather than assume the binary is the same name as the kext, the script now extracts the name and then tests for the architecture.
   
  
• Fixed a bug where kexts in /Extra could not be properly compared against other plugin kexts in /System. If you have, say, RealtekRTL81xx_Lnx2Mac.kext in /Extra, its version can be compared against a RealtekRTL81xx_Lnx2Mac.kext in the IONetworkingFamily.kext's PlugIns folder in /System. This can alert you to conflicts or duplications.
   
  
• Reworked the kext version number update feature to include the "CFBundleShortVersionString," which is considered the release or marketing version number. The "CFBundleVersion" string, the build version number, is used by the system and this is the one the script was updating. However, "CFBundleShortVersionString" is typically used by the Finder and was not being updated by the script, although it generally uses the same number as the "CFBundleVersion" string. Now, updates to the kext version number will show up in the Finder windows, as well.
   
  
• Reworked the DSDT Shutdown Fix to include a PMbase value of "10." The previous script only worked on a single digit, like "4" or "8."
   
  
• Made a slight change to the "View RAID member partitions" routine to maintain folder viewing attributes.
   
  
• Made slight change in Kext Installer routine so that kexts being uninstalled in the /Extra directory will show up as "Remove," just as kexts in /System do.
   
  
• Reworked the older routines - Modify Mac model name, processor info, ATM graphic, themes and boot picture selection - as they had gotten neglected in the past couple years. These are mostly under-the-hood changes and bug fixes.
   
  
• Numerous optimizations in string handling and other performance improvements.
  

 

Installing Lion will be simple. Here will be the steps:

1. Partition a USB drive (flash or hard drive) as MBR. (GUID partitions cause the BIOS to lock up in my experience on Gigabyte boards.)
    
   
2. Mount Lion ISO/DVD.
    
   
3. From script, run Create boot disk (menu #15) and select Boot Disk option.
    
   
4. Select the USB drive from the list of the storage devices and create the boot disk, skipping EFI strings setup.
    
   
5. Restart and boot new drive, "Mac OS X Base System," using the -usecache boot flag. Verbose flag should already be set. Here is where things may get tricky. Currently, there are issues where a double-fault KP will appear right at the beginning. If you are not having success, try disabling JMicron SATA ports and serial ports, if equipped.
    
   
6. Install Lion on drive of your choice.
    
   
7. Boot back into your current SL system.
    
   
8. Run Kext/Kernel Installer (menu #5) and direct all kexts to be installed into /System.
    
   
9. Add -usecache as kernel flag to the boot plist (menu #9).
    
   
10. Install DSDT patch (menu #7).
     
    
11. Reboot into Lion and enjoy. This may take several tries to get past the DF KP.
    

 

Wait patiently!!

 

MAJ

 

P.S. Gaaaa. Trying to send this short reply is going to take 30 minutes!!

Wish I had dialup. It'd be a lot more reliable. LOL

[tsunoo]

YOU ROCK!!!

And CruiSAr too!

[mattrb4]

YOU ROCK!!!

And CruiSAr too!

 

I agree digital_dreamer is amazing. One of the greatest script writers in the history of terminal scripts.

[CruiSAr]

I agree digital_dreamer is amazing. One of the greatest script writers in the history of terminal scripts.

I second that ...

[digital_dreamer]

Ha! You guys are making me blush. It's just a bloated script and it's not even considered programming.

It's amazing how much I can do without a QE/CI enabled graphics card and 17-century internet access.

Internet IS getting better: I could upload a 295k graphic and load this reply page in about 30 seconds. All this on a quad-core i7 system with 6GB RAM. I know I have my priorities right.

 

I've been able to install kexts in Extra and create a linked kernel from there:

kextcache -K "/Volumes/BOOT_DRIVE/mach_kernel" -L \
-c "/Volumes/BOOT_DRIVE/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache" \
"/Volumes/BOOT_DRIVE/Extra/Extensions" "/Volumes/BOOT_DRIVE/System/Library/Extensions"

 

With this method, we can still install kexts in Extra, but the bootloader isn't going to be loading them.

 

However,this seems to only work in Lion. When building in SL, the kernelcache for Lion is significantly smaller - about 11MB, versus 19-20MB in Lion. The kextcache log is very different and when booting into Lion, it halts at certain places. Seems like we'll have to boot into Single-User mode to get one created with 'buildcache', if needed.

 

Someone has mentioned being able to delete the kernelcache and still boot. Didn't think that was possible, but haven't tried it, yet. Anyone else confirm?

 

Interesting details keep popping up:

When you open kext packages in Lion, it doesn't open a new window. I have a habit of closing the kext package window and in Lion you will lose the parent window if you do that. You just need to hit the "Back" button to get to the parent folder (outside the package). Nice.

 

Copying labeled (colored) kexts to another volume will remove the label.

 

Since I don't have a QE/CI enabled graphics card (ATI 4870 X2 went out and got replaced by a sucky ATI Radeon 2600 XT that requires that I disable the ATIRadeonX2000.kext to make it work), there are many things I can't do, like run Safari (I have to use Firefox) or take screenshots. However, in Lion, I can do all those things. Graphics are much smoother. I suppose Apple has gotten the CPU to do more GPU-related tasks. Preview, however, still doesn't display graphics on my non-QE/CI system.

 

Some things that you never thought about are noticeably faster. Doing multiple undos in Coda is wicked fast, compared to SL.

 

(click to enlarge)

 

 

regards,

MAJ

[bbchucks]

Hi,

Trying to get 64-bit kernel on this since i've updated my RAM. Model Identifier: MacPro3,1 Processor Name: Intel Core i7 Processor Speed: 2.67 GHz

using bios version F13Q

 

When i execute: ioreg -l -p IODeviceTree | grep firmware-abi

| | "firmware-abi" = <"EFI32">

 

does this mean there is no way to use 64bit?

 

When i change the arch=x86_64 and boot up the error i'm getting is

 

error:

BSD process name corresponding to current thread: Kernel_task

Debugger called: (double panic)

backtrace (CPU 0)

 

I do notice under Software/Extensions i have a few .kext that are 32bit only which is: BSDKernel6.0, Displaylinkdriver.kext, IOKit6.0, Libkern6.0, Mach6.0, System6.0

Do you have to only have 64bit kexts only?

 

anyone know what the issue maybe?

[digital_dreamer]

bbchucks,

That ioreg command is not reliable as it refers to the firmware for 64-bit capability. But, our systems don't have the firmware, so it's useless. It just changes based on what mode you are in.

 

Additionally, those kexts and other loaded libraries are 32-bit because you are running in 32-bit mode. If you were in 64-bit mode or were running a 64-bit app, it would load the 64-bit libraries. So, again, not a reliable indicator.

 

I suspect that you have a kext that is not 64-bit ready. Would you list all the kexts you are using so we can determine where the fault lies?

 

 

SCRIPT UPDATE:

UPDATE: 3/11/2011 - version 5.5

All on the front page.

 

 

kind regards,

MAJ

[bbchucks]

bbchucks,

That ioreg command is not reliable as it refers to the firmware for 64-bit capability. But, our systems don't have the firmware, so it's useless. It just changes based on what mode you are in.

 

Additionally, those kexts and other loaded libraries are 32-bit because you are running in 32-bit mode. If you were in 64-bit mode or were running a 64-bit app, it would load the 64-bit libraries. So, again, not a reliable indicator.

 

I suspect that you have a kext that is not 64-bit ready. Would you list all the kexts you are using so we can determine where the fault lies?

 

Thanks MAJ!!! as always!

 

here is my extensions listing!

drwxrwxr-x@ 17 root admin 578 Sep 17 2009 Themes

-rwxrwxr-x@ 1 root admin 17132 Jun 17 2010 DSDT.aml.original

-rwxr-xr-x 1 root wheel 1082 Jun 24 2010 smbios.plist

drwxrwxr-x@ 3 root admin 102 Nov 25 00:24 LegacyATI4800Controller.kext

-rwxr-xr-x@ 1 root wheel 8945 Dec 4 11:14 DSDT.aml

-rwxrwxr-x@ 1 root admin 131072 Jan 9 13:07 Sapphire.HD4870.1024.090303.bin

-rwxrwxr-x@ 1 root admin 131072 Jan 9 13:09 1002_9440.rom

-rwxrwxr-x 1 root admin 1039822 Mar 12 00:28 Extensions.mkext.previous

-rwxr-xr-x 1 root wheel 1039822 Mar 12 00:28 Extensions.mkext

drwxrwxr-x 10 root admin 340 Mar 12 00:32 _Kexts_For_Extra_Cache

-rwxrwxrwx 1 root wheel 694 Mar 12 00:34 com.apple.boot.plist

 

_Kexts_For_Extra_Cache

drwxrwxr-x@ 3 root admin 102 Mar 12 00:27 NullCPUPowerManagement.kext

drwxrwxr-x@ 3 root admin 102 Mar 12 00:27 LegacyHDA.kext

drwxrwxr-x@ 3 root admin 102 Mar 12 00:27 JMicron36xeSATA.kext

drwxrwxr-x@ 3 root admin 102 Mar 12 00:27 IONetworkingFamily.kext

drwxrwxr-x@ 3 root admin 102 Mar 12 00:27 IOAHCIBlockStorageInjector.kext

drwxrwxr-x@ 3 root admin 102 Mar 12 00:27 HDAEnabler.kext

drwxrwxr-x 2 root admin 68 Mar 12 00:29 _Kexts_For_System

 

_Kexts_For_System

is empty!

[bbchucks]

this is the error im getting when using arch=x86_64

 

[digital_dreamer]

bbchucks,

I just wanted to know what modified kexts you have installed, whether they be installed in /Extra or /System.

The Apple-supplied kexts are not going to keep you from booting into 64-bit mode. It's got to be a modified kext.

Can we have that looong list removed?

 

kind regards,

MAJ

 

Edit: Okay, I see your KP log. What kind of modifications may you have in the DSDT?

[bbchucks]

bbchucks,

I just wanted to know what modified kexts you have installed, whether they be installed in /Extra or /System.

The Apple-supplied kexts are not going to keep you from booting into 64-bit mode. It's got to be a modified kext.

Can we have that looong list removed?

 

kind regards,

MAJ

 

Edit: Okay, I see your KP log. What kind of modifications may you have in the DSDT?

 

oops, i've updated the Looooong list!!

im actually just using whatever your script installed.

with the DSDT i'm using your default settings that your script set!

 

thanks again for your help!

[digital_dreamer]

I don't really see anything amiss in the Extensions you are using. But, I would try a few things, as you have ACPI issues.

 

Do you have a maintenance partition to boot to/from?

If so, I would try removing the DSDT file in /Extra and see if it's able to boot into 64-bit.

Which bootloader are you using?

 

And, just out of curiosity, do you need that video ROM for the 4870?

How is your boot.plist set up for it? Are you using the "UseAtiROM=Yes" argument and string?

 

MAJ

[bbchucks]

I don't really see anything amiss in the Extensions you are using. But, I would try a few things, as you have ACPI issues.

 

Do you have a maintenance partition to boot to/from?

If so, I would try removing the DSDT file in /Extra and see if it's able to boot into 64-bit.

Which bootloader are you using?

 

And, just out of curiosity, do you need that video ROM for the 4870?

How is your boot.plist set up for it? Are you using the "UseAtiROM=Yes" argument and string?

 

MAJ

Yah i have a partition to boot from but not sure sometimes it doesn't work! i haven't tested it since 10.6.2

 

i'm using the bootloader RC5 r691 from your script.

Yes! Without the video rom file for my 4870 won't boot up.

my boot.plist has:

<key>UseAtiROM</key>

<string>Yes</string>

<key>VideoROM</key>

<string>/Extra/1002_9440.rom</string>

 

i just ran your DSDT patcher again from your script.

[digital_dreamer]

Hmmm. Nothing really pops out.

 

My understanding of the VideoROM key is that it only applies to nVidia cards and, in your case, it's also redundant with the UseAtiROM key. Are you using it to pick up the bin file? I don't see why there are two - you have a ROM file, read by the UseAtiROM argument, and a bin file, which I assume is read by the VideoROM argument. Aren't these files exactly the same, except for the file name? I'd remove the bin file and VideoROM key, if I were you. I don't believe they are being used. And, if they are, it could be the basis for a conflict as the bootloader expects that bin to be a nVidia ROM file, not ATI, AFAIK.

 

As for running the DSDT patcher: The best way to ensure a proper virgin patch, if there's something wrong with the existing one that's loaded, is to boot without one and run the DSDT patcher. When you are booted with a DSDT file, the patcher applies fixes based on that modified DSDT. This is why it won't find any fixes needed, as they have already been applied.

So, to get to a fresh start - again, I'm assuming something is wrong with the current DSDT file that's loading - boot without one and apply the patcher fixes. Then, reboot, again.

I can't imagine anything going wrong with that file, but it has happened in my testing. Anything is possible with all those variables.

 

See if you can boot into your maintenance partition first, before you make any changes.

 

MAJ

[rumz]

Actually you dont need sleepEnabler but this depends on the DSDT present in your /Extra folder. I recommend you use the DSDT I have in a guide in my signature.

 

With this DSDT, you will need only fakeSMC in /extra and the latest Chameleon just to boot into OSX.

Software update works as well. Let me know if you need help plunging to Native Power Management and I will be more than happy to help .

 

Cheers

Charles

Alright, I have a secondary install of Snow Leopard that I use purely for experimenting / testing so that I don't have to worry about bricking a working install. I'm getting a kernel panic using your DSDT file.

 

Here's what I did with it: It has 10.6.6 on it already from an install using DD's script (done a couple month's ago), so I modified that install.

 

I updated the Chameleon bootloader on that drive to r700 (to support my ATI 5770), made sure it had only 2 kexts installed (FakeSMC, IONetworkingFamily), changed the boot plist to run in 64-bit mode, etc.

 

(it was previously forcing 32bit to work with sleepenabler, which kext has now been removed).

 

Last thing I did was copy your DSDT.aml file over the existing DSDT.aml file.

 

Upon booting from the test drive, here's the KP screen I get. I've also included screen shots of my boot.plist and the kext installer so you can see what's installed.

 

----

 

My concern is that perhaps this DSDT with it's EFI string injection is not compatible with using Chameleon R700 (which is what I need to run my ATI 5770). I use no texts or EFI strings for my gfx card-- just the GraphicsEnabler key in my boot.plist in tandem with Chameleon RC700.

 

Either that or I really do just need to do a completely clean install of SL on this drive.

[bbchucks]

Hmmm. Nothing really pops out.

 

My understanding of the VideoROM key is that it only applies to nVidia cards and, in your case, it's also redundant with the UseAtiROM key. Are you using it to pick up the bin file? I don't see why there are two - you have a ROM file, read by the UseAtiROM argument, and a bin file, which I assume is read by the VideoROM argument. Aren't these files exactly the same, except for the file name? I'd remove the bin file and VideoROM key, if I were you. I don't believe they are being used. And, if they are, it could be the basis for a conflict as the bootloader expects that bin to be a nVidia ROM file, not ATI, AFAIK.

 

As for running the DSDT patcher: The best way to ensure a proper virgin patch, if there's something wrong with the existing one that's loaded, is to boot without one and run the DSDT patcher. When you are booted with a DSDT file, the patcher applies fixes based on that modified DSDT. This is why it won't find any fixes needed, as they have already been applied.

So, to get to a fresh start - again, I'm assuming something is wrong with the current DSDT file that's loading - boot without one and apply the patcher fixes. Then, reboot, again.

I can't imagine anything going wrong with that file, but it has happened in my testing. Anything is possible with all those variables.

 

See if you can boot into your maintenance partition first, before you make any changes.

 

MAJ

Thanks, i cleaned up the plist file and now im just using the ATIrom.

Also remove DSDT and then ran it again with your patcher after the reboot.

 

still crashing or KPing...no biggie imma just wait for Lion, it's around the corner anyways!

 

i dont know if my 12gigs of memory is being utilized in 32bit mode but at least all my apps are working.

[digital_dreamer]

rumz,

You might want to try the older version of FakeSMC.kext. The 3.1 version is a newer one that I just threw in recently and it has 3 Plugins, including a ACPIMonitor.kext and IntelThermal.kext. It may cause problems with the modded DSDT file with native power management, I don't really know. Perhaps CruiSAr can answer this. The older one (v2.1) is in the repository and is in all lower-case type.

Oddly, that KP also looks Ethernet related, but I can't imagine why. Perhaps it had just loaded the RTL8168D/8111D LAN driver at the time of the KP.

 

bbchucks,

Is it just KPing in 64-bit, or are you having trouble in 32-bit mode also?

 

Even when booted with a 64-bit kernel, 32-bit applications are limited to just 4GB. A 64-bit app has the ability to exceed that, if needed. So, you're not really missing out, unless you're using a RAM hungry 64-bit application that could use more than 4GB or need several of these applications open at once without the VM paging them in and out of the HD every time you switch apps.

 

But, I agree, Lion is worth the wait. It's pretty cool.

MAJ

[bbchucks]

bbchucks,

Is it just KPing in 64-bit, or are you having trouble in 32-bit mode also?

 

Even when booted with a 64-bit kernel, 32-bit applications are limited to just 4GB. A 64-bit app has the ability to exceed that, if needed. So, you're not really missing out, unless you're using a RAM hungry 64-bit application that could use more than 4GB or need several of these applications open at once without the VM paging them in and out of the HD every time you switch apps.

 

But, I agree, Lion is worth the wait. It's pretty cool.

MAJ

 

Thanks as always, your support is unrivaled!

i'm good on 32bit mode, just 64bit.

i think lightroom or vmware fusion is the only intensive apps that might be RAM hungry. alright i do play World of warcraft at times too lol.

 

yah i'll wait for Lion, with TRIM support i think i'll finally pickup a SSD drive then too.

 

loving it that you are still updating your script to have Lion support!

[digital_dreamer]

Just keep in mind that TRIM support appears to only work with Apple-supplied SSDs, at least so far as the information I've been reading around the net. Third party SSDs from the manufacturers haven't received TRIM support from the OS. Not sure why that is, but I hope it's not because Apple wants control of the SSD purchases. I'm not particularly pleased with having to pay the Apple tax just to get TRIM, but we'll have to see how this plays out in the long term.

 

best of wishes,

MAJ