How can I _really_ disable ACPI?

No, dude. Just... no.

The first thing you need to consider is that XNU is an acronym for "X is not UNIX." This is a reminder that the OS X kernel is substantially different from other UNIX variants, being a unique hybrid of Mach and BSD kernel components. If you try to use features provided by some other kernel, you will most likely be disappointed in the results.

Moreover, as described in System Startup Programming Topics: The Boot Process, the boot process is unique to the Mac, & depending on the circumstances, the boot loader may need to load some drivers and other kernel extensions early in the boot process, before the kernel can be linked & initialized. Much of this depends on the *I/O Kit*, a part of XNU that is radically different from traditional systems. For more about this, see for example XNU: The Kernel.

The bottom line is that just removing what you consider to be non-essential extensions & modifying com.apple.Boot.plist has about zero chances of doing anything besides breaking the boot or kernel initialization process.

If your MacBook won't boot into OS X, it is likely because some system files were corrupt, or possibly because of other modifications you have performed on system level components. What you are doing is basically like trying to put a bandaid on a terminally ill patient. Trying to hack the OS isn't going to get you anywhere, at least if your goal is running OS X stably.

Message was edited by: R C-R

I'm not quite sure how you hope to solve a hardware problem by using a different kernel -- no matter what, it is a workaround, not a solution.

Compiling your own kernel is a formidable task, at least if you want to run OS X frameworks on it. That will take a lot of study of the developer docs, & remember: Darwin is only a part of OS X. Much of OS X is closed source & not well documented.

< One morning I found my MacBook frozen and with fans spinning noisy. It refused to boot anymore, even off the install DVD.

Boot from external drive is okay?
Then the directory isn't totally corrupt, something that can prevent booting from CD/DVDs.

Use Disk Warrior, don't assume that no error report in Apple First Aid means 100% clean bill of health.

AHT does not look for file system errors.

Maybe there is a bad block hidden in the partition tables, maybe not, but until you rule out such things, I'd just reinitialize and restore and check how many spare blocks used now.

Well, I see ... The weird thing is, that this has to be a hardware problem as I boot and run flawlessly the same installation on my Mac Mini off the MacBook's hard disk via FireWire and Target Disk Mode. So, no - no files or system level components are corrupt ...

A Mac Mini and a MacBook are not identical and may use different drivers for some of their components. A driver used by the MacBook may be corrupt while the driver used by the Mac Mini is not. Try an archive and install.

Other things to try are a PRAM reset and SMC reset.

Message was edited by: Martin Pace

Then the directory isn't totally corrupt, something that can prevent booting from CD/DVDs.

How can a corrupted file system on a HD prevent booting from an entirely different device? If you invoke the Startup Manager (option key start), nothing is loaded from any storage device until you choose one to boot from, & then it loads everything from that device.

It does, it has, it has been confirmed (not in your universe but showed up years ago and pulling the hdd solved the no boot situation) apparently even during boot there is a scan of volumes, and a really really bad directory will do it.

Even EFI boot manager can't handle those drives.

dfgfgre wrote:
It is funny that the XNU kernel loads it extensions based on a mysterious logic that nobody knows of or can control ... it has a touch of black magic 🙂

There is no mysterious logic about it. The process is well explained in the previously mentioned System Startup Programming Topic & related links, expecially I/O Kit Fundamentals: Introduction to I/O Kit Fundamentals.

What is mysterious is your explanation about what will or won't prevent the kernel & extensions to it from loading, which makes no sense in light of the material in these references. And while instances of needing to disconnect the HD to get a system to boot from another source are quite possible, there is no reason to think that "a really really bad directory" is the cause, whatever that mysterious phrase is supposed to mean.

Think about it: a directory is a feature of a file system. At boot time, no method of accessing any file system exists in the computer. The bootROM (which is in firmware) starts the process by first doing POST, which initializes some of the hardware, & then selects the operating system to run. If there is a partition on some device previously set for that in PRAM (for instance, by using the Startup Disk System Preference), it will choose that one unless one of two exceptions occur: 1) the user overrides that by invoking the Startup Manager (also in firmware) or 2) the chosen device isn't available for some reason, in which case the firmware starts looking for the first available device with a boot loader. In either of these two exceptions, it is certainly possible that a bad boot loader from the device would halt the boot process, but if the user takes control of the choice by evoking the Startup Manager, unless there is a hardware problem in the computer itself, this is a non-issue, assuming a viable boot loader is chosen.

Only after the boot loader loads the kernel environment from the device (which for OS X among other things means building the I/O device tree) can that kernel provide the low level services necessary to access the file systems it supports.

If you want to take control of the boot process, you can -- but you must be familiar with all of the requirements involved, including those mentioned in the previously mentioned references, the EFI boot process, & so on. But in no case will this exempt you from the problems "buggy" hardware will cause. There is nothing whatsoever mysterious about that.