Jump to content

Munky's Experiments with Boot-132 - Thread Dumping Ground


munky
 Share

44 posts in this topic

Recommended Posts

This thread is a dumping ground for the experiments leading up to my booting the retail Leo DVD on my pre-Core architecture Hackintosh, something which was considered hitherto not possible.

 

For a decent overview and the latest developments, please refer to this thread: http://forum.insanelymac.com/index.php?sho...123841&st=0

Link to comment
Share on other sites

POTENTIALLY BIG NEWS FOR OWNERS OF PRE-CORE ARCHITECTURE INTEL SYSTEMS...

 

so an update on my thoughts on specifying an alternative kernel. i chatted to dfe - who, by the way is a scholar and a gent, and has been incredibly patient, generous and helpful - and it turns out you CAN specify an alternative kernel.

 

this should open up the boot-132 method to pre-Core processors, like my Pentium D :)

 

i'm working on getting this working, and will post results as and when, but for anyone else who'd like to try, here's what david said:

 

Hi Munky,

 

If you look slightly more closely at the code you'll realize that it names the ramdisk rd(u,p) just like hard drives are hd(u,p). So it already works to do something like rd(0,1)/mach_kernel.custom assuming you have a file mach_kernel.custom in the root of the ramdisk and the partition is numbered 1. I think partition numbers start at 1 so you should be ok with that. If not try 0.

 

It's been a while since I did this but I remember it working fine. That is, you simply enter the full path to the kernel on the boot command-line followed by any options.

 

Enjoy,

-Dave

Link to comment
Share on other sites

POTENTIALLY BIG NEWS FOR OWNERS OF PRE-CORE ARCHITECTURE INTEL SYSTEMS...

 

so an update on my thoughts on specifying an alternative kernel. i chatted to dfe - who, by the way is a scholar and a gent, and has been incredibly patient, generous and helpful - and it turns out you CAN specify an alternative kernel.

 

this should open up the boot-132 method to pre-Core processors, like my Pentium D :thumbsdown_anim:

 

i'm working on getting this working, and will post results as and when, but for anyone else who'd like to try, here's what david said:

 

That would actually be huge news for many people.

Link to comment
Share on other sites

POTENTIALLY BIG NEWS FOR OWNERS OF PRE-CORE ARCHITECTURE INTEL SYSTEMS...

 

so an update on my thoughts on specifying an alternative kernel. i chatted to dfe - who, by the way is a scholar and a gent, and has been incredibly patient, generous and helpful - and it turns out you CAN specify an alternative kernel.

 

this should open up the boot-132 method to pre-Core processors, like my Pentium D :D

 

i'm working on getting this working, and will post results as and when, but for anyone else who'd like to try, here's what david said:

 

Just tried it with a VMware session. It works, except the kernel I used bombs out, but definitely picked it up. Placed in root of the initrd.img then at boot used rd(0,1)/mach_kernel.

 

Update: Tried the vanilla kernel and it does boot further but then hangs. I assume missing something maybe system.kext???

 

Update2: Waiting for root device is the issue. This is a fully working system, so obviously we need to work out the missing bits.

Link to comment
Share on other sites

@Foodie, Donk:

 

I am going to test this evening with a new kernel.

 

will report back with findings.

 

my hope is that this will allow us pre-Core architecture intel owners who have machines like mine (I class it 'frustratingly close to vanilla') to boot retail DVD and install, and to update direct from apple, etc.

 

another thought: if this can give us the ability to run an AMD-compatible kernel, then if its possible to do AMD-patching on the fly via a kext, then AMD guys could get in on the party too. I dont have an AMD so im not sure what the state of the art is with that stuff, but iirc binary patching is needed to remove checks for 'GenuineIntel' strings, right? so if that could be patched on the fly by a kext / modified kernel, then, well, its party time...

 

i guess the whole thing about attempting to boot the retail DVD (and a vanilla install) with extra kexts + kernel supplied on the ram disk is that its a fundamental shift in how we tackle incompatibilities on our hacks. the old approach was 'blah.kext causes crash? remove blah.kext'. the more intelligent approach is 'clobber blah.kext by creating a blahdisabler.kext, and put blahdisabler.kext on the boot-132 ramdisk'.

 

anyway, im rambling now... :P

Link to comment
Share on other sites

