Posts Tagged ‘operating systems’

10.8 upgrade/install on my hackintosh

Saturday, August 11th, 2012

With 10.8 coming out, I took the opportunity to migrate my OS installation from a traditional hard drive to an SSD.  (Specifically, I installed a 256GB Samsung 830-series drive).  I followed the general approach over at tonymac (I bought 10.8 online, then used his Unibeast wrapper to build an install-from-USB stick), modified for my setup.  The installation of 10.8 to my SSD went swimmingly, but I noticed something odd – I needed to upgrade my version of Chimera (the Chameleon bootloader fork), as the previous version I’d been using without problem on 10.7 just barfed.  (It rebooted immediately after starting to boot anything 10.8).  But that was easy to fix by updating my version of Chimera (which I do manually, since my loader is on its own partition on a separate drive & the tonymac auto-install tools tend to screw that up).  Of course, I also had to install fakesmc & wanted to get rid of the orange icons for my hard drives, so I also installed the ahci port-injector kext.  But, that was it.  I much prefer not to use “Multibeast” for post-installation, because it tends to crap out kexts all over that I don’t want — and which could lead to problems across software updates.  (I also just like to know exactly what’s installed).

During installation, I did a fresh, full install.  I did not do any kind of upgrade.  (In fact, my 10.7 installation is still intact on my hard drive).  However, I did want to keep my old user accounts with as little fuss as possible.  So, I took note of the user ID, group ID, and UUID settings for each of my accounts as established in 10.7.  Then in 10.8, I first created accounts corresponding to each of the existing user accounts.  But before ever logging in to those accounts, I went in and changed the user/group/uuid settings (and obviously the home directory setting, to point it to the location on the old hard drive where the user data sits).  This made for a seamless transition – accounts log in & have all of their old settings as they previously did, but I get awesome speed from having my OS and applications on the SSD.

Using xbench, I see speeds of between 350 & 425 MB/s, which is about what I expected.  It doesn’t approach the peak speeds that the interface and the disk support, but that’s because of the controller I have it sitting on.  My Gigabyte X58-based board only has a Marvell SATA3 controller, which is somewhat notorious for its inefficiency, bad drivers, and limited architecture.  Further, the Gigabyte implementation is apparently flawed & only has the controller connected to a single PCIe lane on a PCIe 1.0 link.  This limits the theoretical throughput to 250 MB/s.  So, I bought an add-in card (an Asmedia ASM1061) for about $10 on Amazon.  It’s a single-lane card as well, but installing it in to a PCIe 2.0 slot will up the theoretical throughput peak to 500 MB/s.  (This controller works out-of-the-box without any additional drivers/kexts required).  The only real problem with my resultant setup is that I’d also like this on Windows, but I have about 300 GB of applications (games – thanks, Steam sales!) on top of the Windows requirement, and I don’t really want to mess around with uninstalling/reinstalling games as I use them.  So for Windows, I’ll wait for prices to drop some more & pick up a 512 GB SSD at some time in the future.  Given that it’s been more than 2 years since I did any kind of major hardware tweak to this machine, it probably won’t be any time soon anyway.

10.7.1 update issue-free

Thursday, August 18th, 2011

I continue to be impressed with the chameleon/chimera boot-loader efforts – it’s made all of my updates since first installing my hackintosh trouble-free, including this last 10.7.1 update.  Awesome.

A tale of two Mac OS Updates

Tuesday, July 26th, 2011

I recently bought Mac OS 10.7 (“Lion”) for both my 2006 Core 2 Duo Macbook Pro and my i7-based hackintosh. I assumed that the Macbook Pro update would go smoothly, so I focused on preparing first for my hackintosh (after reading generally favorable outcomes online). First, I updated my bootloader from Chameleon 2 RC4 to an RC5 variant. However, the App Store would not let me continue my purchase (giving me the error “This version of Mac OS X 10.7 cannot be installed on this computer”). After reading over at tonymac that his/their variant of Chameleon (“Chimera”) was required, I installed that over my Chameleon 2 RC5 build — this did not make the App Store error go away. I was using the required MacPro3,1 system definition in my smbios.plist file, but it turns out this wasn’t sufficient – I had a bunch of other stuff in there (including DRAM information) from my Chameleon 2 RC4 install that was causing the problem. I installed the tonymacx86-provided MacPro3,1 system definition (from Multibeast), which in fact is actually just a relatively spartan smbios.plist file. That seemed to do the trick. It’s not clear if Chimera was actually required after all, but from there on out it was smooth sailing. I installed using the steps here, which include copying the installation files and kexts such as fakesmc to an installation partition, blessing it for boot, and then booting the installation partition to continue the install. The only real hitch was that my sound driver (voodoohda) was out of date & was 32-bit only, and I had switched over to using the 64-bit kernel. So, I had no sound until I installed the new driver.

