Jump to content

[Guide] Boot from EFI partition, zero modification installs on Intel SSE2 or better...

munky

By munky,
in Tutorials (The Genius Bar)

 Share
1,404 posts in this topic

Recommended Posts

munky
munky
Posted
  • Author
Posted

Timing bugs are to do with FSB detection code. This will be addressed soon.

 

The stage2 bootloader used here is not Chameleon based, so sadly doesnt benefit from the fixes applied to Chameleon, unless I port them directly myself. I spoke briefly to zef and this type of functionality may or may not be coming to a future version of Chameleon. If it does, I will stop development and switch to using Chameleon, because it is the far more compatible and refined bootloader. In the meantime, i'll try to port as many fixes to this build as possible, and hope that it works for as many folks as possible.

 

I also spoke at length to Kabyl last night on the subject of modifications to /System/Library/Extensions. He convinced me I should clarify my statements and intent with this project. I am *not* trying to say that /System/Library/Extensions is sacrosanct and should never be changed - after all, that is precisely what it is designed for. Adding new kexts like RealtekR1000.kext or SMBIOSResolver.kext or even dsmos.kext / AppleDecrypt.kext is totally fine. Where things get tricky is when you have a modified version of an Apple-supplied kext you need to use for your particular setup.

 

One approach is to put these in the EFI partition's boot cache, though as many of us have discovered, dependency issues can cause them not to load. Another approach would be to simply copy and rename the kext, and bump version numbers and IOProbeScore values to ensure the 'alternative' version is 'preferred'.

 

One reason why I *personally* wanted to keep edits out of /S/L/E is that I wanted to share a USB drive between a real Mac and a Hack. I have a genuine, real-world use-case here - I backup my work Mac to a usb drive every day and figured it would be 'kinda neat' if I could boot that drive on my home Mac and my home Hack, too, without needing to change anything. However, it must be understood that this is an edge case - not many people will be wanting to do this type of thing.

 

If you're installing Leopard to use on your own PC on an internal drive, and that drive will never be used anywhere else, then please dont kill yourself trying to make everything work from the EFI partition. Use /System/Library/Extensions - thats what its designed for!

 

One other note - I still think that having some kexts on the EFI partition is valid / desirable, as well as using it as a place for alternative kernels and com.apple.Boot.plists. The nice thing about booting from EFI partition is that you can reinstall Leopard and have it 'just work'. Maybe the best approach is to have the bare minimum for booting reside on the EFI partition - say dsmos.kext and Disabler.kext, and a Boot.plist with your graphics device-properties string (so-called 'EFI string') and - if you need it - a patched kernel. Thus after you reinstall, everything you need to boot is there and the fresh install will boot right up, and you can set about installing your 'standard set' of kexts to /System/Library/Extensions.

 

Galaxy mentioned he may write up a guide to bumping version numbers and IOProbeScores etc at some stage. This would be useful for newbies to grok the 'right' approach.

Link to comment
Share on other sites
vailancer
vailancer
Posted
Posted

munky,

 

i have everything works fine, but after i add in the gfx string into the boot plist it just wont boot into gui . from the log it stuck after the login window started.

any idea? the gfx string im 100% sure its correct. If i remove it and it boot. Weird.

Link to comment
Share on other sites
Donk
Donk
Posted
Posted
Timing bugs are to do with FSB detection code. This will be addressed soon.

 

The stage2 bootloader used here is not Chameleon based, so sadly doesnt benefit from the fixes applied to Chameleon, unless I port them directly myself. I spoke briefly to zef and this type of functionality may or may not be coming to a future version of Chameleon. If it does, I will stop development and switch to using Chameleon, because it is the far more compatible and refined bootloader. In the meantime, i'll try to port as many fixes to this build as possible, and hope that it works for as many folks as possible.

 

Guess it is just age, but confused now as to what code comes from where? Also are you not in a position to release any oif it, as I would be interested in taking a look?

 

