Jump to content
5 posts in this topic

Recommended Posts

Dear all,

 

I am toying with a thought of building a new hackintosh to replace my aging iMac, as I would welcome some more flexibility in my component choice. Still, I want it to be a full-fledged replacement for a real Mac.

 

Basically, my goal would be to create a vanilla installation on my disk (which could be also booted from a real mac). I have access to a Mac in order to create such an installation. I would place the bootloader inclusive all required kexts and extras onto an USB key, and boot from it (aka EFI-X). This should in theory simplify any update and backup procedures because they will never touch the osx86 related files. Also, I could clone my install disk and use it to boot a real Mac, which is also an important benefit for me.

 

Now my questions:

 

Is something like possible and easily done with modern bootloader versions? Will I loose performance if my bootloader and kexts are on the USB key instead the main install disk (which would be an SSD)? Is there a mITX mainboard which I can expect to run without any hickups, which all relevant features (sleep, sound etc.) enabled with only a minimum of additional kexts required? It is also very important to me that the machine behaves like a real Mac, e.g. it should work with App Store and Parallels Desktop. Compatibility with OS X 10.8 would be also a big plus.

 

So, am I expecting too much or is what I am thinking about perfectly possible?

 

Thanks for your input!

Here for components:

http://wiki.osx86project.org/wiki/index.php/Apple_hardware

Here for booting info:

http://www.insanelymac.com/forum/index.php?showtopic=278350

 

 

Buy the right parts and you may find you only need the fakesmc kext anyway.

 

Parallels is only dependant on virtualisation capabilities of the processor and the only reason the app store wouldn't work is if you don't have your ethernet /airport card working & setup right.

Thank you for your encouraging answer!

 

 

Here for booting info:

http://www.insanelym...howtopic=278350

 

Unfortunately, I couldn't read too much out of it. If I understand correctly, this is about installing the kexts on the system disk, while I want to keep my system disk and the bootloader disk with kexts completely separate. Any tutorials/hints on how to do this? My problem is that I don't have a PC at hand where I could try things out, and I don't want to buy expensive hardware if I am not sure that it will work...

Not necessarily, my experience lies only with lion so don't quote me on the specifics but I'm relatively certain of the following:

With snow leopard any extra kexts could be placed in /extra/extensions on any device where the chameleon bootloader was installed (i.e. your usb drive) and it would automatically inject them into the kernel with no performance issues, this was because under snow leopard there wasn't a kernel cache but an "mkext" which held the details of which kexts were required to boot and could be placed on the usb stick with chameleon hence theres no overall effect on boot time and everything fine.

On lion however the cache of required kexts is managed by the operating system elsewhere so kexts have to be installed to /s/l/e or you have to boot without the kernel cache resulting in longer boot times.

Again I might be a little of with some of the specifics but I'm sure you can get the jist of it. That said there may be a different way with a different boot loader but I've just never stumbled across it, google is your friend.

 

Also since a kext is simply a file and I can't see you swapping hard drives between computers evreryday then it isn't really neccessary to have them separate to the install. It would take at tops 15 seconds to delete your modified kexts (as mentioned earlier if your building the rig specifically to run os x I'd be very surprised if you needed many) then it could run fine on your original mac.

 

If your not aware then when you install kexts the utility you use (normally kext utility) will automatically move the kext your changing to a backup file (whatever its original name is with .bak appended to it) in the same directory. Just delete the modified kext then the .bak extension and your good to go.

 

Someone else may chime in with how to get the extra kexts off local but if they don't at least you know it wouldn't be too much of a hassle regardless

With the right MB and video card you should be able to get very close to your objective, although I cannot think of a scenario where I would want to swap a HD from my Hack to a real Mac and boot from it!

 

Gigabyte MBs are quite friendly to configure in the Hack world. I presently have three X58-UD3R boards with ATI5770 video cards that are very Mac friendly. Beginning with SnowLeopard and continuing through the present developer versions of MountainLion, upgrades have been no problem with the exception of the audio 'breaking' with each new version of the OS. That is easily fixed by installing replacing the AppleHDA kext, added by the new install, with an old one that will permit on-board audio to work.

 

There are only two kexts required in S/L/E (System/Library/Extensions) for an install to work, other additional kexts can reside in Extra/Extensions (a folder only 'seen' by the bootloader). The newer bootloaders (those that work with ML) apparently do not require any sleep kext for the sleep function to work. Sleep works on my ML and LIon installs without any kexts for that function. Kexts for ethernet and audio must reside in S/L/E for those interfaces to work. If one used a USB audio device for audio then that kext would not be required. As to the ethernet kext, it would not be required by a real Mac (different name) but I do not know how the Mac would react to the presence of a 'foreign' kext (don't have one to try).

 

Basically, you could have the bootloader, Simbios, boot.plist, DSDT and extra folder on a USB to boot and, if you used USB audio, only need an ethernet kext in S/L/E to boot the HD on a PC. If the real Mac 'objected' to the foreign ethernet kext you would need to remove it before moving the HD to the Mac.

×
×
  • Create New...