All told, it was actually a pretty smooth transition, as far as hackintosh operations go. My only real beef with the process is that the “Multibeast” installer is very opaque about what exactly it’s installing and where they go. For example, I have my boot loader on a separate partition from my system drive, and I then chain-load Mac OS from Chameleon/Chimera. The installer basically takes a volume as a target & emits the files to assumed locations, and it doesn’t tell you which files are getting written out. To hunt and peck through the process of getting only what I needed (and then manually updating my loader partition after the fact), I had Multibeast install its various pieces to a scratch volume (a USB stick, actually), and I tested the various pieces using a separate USB stick with my loader & basic kexts (ahci port injector, openhaltrestart, and voodoohda). Once that was stabilized & working with 10.6, I updated my loader partition for the 10.7 installation process.

In contrast to the quirky-but-functional hackintosh update experience, my Macbook Pro got hosed by the upgrade. I’m still not sure exactly what happened. My Macbook Pro contains a non-default hard drive (the previous one was too small), but I didn’t do anything crazy there — I initialized it using the Mac OS (10.6) installer several months ago when I installed the drive, installed Mac OS, reinstalled my applications, partitioned using Boot Camp, and installed Windows 7 on there as well. So I started the 10.7 installer/upgrade process, and midway through (after a reboot into the 2nd phase of the installer), I get “Mac OS X Lion couldn’t be installed, because the disk is damaged and can’t be repaired” (where is obviously the name of my 10.6 partition). It then told me to re-try the installation (which wasn’t very helpful, given that I was stuck in an installation loop booting back in to the 10.7 installer which wouldn’t complete). It also suggested I get the data off my hard drive and do a clean install. Brilliant! Various reports online attempted to attribute this to hardware failure – which is incorrect. I booted my 10.6 installation DVD and attempted to repair the volume – same issue. I reset PRAM – no luck. I checked for SMART errors – none. The only thing I can attribute this to is my non-factory hard drive on the machine, but it definitely isn’t failing. I booted Windows, copied the data off using the HFS+ driver that Boot Camp installs, booted the 10.7 installation DVD (which I made prior to attempting the installation, just for this sort of eventuality), erased my 10.6 partition, and then did a clean install. This worked, as did restoring my data. But it took many hours & brought me quite close to data-loss disaster. If I’d have had this experience prior to installing on the hackintosh, I don’t think I’d have attempted the hackintosh installation so soon (or at least, without backups in triplicate – admittedly, I operated somewhat without a net when doing the hackintosh update).

Anyway, those are my experiences with the update – all I can say is that I’m glad I at least didn’t lose my Windows partition as well, which I’ve read that others have experienced.

Hackintosh, Networking updates

Thursday, March 24th, 2011

I’ve made a few sporadic updates to my Hackintosh, so I thought I’d share them here.

First, the update to 10.6.7 went smoothly, as anticipated.

Second, I put in wired networking in my house, so I needed a wired-NIC solution. (I had been using wireless). I also needed something better than 100mbit, because that was a big motivator of bothering to put in wired networking in the first place. After enabling the onboard realtek gigabit NIC in my BIOS, it “just worked” in macos using built-in drivers. (Remember, I have a patched DSDT). However, realtek nics are less than stellar performers and are not that reliable. I could never get more than 750 mbit/s with it, and it would periodically just go down — this happened in both MacOS and Windows. Resetting the driver wouldn’t work. I’d have to reboot the machine. This is actually somewhat common with realtek hardware because of their crappy heavily MMIO-based interface — too many MMIOs in a short period of time and the state machine in the NIC’s firmware gets wedged (because some portions of the state machine do not have positive acknowledgement that they’ve completed – you do step A, then B, then C from the driver), and that’s it, you’re done.

