Jump to content

SSE2 & 3 Retail Leo and Vanilla installs - Boot 132 on pre-Core !


munky
 Share

614 posts in this topic

Recommended Posts

couldn't i do this on a Vanillia kernel ??

No, If you're running vanilla kernel that's mean that you can update to the next vanilla kernel from Apple updates BUT there's some extensions will overwrite your current extensions for example AppleIntelCPUPowrMangement.kext will be added and will cause Kernel Panic to this why we use Boot-132 to add our modified extensions and Disabler.kext on the boot CD or USB or Extra folder so that we don't care about /System/Library/Extensions folder :(

Link to comment
Share on other sites

No, If you're running vanilla kernel that's mean that you can update to the next vanilla kernel from Apple updates BUT there's some extensions will overwrite your current extensions for example AppleIntelCPUPowrMangement.kext will be added and will cause Kernel Panic to this why we use Boot-132 to add our modified extensions and Disabler.kext on the boot CD or USB or Extra folder so that we don't care about /System/Library/Extensions folder -_-

OK thx ;) only think i noticed is that it goes faster then the kalyway ,JaS releases

Link to comment
Share on other sites

Someone please explain to the newb :D

What does actually get loaded from boot partition? kernel and extensions right?

 

So how come it can't work for audio or any other driver (screen card maybe) for that matter since they also in extensions? :unsure:

 

Kindly explain please, I need to understand this.....

Link to comment
Share on other sites

Someone please explain to the newb :D

What does actually get loaded from boot partition? kernel and extensions right?

 

So how come it can't work for audio or any other driver (screen card maybe) for that matter since they also in extensions? :unsure:

 

Kindly explain please, I need to understand this.....

 

There's something with Audio kexts that they don't load from the CD but I don't know why.

Link to comment
Share on other sites

Yes, the idea is to have kernel extensions essential for running on a hackintosh (eg dsmos.kext) on the EFI partition, and, for machines not capable of using the vanilla kernel, a kernel as well.

 

