Minimalist Mini MacBook

As someone weaned off of PC hardware (not necessarily Windows), I've had my share of this sticker happy period that's characteristic of PC heads. From desktops to laptops...

image from 1.bp.blogspot.com

So following this tradition, we have a netbook looking like this:

image from eeeuser.com

Pretty? I thought so too. Past tense.
I also had once upon a time went as far slapping additional stickers onto my HP Mini MacBook 1001TU:

Well, I'm using the most elegant OS in the world, at least in my own opinion and yet I live with this monstrosity. So now with my HP Mini 311 MacBook, which looked like this before:

Is cleaner now:

If I couldn't have this:

image from typicalmacuser flickr.com

I'd at least have this:

Sorry for the crap picture quality, it's my Nokia 5530 that I took it with.

HPM311DP_061810HF6RC3, 10.6.4 and Internal Mic Problem

from gearlive.com

After spending more time to observe and test my Mini MacBook 311, I can verify problems with the external mic no longer working is not caused by 10.6.4.

Apparently, even if VoodooHDA's necessary dependencies were put in EFI /Extra/Extensions and the kext is indeed able to load and provide system sound, it being not in /System/Library/Extensions causes internal mic to not function.

So that means it's my fault. Actually HPM311DP_061810HF6RC3.pkg, on its own, can hardly be blamed cause it only puts a new Extra folder in EFI containing all the kexts with the additional VoodooHDA related stuff. It does NOT run any scripts that touch /System/Library/Extensions. If you remember the experiment I had sought people's help to test, VoodooHDA needed to be manually eliminated in /System/Library/Extensions with the help of Kext Utility to wrap things up nicely. My apologies for making you test but I deeply appreciated the feedback of those who participated and signaled this issue with the internal mic.

I guess this means, VoodooHDA cannot ever be placed outside of /System/Library/Extensions. :(

Now there are other things I've discovered: my shirking from putting kexts in /S/L/E is entirely rooted in my not so good issues with putting PS2 Controller kexts (ApplePS2 and VoodooPS2) in that location. It caused me kernel panics. 

The current HP Mini 311 PS2 Controllers should not be placed in /S/L/E in my opinion.

Sure, VoodooHDA caused its own share of KP's when put in /S/L/E but I've now discovered that removing CHUD resulted in a more stable system.

In short, we'd just have to make sure we have Retail Pack 0.9 kexts.
1. Download Retail Pack 0.9 and unzip it.
2. Mount EFI:
$ mkdir /Volumes/EFI
$ mount_hfs /dev/disk0s1 /Volumes/EFI
Or if you're not comfortable with Terminal, you can use Alter EFI v1.3 to mount EFI. IMPORTANT: Choose the "Edit kexts" option.
3. Copy the (entire) "Extra" folder from Retail Pack 0.9 and paste it inside EFI. To verify, your EFI root volume should contain two things: (1) boot (2) Extra folder
4. Umount EFI;
$ umount -f /dev/disk0s1
$ rm -rf /Volumes/EFI
Or if you used Alter EFI to do the mounting for you, just click on "Done" on Alter EFI to umount EFI.
5. Copy VoodoHDA.kext from Retail Pack 0.9's kexts folder and paste it in /Sytem/Library/Extensions.
6. Run Kext Utility.
7. Restart.

10.6.4 Update for Mac OS X Snow Leopard

NOTE: VoodooHDA when put anywhere else outside of /System/Library/Extensions will cause problem with internal mic not working. 

Just run MacOSX10.6.4ComboUpdate and before restarting, install package (this package also fixes system if you've done this experiment):

HPM311DP_063010HF6RC4.pkg

Note: This is for the HP Mini 311. I haven't been able to update my HP Mini 1000 to 10.6.4 yet. Having an "install failed" issue will try over the weekend perhaps.

First of all, let me apologize for the confusion I may have spawned in the community. 

10.6.4 does NOT break anything at all.

But, to be on the safe side, if you're updating from a 10.6.2 system, skipped 10.6.3 right on to 10.6.4, you have at least to make sure that you do have meklort's latest SleepEnabler - it's that version that is 10.6.x independent. 

Download link to official version as per meklort.

Then let met explain what HPM311DP_061810HF6RC3 actually is:

1. based on MowgliBook's Retail Pack 0.9

2. installs VoodooHDA in EFI - this kext has to be deleted from /System/Library/Extensions and Kext Utility needs to be run to fix things as this particular kext makes its exit from the said location in your system.

3. installs VoodooHDA's dependencies, IOAudioFamily and OSvKernDSPLib - the IOAudioFamily and OSvKernDSPLib that get installed are 10.6.4 version (at least so I think, cause it's after I had update to 10.6.4 that I got these kexts from /S/L/E to add "OSBundleRequired=Root" to their info.plist to enable loading them from outside /S/L/E - same stuff I did with VoodooHDA above)

4. new Extensions.mkext - created via Mkext Tool instead of automatically created via the "kextcache -a i386 -K /mach_kernel -m" which, as I discovered, is the root of my blank screen on wake issues from before.

So why did there have to be a new release?

Technically, HPM311DP_061810HF6RC3 is still not a release in the sense that it is still, well, as the name implies, only a release candidate "RC". That's why I needed testers. If it behaves well enough and it could be an official HF6 release.

Why only now in 10.6.4 (why let an experimental release candidate coincide with 10.6.4)?

It just happened that Apple released 10.6.4 to the greater public (i.e. non developer public who don't have access to the seed release of this point update) just after I got my HP Mini 311-1002TU back from the repair center.

Apple released 10.6.4 and I also got a machine to work with.

So why do we need to get to an HF6 release ?

Because we need to progress and find ways to improve the 311 Mini MacBook experience, (sorry in advance), duh?

I don't about you, but trying new things is what makes me tick. And the "new thing" being moving VoodooHDA to EFI /Extra/Extension does mean a lot to me - one less location to monitor and maintain from now on. Having additional stuff in /S/L/E requires me to create a package installer that not only puts the kext in that location but also to make sure other little details are taken care of accordingly - conflicting kexts that are also in /S/L/E (don't remind me of those PS2Controller that were put in there for testing but didn't quite cut it :-|), permissions, and system caches, etc. 

I refuse to play the hypocrite and say that working out the code to manage all that into a preinstall or postinstall PackageMaker script is not overwhelming at all. 

It's like a puzzle to solve - sometimes it's as trivial as putting in a line of command to mount a hidden partition (*wink wink*), other times, well, most of the times, it involves discovering how to perfectly formulate commands (*-m, -a, i386, -K, ring a bell?), from the kextcache in order to avoid having that nasty blank screen on wake issue, to get that com.apple.kext.caches in /Sytem/Library/Caches sorted. It does require some thinking and using one's brain. Specially that most tools like Mkext Tool sources are closed off - no way to know what it does under the hood but to figure it out on your own.

I thought we could attempt a clean new start, less complex stuff, and which better time to do it than with a point update such as 10.6.4? What it means to you, on the other hand, (ideally) should be a less problematic 311 Mini MacBook user experience.

P.S. This is more of like a monologue actually. Oh yeah, now I also talk to myself too. LOL.