So, I looked for an add-in card. I have a BCM5721 gigabit NIC, but I could not get this to work with stock drivers. I’d read people had success copying drivers from old MacOS builds, but I wanted to avoid this path because it could get killed in any subsequent update, and I’d have to redo it. There were multiple problems here. First, the driver attempts to enable wake-on-lan, and it fails given my system + hackintosh’s acpi information. However, you can disable wake-on-lan in the driver’s Info.plist. (this setting *is* sticky across most updates, btw). Even doing that, however, I couldn’t get the driver up. After a great deal of debugging (and playing with writing my own driver, which I discovered others had started on as well), I found that basically the stock driver isn’t handling message-signaled interrupts (MSIs) correctly. Likely Apple does not have this hardware installed on any systems that use MSI, or for those that do, the default interrupt vector is the correct one. I considered either modifying other drivers or writing my own, but at this point, I’d already spent a lot of time on this problem.

So, I took a gamble on a Marvell-based gigabit NIC. I bought a Rosewill RC-401-EX from Newegg for $23. And, I’m happy to report that it works out-of-the-box, with stock drivers. (No modified plists, nothing). I get line-rate with it (~940mbit/s using TCP netperf), and I have yet to have the interface wedge on me. It’s a great solution to this sort of problem, if you run in to it.

10.6.5 upgrade on my hackintosh – no problems

Thursday, November 11th, 2010

For those who sometimes follow the hackintosh scene, I thought I’d post an update that the upgrade to 10.6.5 via “Software Updates” went fine for me, without issue.  (My hackintosh build is described in this post).  There were some horror stories yesterday over at insanelymac.  These sort of underscore the increased risk associated with all these non-vanilla build methods that have been around for a while.  If you’re using a bunch of nonstandard kexts or (especially video) hardware that requires special tricks to get it to work, reliability seems really, really spotty.  I’ve been pleasantly surprised with the reliability of my build so far – let’s hope it keeps up.

Free-software hippies frothing at Oracle

Wednesday, August 18th, 2010

Oracle recently sued Google over alleged infringement of Java-related software patents as implemented in the Java-ish userland operating environment of Google’s Android OS.  I haven’t read a good breakdown of the actual alleged violations, so I can’t speak to their merit.  However, it’s not as though Oracle is some patent troll — they legitimately own the intellectual property associated with Java patents by virtue of their acquisition of Sun Microsystems, and they continue to develop Java technology.  Shortly after this announcement, Oracle also announced that they will no longer develop Solaris (the commercial software) through Open Solaris (the open-source development project that has, heretofore, “run ahead” of Solaris).  Instead, Solaris will be developed in-house by Oracle and its source will be released after, not before, a commercial release.

Since then, there’s been a steady stream of free-software enthusiast outrage.  Over at zdnet, there has been (and I’m not joking) nearly one article or blog post per day, all decrying the evil that is Oracle.  The crux of their complaining stems from their underlying assumption that software patents should not exist, and that a company cannot be “a friend of open source” and also defend its intellectual property via software patents.  This is utterly ridiculous.  Oracle’s lawsuit may be meritless (I don’t have the expertise on the exact allegations to say one way or the other), but they’re not evil for killing off a money-losing endeavor (Open Solaris — which was already almost exclusively developed by Sun/Oracle engineers or those working for them through partnership agreements) or claiming a stake in the multibillion dollar mobile OS market that is Android, and which may in fact be based on Oracle-patented technology.  Being “open source” doesn’t necessarily mean “here, take everything for free, I disavow any claim to this.”  That’s what the GPL hippies want “open source” to mean, but that’s not what it meant long before the GPL ever came around.  And, I’ve got no problem with people wanting to develop “Free” (as the GPL hippies define it) software – cool beans for them.  But, they’re crazy to demand that businesses license their software and their intellectual property according to their nutjob demands.  (The GPL hippies aren’t exactly completely altruistic, either.  Though they are bemoaning what they perceive as Oracle “changing the deal” with Java by coming back now and asserting intellectual property rights on something they believed was “Free”, they do the exact same thing if a company improperly appropriates GPL code in to a closed-source product:  they “come back later” and demand that the terms of their intellectual property agreement — the GPL — be enforced).  This latest bout of batshit insane demands from the corners of Free Software enthusiasts only reinforces my underlying belief that Free Software is mostly about one thing for its proponents:  gimme gimme gimme.

Mac OS 10.6.4 upgrade: No Issues

Monday, June 21st, 2010

I find blog updates about most minor Mac OS updates to be mundane and unnecessary, but for those following the Mac-OS-on-generic-hardware scene, it’s useful to know how others with similar hardware fare with Mac OS updates.  I used the software-updates method (rather than the “combo update” mechanism some seem to prefer — that’s useful in configs different than mine).  There were no issues whatsoever.