Some (most?) extensions will work from the boot-132 CD or from the EFI partition, but for some reason nobody has been able to figure out (so far), audio kexts will not work. Other types of kext seem to work fine (for example, I have Natit, and the 10.4.4 IONetworkingFamily and IO80211Family kexts working (I need those older networking kexts in order for my wireless card to be detected as Airport).

 

One of two things will happen - someone will figure out how to get audio working from boot132/EFI, or they wont, in which case we'll just have to stick them in /System/Library/Extensions, and possibly have to repatch/replace them after Software Update. Though i've heard that you can copy and rename the audio kext so that Software Update wont touch it...

Link to comment
Share on other sites

Thank you 3Dman, feel a bit less stupid now :(

 

Wouldn't a restore function as an option at boot time be nice then? A little app where you can choose to restore some files (such as sound kext) from boot partition and depending on the choice the relevant plist files get updated as well. So basically anything that is not vanilla and thus whenever you update you are still safe.

 

Don't know, just a thought....

 

Actually hoping you all think it's a dumb idea so that nothing (like extra development time) delays the release of the final product :)

Link to comment
Share on other sites

wilcok: the whole point of this is to have a patch-free OS installation. so far on my PC, I have *NO* modified files in the actual Leopard install. all of the patches are held on the EFI partition, outwith the installed OS.

 

it is my firm hope and beleif that I will find a way to patch audio properly the same way i've patched gfx, ethernet and wifi - ie on the EFI partition, outwith the OS. that way my installed OS remains patch-free.

Link to comment
Share on other sites

wilcok: the whole point of this is to have a patch-free OS installation. so far on my PC, I have *NO* modified files in the actual Leopard install. all of the patches are held on the EFI partition, outwith the installed OS.

 

it is my firm hope and beleif that I will find a way to patch audio properly the same way i've patched gfx, ethernet and wifi - ie on the EFI partition, outwith the OS. that way my installed OS remains patch-free.

Thank you for the explanation, got it.

I think that is a great idea and I would love to use Mac OS on hackintosh due to flexibility and upgradability even though I wouldn't mind paying for the OS license. I appreciate your efforts.

 

I just need to understand; so the files remain on Boot 132 partition and OS will get it there when needed or do OS X load everything into memory at once?

I suppose some files/references on the OS do get changed to know where the required files are?

I am really not trying to be difficult, just trying to learn as much as I can as quickly as I can from the masters of MAC.

Care to tell me what DFE does, isn't it similar to Boot 132?

Link to comment
Share on other sites

booting from the EFI partition works very similarly to booting from a boot-132 CD.

 

in each case, the machine is initially booted from a device *other* than Leopard installation. (In the case of booting the retail DVD, you're still basically booting a Leopard installation, albeit one that boots into an install routine rather than the desktop).

 

so: booting boot-132 CD loads a ramdisk (the contents of which are stored in initrd.img on the CD), then it boots the Leopard installation / DVD, but *injects extra kernel extensions* from the ramdisk. optionally, you can specify a kernel on the ramdisk, rather than the vanilla kernel on the installation / DVD.

 

booting from EFI does a very similar set of steps. once again, the Leopard installation is not the partition used to initially boot the PC. the EFI partition is used for initial booting. the bootloader then loads extra extensions (from a directory on the EFI partition this time, not a ramdisk image), optionally a kernel, and then boots the installed OS.

 

in either case, NO modifications are made to Leopard itself - either the DVD (which obviously is read-only) or the installed partition.

 

 

put it like this - the fact we can boot the retail Leopard DVD proves that no modifications are necessary to the OS in order to boot, because the DVD is read-only and therefore inviolable.

Link to comment
Share on other sites

Aha! Now I understand, thank you so much.

I suppose DFE is then more or less the same, maybe you can make sense of this munky; http://aquamac.proboards106.com/index.cgi?...496&page=22

 

If it is in line with your idea maybe STLVNUB can help with the sound kext problem......

 

I am really excited about Boot 132, can't wait until it's done

David Eliott (DFE) has modified BOOT-132 bootloader to make it load extensions from RamDisk.

Boot-dfe and BOOT-132 modified bootloader by dfe they are the same :(

Link to comment
Share on other sites

wilcok: the whole point of this is to have a patch-free OS installation. so far on my PC, I have *NO* modified files in the actual Leopard install. all of the patches are held on the EFI partition, outwith the installed OS.

 

it is my firm hope and beleif that I will find a way to patch audio properly the same way i've patched gfx, ethernet and wifi - ie on the EFI partition, outwith the OS. that way my installed OS remains patch-free.

 

Munky: Have you tried activating your audio with EFI strings in com.apple.Boot.plist? I know some were experimenting with that over in the netkas forum. Since the Boot.plist will most likely be modified in some way on most installations - e.g., kernel flags & graphics card - that appears to be a reasonable approach. That is, if it works for you.

Link to comment
Share on other sites

Munky: Have you tried activating your audio with EFI strings in com.apple.Boot.plist? I know some were experimenting with that over in the netkas forum. Since the Boot.plist will most likely be modified in some way on most installations - e.g., kernel flags & graphics card - that appears to be a reasonable approach. That is, if it works for you.

Can I do the EFI strings thing for realtek AC97 ALC665 ?

Link to comment
Share on other sites

Can I do the EFI strings thing for realtek AC97 ALC665 ?

 

3dman: I am not sure. I use the strings for a realteck nic and a GeForce FX 5500 graphics card. Check the Netkas EFI forum

 

There are several discussions of various graphics and audio cards. They also provide a utility for converting between html and hex string forms of the data. Saves the user from needing to edit hex strings.

 

I set my efi strings several months ago and have not been following the progress over there for some time.

Link to comment
Share on other sites

BladeRunner: that could very well be the best solution. I haven't gotten round to figuring out the whole efi strings thing yet. (quite lazy really).

 

com.apple.Boot.plist is the one and only modified file on my OS, to save me from having to type in magic incantations at every boot.

 

I should figure out strings for my gfx (X1800), Ethernet and maybe even wifi too.

 

Thx for the idea

 

PS: My wifi is one of those cards which needs IONetworkingFamily and IO80211Family from 10.4.5 to work as airport which is a pain, frankly. Anyone know if there's a better solution?

Link to comment
Share on other sites

 Share

×
×
  • Create New...