On a different note I have used this method successfully to run Leopard on VMware. It boots much faster than from CD. A CD image is still needed as VMware insists on using one to boot OSX but all it does is chain to the hard drive. I am planning on building some news sets of templates for VMware users in the next few days. Also can use voodoo off the EFI partition and will be looking for VMware users who have pre-Core machines to try it out.

Link to comment
Share on other sites
Duckydude
Duckydude
Posted
Posted

What kexts would work with this and which ones won't? I'm confused as to which ones will actually load properly. I plan to use the kexts found in ls8's GA-P35-DS4 pack (not including the realtek patch though), plus the shutdown fix, and IONeworkingFamily kext. It would be a good idea to have a list compiled so we all know which kexts can be loaded without issues. Thank you :), this is a great method for OSX86 installs :D.

Link to comment
Share on other sites
munky
munky
Posted
  • Author
Posted

basically, any kexts which load from the EFI partition are not going to find anything they depend on, unless it too is in the EFI partition. (by the way copying ALL of your kexts to EFI partition isnt a great idea).

 

please read my post above about modifying /System/Library/Extensions. i'm starting to think that we should use EFI partition for things critical to boot, and use /S/L/E for normal kext installations. the big problem is when you need to modify an Apple-supplied kext - either a plist edit or a binary patch. those will still get nailed by system updates. i'm looking into a few options to solving this in a 'nice' way.

 

source code coming soon, i promise. its been more about lack of time and organisational skills than anything else.

Link to comment
Share on other sites
Terc
Terc
Posted
Posted
Terc, thanks for the tip, but I know how to customize my com.apple.Boot.plist :unsure:

 

The issue with always using -f is that the boot time is significantly longer. My point was, since I'm not rebooting often, it's not a big deal, but it'd be nice to fix properly. My old Kalyway install would boot to desktop in like 8 seconds, the retail one is more like 30+ secs.

 

Then again, I now run a 100% virgin install on unsupported hardware, so I feel I've already gained a lot with this method :P

 

Yup, time to boot is certainly a disadvantage (the only?) of booting a boot132 partition first, but I think we all agree it's a better method for a daily use machine. I've noticed certain combinations of kexts can really increase boot time, mostly due to errors, like missing extentions, the machine resorting to defaults due to settings that aren't specified, and other bumps along the way. Kalyway has been tweaked more than most of us are probably willing to on our own.

Link to comment
Share on other sites
TofuTodd
TofuTodd
Posted
Posted

how do I force the booting of the retail leopard disk? I've completed the steps but it just keeps booting into my installed copy of iDeneb v1.3. I'm guessing i need to give it some flags at boot? my cd drive is :

 

#: TYPE NAME SIZE IDENTIFIER

0: Apple_partition_scheme *7.8 Gi disk1

1: Apple_partition_map 30.0 Ki disk1s1

2: Apple_Driver_ATAPI 607.6 Mi disk1s2

3: Apple_HFS Mac OS X Install DVD 7.2 Gi disk1s3

Link to comment
Share on other sites
jokinawa
jokinawa
Posted
Posted

As far as the retail disc is concerned I found it easier to just make a 2 partition drive before I installed my retail. 1 was 8GB and the other used the remaining disk space. I then used another leopard install to use disk utility to 'restore' my Retail leopard disc to the 8GB partition. Then my other partiton is where my vanilla install resides. Keep my retail disc safe from scratches that way.

 

I can then boot vanilla install or retail cd from the EFI boot 'menu'.

 

btw, the retail disc boots extremely fast and loads extremely fast this way.

 

J

Link to comment
Share on other sites
BladeRunner
BladeRunner
Posted
Posted

I tried an experiment yesterday. It may be of interest to some.

 

I had an 8Gb USB stick just laying there looking for something to do. So, I formatted it as a 1 partition GUID disk. Then, I installed the efi boot partition v3 boot loader and the set of kext I normally use to boot my system in the efi partition.

 