DSDT and kext information for my Hackintosh

Wednesday, May 5th, 2010

As previously mentioned, I’ve built a hackintosh using a Gigabyte GA-X58A-UD5 motherboard (with the F4 bios), an i7 950 processor, and an nvidia GTX 260 graphics card.  The information one might need to get Empire EFI/Chameleon RC4 booting this machine is present in that other post.  However, a few people have asked for my DSDT information, so here are the diffs to the the disassembled dsdt.  As previously mentioned, I simply followed the guidelines here and adapted them to my DSDT.  Note that there is processor-specific information here regarding power states (in this case, for my i7 950).  To use this, you just need your disassembled dsdt file (called dsdt.dsl), which you can get by first getting the compiled version (I used an Ubuntu Live CD) and disassembling it (using iasl — again, I used Ubuntu).  With your disassembled DSDT and this diff, simply do:

patch -p0 < dsdt.dsl.diff

And then recompile doing:

iasl -sa dsdt.dsl

which will create a “dsdt.aml” file suitable for various PC EFI projects (including Chameleon RC4).

Using this, I don’t need a null power kext or any modified power management kext.  Stock Apple power-management kexts just work.  What doesn’t work:  sleep.  Apparently other people have used some sleep enabler kext to get this to work, but I haven’t tried that, since I don’t need it.  What also doesn’t work without a driver:  sound.  Also, as a reminder, I’m using the 32-bit kernel.  And to summarize, (native) SATA (without IDE emulation), USB, firewire, and graphics all just work (using GraphicsEnabler=Y, PciRoot=1) w/ Chameleon RC4.  Without a kext fix, however, the hard disk icons are the orange external ones.  There are several methods to fixing this.  The machine will shut down, but not reboot.  So, I also use a snow-leopard compatible OpenHaltRestart.

So, the drivers (kexts) I use are:

VoodooHDA (for sound)

Fake SMC 2.5 (platform workarounds to make the sucker boot – I had to install this on my System partition rather than in Chameleon’s Extra folder.  It wouldn’t work otherwise, for me)

IOACHIBlockStorageInjector (Just to make the hard-drive icons gray rather than the orange external ones)

OpenHaltRestart for 10.6 — I can’t find the source for this right now, and I’m not hosting kexts on my blog.  The version for 10.5 will not work – I see several different options over at, so have a look over there if you need this.  As I recall, shutdown would work, but reboot would not.

Before you ask, no, I will not provide the compiled version of my DSDT.  The diffs are more useful for you because you can use them to generate a new DSDT against newer BIOS revisions or against slightly different motherboards.  (People inexplicably mix & match DSDTs that aren’t for their motherboard — if/when this works, it’s purely accidental).  If you’re mucking around with a Hackintosh, you ought to be able to boot an Ubuntu Live CD, follow some simple commands, and apply a patch.

10.6.3 update on Hackintosh – Success

Monday, March 29th, 2010

I updated my Hackintosh to 10.6.3 without issue today — I figured if I’d spent all that time & effort into making my machine “just work”, what was the point if I didn’t try updates?  (I have Windows as a reliable backup on another disk).  Anyway, it worked flawlessly — so, one anecdote in the “plus” column.

Hackintosh – it’s alive!

Monday, March 8th, 2010

My Core i7 950-based Hackintosh is alive.  I’m using a Gigabyte GA-X58A-UD5 motherboard, a D-Link DWA-556 wireless card, and an nvidia GTX 260 video card.  To install, I used Empire EFI 1.85 r2 to bootstrap the retail 10.6 DVD, which I own.  I had to provide the “GraphicsEnabler=Y PciRoot=1” options to the Empire EFI loader to successfully boot the DVD.  Once installed, I used the Chameleon 2.0 rc4 boot loader from a USB stick (Chameleon cannot boot DVDs directly, or else I’d have tried that first) to boot my machine.  As to be expected, there were several caveats along the way.