@Foodie, Donk:

 

I am going to test this evening with a new kernel.

 

will report back with findings.

 

my hope is that this will allow us pre-Core architecture intel owners who have machines like mine (I class it 'frustratingly close to vanilla') to boot retail DVD and install, and to update direct from apple, etc.

 

another thought: if this can give us the ability to run an AMD-compatible kernel, then if its possible to do AMD-patching on the fly via a kext, then AMD guys could get in on the party too. I dont have an AMD so im not sure what the state of the art is with that stuff, but iirc binary patching is needed to remove checks for 'GenuineIntel' strings, right? so if that could be patched on the fly by a kext / modified kernel, then, well, its party time...

 

i guess the whole thing about attempting to boot the retail DVD (and a vanilla install) with extra kexts + kernel supplied on the ram disk is that its a fundamental shift in how we tackle incompatibilities on our hacks. the old approach was 'blah.kext causes crash? remove blah.kext'. the more intelligent approach is 'clobber blah.kext by creating a blahdisabler.kext, and put blahdisabler.kext on the boot-132 ramdisk'.

 

anyway, im rambling now... :)

 

If you need any additional help let me know. I've been working on VMware support for Leopard based on dfe's work.

Link to comment
Share on other sites

@donk: will do man :) i am hopefully (if my two-year-old allows!) going to test tonight, and start thinking about putting together a 'post-install' package which will install the bootloader onto the drive after installing from retail. so the process would be:

 

- boot from CD containing boot-132 + kexts + kernel

- boot retail Leopard disc, format and partition GPT disk, install vanilla Leopard

- boot from CD again, use that to boot the vanilla partition

- run post-install routine, which places boot-132 bootloader, kexts and kernel on the partition, and sets the boot options accordingly.

Link to comment
Share on other sites

OMFG IT WORKS.

 

Ladies and jellyspoons, Pentium 4, Pentium D, Celeron D owners : YOU ALMOST CERTAINLY CAN BOOT RETAIL DVDs

 

Dfe himself has been assisting me in some experiments.

 

As we already know, (see my posts above), you can specify an alternate kernel, as well as kexts, with dfe's boot 132. I obtained a new, minimally patched kernel (which im not at liberty to discuss right now...) as I had tried and failed with StageXNU and Modbin. Dfe explained that most hackintosh patched kernels strip out some efi related stuff which is actually needed. I cant say more about the new kernel, for the moment.

 

I tested with the following:

 

- A USB drive containing a clone of my work machine's 10.5.4 installation (its a c2d based Macbook pro)

- A copy of dfe's generic ISO with nothing added except dsmos.kext

- The new patched kernel. I actually put this on the clone, but others have already verified it can run from the ram disk.

 

I booted the cd-r, selected the USB drive, specified the patched kernel and -legacy flag (kern currently has to run 32-bit unless you have SSSE3)

 

This pretty much guarantees that I'll be able to boot the retail DVD using a similar method (albeit with the kern on the ram disk). I would test but my wife and son are sleeping in the room with the computer in it :-(

 

Woot!!!

Link to comment
Share on other sites

OMFG IT WORKS.

 

Ladies and jellyspoons, Pentium 4, Pentium D, Celeron D owners : YOU ALMOST CERTAINLY CAN BOOT RETAIL DVDs

 

Dfe himself has been assisting me in some experiments.

 

You can specify an alternate kernel, as well as kexts, with boot 132. I obtained a new, minimally patched kernel (which im not at liberty to discuss right now...) as I had tried and failed with StageXNU and Modbin. Dfe explained that most hackintosh patched kernels strip out some efi related stuff which is actually needed. I cant say more about the new kernel, for the moment.

 

I tested with the following:

 

A USB drive containing a clone of my work machine 10.5.4 (a c2d based Macbook pro)

A copy of dfe's generic ISO with nothing added except dsmos.kext

The new patched kernel. I put this on the clone, but others have already verified it can run from the ram disk.

 

I booted the cd-r, selected the USB drive, specified the patched kernel and -legacy flag (kern currently has to run 32-bit unless you have SSSE3)

 

This pretty much guarantees that I'll be able to boot the retail DVD using a similar method (albeit with the kern on the ram disk). I would test but my wife and son are sleeping in the room with the computer in it :-(

 

Woot!!!

 