I placed a com.apple.Boot.plist file in /Volumes/EFI/ and then used disk utility to restore my retail install DVD to the usb stick. Now, the usb stick boots like any other external usb drive - except that it boots the retail OS X install. It's quite fast and very useful.

 

I used the boot-uuid= in the Boot.plist because I have several external usb drives but they are not all on all the time. The diskX value changes frequently depending on the order in which they come on-line.

Link to comment
Share on other sites
B612
B612
Posted
Posted

@munky

efi boot v5 works perfect. congratulations :(

 

@bladerunner

this is really interesting. Would the USB stick boot with the normal efi boot files? In my case, if I copy the efi files into it, it just doesn't want to boot.

Why did you prefer to put v3 rather than v4 or v5?

Link to comment
Share on other sites
munky
munky
Posted
  • Author
Posted

drawrof: apologies for removing your post, but there was a lot of those steps unnecessary.

 

just for information:

 

boot0 and boot1h have not changed since v1, so no need to reinstall those. all changes since then have been in the stage2 bootloader called 'boot' (which I call boot-turbo-munky.bin in the distro).

 

however, i just realised I made a booboo with v5 - inside the zip is boot-turbo-munky.bin which is actually v4, and boot which is v5. i'll upload a fixed package. for those who have already downloaded v5, please use the 'boot' file, rather than the boot-turbo-munky.bin. my fault for uploading in a hurry late last night.

 

to upgrade:

 

sudo -s

mkdir /Volumes/EFI

diskutil list - to figure out which disk is your Leo one - on my machine this changes sometimes, so double check!

mount_hfs /dev/diskXs1 /Volumes/EFI

cd /downloaded/v5/directory

cp boot-turbo-munky.bin /Volumes/EFI/boot (Note if you have the 'mistake' v5 use 'boot' instead).

cd

umount /Volumes/EFI

exit

 

and then reboot :)

Link to comment
Share on other sites
BladeRunner
BladeRunner
Posted
Posted
@munky

efi boot v5 works perfect. congratulations ;)

 

@bladerunner

this is really interesting. Would the USB stick boot with the normal efi boot files? In my case, if I copy the efi files into it, it just doesn't want to boot.

Why did you prefer to put v3 rather than v4 or v5?

 

I built the efi partition on the usb stick by first mounting my hard disk efi partition and doing a copy of the entire /volumes/EFI content to a work directory. Then un-mount the hard disk efi and mount the usb stick efi partition and reverse the copy operation.

 

So, yes, I am using the exact same Extensions kext - kext cache as on the hard drive.

 

The only reason I used v3 was that I had not tested v4 at that time. But, since I installed Munkys v5 I guess I'm testing it now :)

Link to comment
Share on other sites
drawrof
drawrof
Posted
Posted
drawrof: apologies for removing your post, but there was a lot of those steps unnecessary.

 

No problem. It's better to get the upgrade instructions straight from the source. I figured I was doing some unnecessary things there, but better safe than sorry, eh?

 

however, i just realised I made a booboo with v5 - inside the zip is boot-turbo-munky.bin which is actually v4, and boot which is v5. i'll upload a fixed package. for those who have already downloaded v5, please use the 'boot' file, rather than the boot-turbo-munky.bin. my fault for uploading in a hurry late last night.

 

Which "boot" file? I see boot0, boot1h, and boot-turbo-munky.bin. But no "boot".

Link to comment
Share on other sites
overflow1972
overflow1972
Posted
Posted

@munky:

 

Hi this is my first post in this thread. I want to ask you some info.

 

The first time I installed the retail version, I used a modified (by me) BOOT-132 CD by using some kexts inside say SET1 kexts. So I installed the retail and I finally installed CHAMELEON for the boot from the hard disk. Whit CHAMELEON, I used different kexts, say SET2.

 

Now is my question: if I want to try to use the guide here, how can I manage this situation ? I mean, I used SET1 kexts to boot the DVD for the installation and then I used SET2 (with CHAMELEON) kexts to boot the installed system.

 

How can I manage this ?

 

Thanks a lot

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...