First, I had to patch my dsdt (basically, BIOS-level device description table) to be compatible with Chameleon and other EFI-translation layers to provide EFI services to Mac OS.  I followed the general guidelines for similar Gigabyte boards here.  I used the intel “iasl” compiler with Ubuntu 9.10 on my machine to retrieve the BIOS’s regular dsdt, decompile it, edit, and recompile.  With my edited dsdt, I have native power-management functionality (rather than using a null driver that effectively makes your CPU run at maximum power-consumption levels all the time).  I also have many of my motherboard’s devices working, including Ethernet, USB, and obviously SATA.  Shutdown works with just my patched dsdt, but rebooting does not.  For that, i had to install a snow-leopard compatible version of the OpenHaltRestart driver.  For sound, I used the open-source voodoohda driver, which works just fine.  My graphics “just work” with the GraphicsEnabler=Y option, though switching resolutions in games does not seem to function as desired.  That said, I don’t really care, because I only ever use my display at native resolution.  My wireless card is identified as an Airport Extreme, as I was very careful to get one with the exact same Atheros chipset as those used in Macintosh hardware.  I use the fakesmc 2.5 driver to enable some platform devices necessary for booting MacOS, but other than the OpenHaltRestart and voodoohda drivers, everything else is vanilla, stock MacOS with no other modifications.  I updated to 10.6.2 without issue.

I did note, however, that Chameleon seems to default to attempting to boot the 64-bit version of the MacOS kernel on my hardware, which is nonsensical.  I had to force the 32-bit kernel in order to make my wireless card work, as Apple does not provide a 64-bit version of the driver.  I do not understand the fascination with the 64-bit kernel within the hackintosh community.  You’ll find lots of people bitching about a lack of a 64-bit driver for this, that, or the other.  As people who are actively modifying OS-level software — especially the MacOS kernel — the people writing the software, at least, should know that the 64-bit kernel buys you very little in terms of functionality on MacOS.  MacOS can address more than 4 GB of RAM using the 32-bit kernel via PAE.  Further, MacOS seamlessly supports 64-bit applications (as well as 32-bit applications) with large-RAM support on its 32-bit kernel.  No benchmark data shows any advantage on MacOS with a 64-bit kernel compared to a 32-bit kernel.  (Yes, there is overhead switching between modes of execution, so syscall-heavy code can suffer, which is why Xserves default to having the 64-bit kernel on. However, my desktop — even with heavy graphics-card use — does not show this to be an issue).  Attempting to default to the 32-bit kernel only reduces compatibility with drivers, for no actual normal-use benefit.

I’m using the F4 version of the BIOS for my motherboard, which is the newest.  I did have quite the scare with updating my BIOS, however.  I flashed it from a USB stick that I’d installed FreeDOS on.  The flash appeared to be successful, according to the program’s results, but upon reboot my motherboard appeared totally dead.  It wouldn’t give me anything on screen, it wouldn’t provide any beeps, and just seemed utterly dead.  The on-board boot status code LED indicated that it was constantly resetting itself, going back and forth between reset and initial memory tests.  I reseated my add-in cards, reseated my RAM, and still, the same result.  Finally I reset the BIOS variables (“CMOS” — an outdated misnomer if there ever was one), and thankfully it worked.  I was not looking forward to the prospect of returning a motherboard to newegg, but thankfully, it didn’t come to that.

Also, I’m glad I decided to go with the 950 rather than the 920 processor.  Apparently newegg got burned with a batch of counterfeit 920 processors last week, which is when mine would have arrived.

On the Windows front, I installed 64-bit Windows 7 (which I bought on sale at launch, knowing I’d need a copy anyway eventually) later, which went smoothly.  I disabled the annoying aspects of the hideously unusable menu-bar, basically making the menu function like Windows Vista (which I actually like).  It does have some minor improvements versus Windows Vista, particularly with simplified network configuration.  That said, it’s really just Windows Vista and an annoying menu bar.  Yes, the compatibility-mode feature (running Windows XP sp3 in a VM for a program) is a nice new addition, but for most users, this is not a big deal.  Most programs have been updated to run with Vista, and so Windows 7 benefits from the perception that “everything runs better”.  Actually, everything runs the same as it did with Windows Vista, now that developers (both 3rd-party and Microsoft) have finally updated most everything to stop doing nasty things like scribble on global, machine-wide registry variables.  Regarding multibooting, I used 2 separate drives for MacOS and for Windows.  Windows still cannot boot a gpt-partitioned drive, and I wanted to use native gpt partitioning for MacOS.  During Windows installation, I disconnected my MacOS drive (which I have since installed the Chameleon bootloader on to, obviating the need for a USB stick on each boot) to avoid Windows writing into the MBR of my MacOS drive.  After successfully installing, I reconnected my drive, and Chameleon can correctly select and boot Windows 7 just fine (though you do have to select the “System Reserved” partition to boot, which contains the Windows 7 boot loader).  I still need to install FreeBSD on this beast, but overall, I’m quite happy with the machine and with the software results.