Fantastic. Let us know when we can get involved.

Link to comment
Share on other sites

Well.. the situation surrounding the kernel is a bit of a grey area, but I have asked my source for clarification...

 

However, I am working from home tomorrow, so i'll be 'experimenting' all day with this I suspect... :(

 

First task: boot and install from Retail.

 

One thing - my booted clone had graphics tearing, no QE/CI etc, Airport didnt work etc... i'm unsure how to best tackle these things... whether we can specify 'efi strings' like with PC-EFI or whatever, or whether just alternative versions of kexts can be stuck on the RAM disk and used in preference to those on the vanilla system.

 

This thread should have been stickied long ago - have fixed that now :)

Link to comment
Share on other sites

um, I don't really get it.. what's new here? I've been booting like this for ages, with stagexnu & other kernels, working just fine. the only part I haven't done is put the kernel on the boot image, but... from what I read you still have the kernel on the cloned drive, so you haven't either?

Link to comment
Share on other sites

so, what, you've been booting retail Leopard discs?

 

the fact i had the kernel on the target partition rather than the ramdisk is immaterial, and was just a convenience (rather than having to go edit the ISO and reburn it). its already been proven that booting with a kernel on the ramdisk works.

 

the significance becomes clear when you mix all these ingredients together, you'll see you can boot a retail Leo DVD on pre-Core architecture PCs. *that* is new.

 

the next step for me is:

 

- create a new ISO with the kernel in place on the ramdisk image

- boot from it

- boot retail DVD using kernel on the ramdisk

- install to hdd

- boot from CD again

- boot hdd partition

- get bootloader and 'extra' folder from ramdisk onto the disk

 

which i would have done tonight, but for the fact that the mrs and sprog are asleep in the room the PC is in. but tomrrow i will do it.

Link to comment
Share on other sites

cloned retail DVD with added kernel, yes. I have a screenshot from 4th august.

 

yeah... but im not talking about a modified DVD, im talking about booting a shrink-wrapped, from-the-shop original retail disc on a Pentium 4 class machine.

 

just to be crystal clear, im not trying to take any credit or claiming that this is something wondrous that i've done - all i did was ask dfe if specifying an alternative kernel is possible with boot-132, and - with his help - did a few experiments which have convinced me that tomorrow, after the mrs is off to work and the sprog is off to nursery, i will be able to boot my retail Leo disc on my PC.

 

ALL of this amazingness is down to dfe.

Link to comment
Share on other sites

(sigh) Yes, that has been the goal of many, and yes it has been theoretically possible for ages, but as I understand it you haven't actually done that yet. So rather than make loads of announcements today, why not show up tomorrow & explain to everyone how you actually did it, because the *only* part missing is the kernel-on-boot-image bit?

Link to comment
Share on other sites

(sigh) well excuse me for being excited! in the spirit of scientific discovery, i was simply reporting my findings, and musing on the possible ramifications. why are you so determined to be so down on this?

 

(sigh) Yes, that has been the goal of many, and yes it has been theoretically possible for ages, but as I understand it you haven't actually done that yet. So rather than make loads of announcements today, why not show up tomorrow & explain to everyone how you actually did it?
Link to comment
Share on other sites

hmm i've gone to the point of removing all my hard disks from the machine - set everything in BIOS to be as 'legacy' as possible. even swapped the DVD drive from slave to master, in case that helped (its on its own on the single IDE channel - all my HDDs are SATA).

 

STILL getting the same error. both the iso image and the burned disc boot fine on my mbp under virtualbox.

 

any ideas??

Link to comment
Share on other sites

argh no pendrive handy. need to figure this out...

 

EDIT: ok, sourced a pendrive of sorts (a usb SD card reader + 2Gb card :D) and i can get boot-132 to boot by using this method: http://hecabe.blogspot.com/2008/07/other-b...-partition.html

 

now... er... how do i know the two-digit hex code which corresponds to my DVD drive?

Link to comment
Share on other sites

I restored my Leopard DVD to an external USB HD so when I boot the CD I just try 80, 81, 82 until it shows me a partition called "Mac OS X Install DVD". 80 is your first hard disk, 81 is second and so on. Just hit the esc key to try again. Might also work for optical drives.

Link to comment
Share on other sites

 Share

×
×
  • Create New...