Jump to content

Slimbuild - Boot-132 CD Creator for OS X


munky
 Share

342 posts in this topic

Recommended Posts

Hmm...that would consolidate everything into one app but I don't think I want to do that for one of two reasons:

 

1) Every time this script updates I'd have to update entire OSx86Tools

2) Putting another person's work into OSX86Tools doesn't feel like the right thing to do

 

Thanks for the suggestion though :hysterical:

Link to comment
Share on other sites

Here is the Boot.plist I used to build the boot-132 cd that I tested. It should clear up any questions. As for the kernel name, it is whatever the kernel you placd in the kernel directory was called.

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	 <key>Graphics Mode</key>
	 <string>"1280x1024x24"</string>
	 <key>Kernel</key>
	 <string>rd(0,1)/mach_kernel.voodoo_b1</string>
	 <key>Kernel Flags</key>
	 <string>-v boot-uuid=C71B1D31-CD17-36E5-A60E-B4555F0708F8</string>
	 <key>Timeout</key>
	 <string>7</string>
	 <key>device-properties</key>

 

and this is the way the slimbuild directory looks now

 

drwxr-xr-x@ 7 lrh   staff   238 Oct  9 16:09 Contents
drwxr-xr-x@ 9 lrh   staff   306 Oct  9 10:16 Extensions
drwxr-xr-x@ 4 lrh   staff   136 Oct  9 16:09 ISO
drwxr-xr-x@ 4 lrh   staff   136 Oct  9 10:28 Kernel
drwxr-xr-x  3 root  staff   102 Oct  9 16:09 Plist
-rwxr-xr-x@ 1 root  staff  8282 Oct  9 13:14 mySlimbuild.sh

 

Hope this answers the questions.

 

-- BladeRunner

 

Thank BladeRunner, that did help alot...

 

Did a test with efi string and uuid and worked fine.

 

Quick question:

 

Are the uuid required to get this to work with efi string, or is it just for automatic disc detection? Becouse if i use uuid in Boot.plist i wont be able to use same bootcd for installation and for booting up the system (when booting with 80/81 for hd option it stops when searching for the uuid)?

Link to comment
Share on other sites

Thank BladeRunner, that did help alot...

 

Did a test with efi string and uuid and worked fine.

 

Quick question:

 

Are the uuid required to get this to work with efi string, or is it just for automatic disc detection? Becouse if i use uuid in Boot.plist i wont be able to use same bootcd for installation and for booting up the system (when booting with 80/81 for hd option it stops when searching for the uuid)?

 

You are correct, the boot-uuid is only to help with disk detection. the uuid has nothing to do with the use of efi-strings.

 

The reason to use the boot-uuid in a boot.plist on a boot-132 cd is that it is sometimes hard to get the correct value for rd=diskXsY when it relates to the CD/DVD drive.

 

Also, you can override the boot-uuid in the Boot.plist by providing rd=diskXsY at the boot prompt. Therefore, you can make the install process easier with boot-uuid and, using the same cd, boot the resulting system using rd=diskXsY. Then, use one of the methods you like to transfer the boot override process to your hard disk to eliminate the need for the boot-132 disk all together.

 

Hope that helps.

Link to comment
Share on other sites

Thanks again, the rd=diskXsY worked fine.

 

Then, use one of the methods you like to transfer the boot override process to your hard disk to eliminate the need for the boot-132 disk all together.

 

Hope that helps.

 

yep, my plan is to archive 99.9% vanilla, using boot-132 disk to install and then use usb to boot the system. So the install remains clean ;)

 

also its great to be able to use boot-132 disk after install to test diffrent .kext for smbios etc with a clean system before building the final usb boot (only vanilla kext on the install).

Link to comment
Share on other sites

I've done some more investigating into the "image checksum error" problem and it seems to be a long-standing issue with hdiutil. I've tried replacing the -hfs flag in the build script with -joliet (to keep the filenames lowercase) but no dice.

 

When I extracted the boot sector from my slimbuilt iso and compared it to a working one there were differences at the start.

 

image1py8.png

 

The differences between the two boot sectors are highlighted in pink. The top bootsector is from the original BOOT-KABYL-BUMBY iso. The bottom from my slimbuilt one.

 

So it would seem that hdiutil is corrupting the boot sector. I think the only way around this is to use mkisofs to build the iso rather than hdiutil.

Link to comment
Share on other sites

All this progress looks good. The modifications to my script are very well done BladeRunner. Keep up the good work! I'll have my mac back this evening so I can continue my research and work again *FINALLY* woot! I should have a new slimbuild package out soon with a few more options. I am thinking about reviving my old line of querying the user for some input during the build process like i did with buildhelper (thank god i god rid of it for a while though it was horrible) at any rate good luck with the tests people it only gets better from here.

Link to comment
Share on other sites

i wonder if u could create some kind of minimalist ppf style approach to just patch those bytes?

Maybe. But in order to apply the ppf patch you would have to bundle a ppf patch tool. Would be better to just bundle mkisofs instead and avoid patching altogether. Next time I get back into Leo I'll try building the iso with mkisofs and see if it boots ok.

Link to comment
Share on other sites

Maybe. But in order to apply the ppf patch you would have to bundle a ppf patch tool. Would be better to just bundle mkisofs instead and avoid patching altogether. Next time I get back into Leo I'll try building the iso with mkisofs and see if it boots ok.

 

yeah but you have to do a few extra steps when using mkisofs like making a bootable image seperate and then dding it on top of the iso made by mkisofs which is why I chose to go with hdiutil for my script which can do all of that in one pass.

Link to comment
Share on other sites

You can build it in one line. I just successfully booted a disc built with this command line:

 

mkisofs -o slimbuild.iso -b isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table Contents

 

The filenames are uppercase (as -joliet wasn't specified) and it still booted without error. So the issue seems to be solely down to how hdiutil writes the boot sector.

Link to comment
Share on other sites

pcwiz: just call the script (nstask) 'expect' a string that appears on the console / terminal from your obj-c/cocoa-app and respond to it with 'entering the string' you received from an nstexfield or whatever object of your gui. i wrote a bunch of perl-scripts that did the same when creating ssl-certs using openssl. works just fine. in a year or so, galaxy's well-done script is most likely to be carrying even more user input fields and with using flags, it'll become more and more unusable - think of a 500 character-long-cmd-line... alternatively, galaxy could implement a 'non-interactive-flag' but oh well, i'd rather get the gui working with the console app.

Link to comment
Share on other sites

Here's some output from my latest version of Slimbuild...

 

SlimBuild v1.8 ©Galaxy 2008.

Special Thanks To:

BladeRunner - com.apple.Boot.plist Ramdisk population.

 

This session's unique string is UVrYnI

Check this session's ISO to match up the string.

Globalizing session string.

 

##### MKEXT CREATION PHASE #####

Permissions are being set for the following extensions:

Extensions/AppleDecrypt.kext

Extensions/LegacyAppleIntelPIIXATA.kext

Extensions/NullCPUPowerManagement.kext

Extensions/SMBIOSEnabler.kext

Permissions set for meta-kernel extension cache creation.

Performing kextcache operation, please wait a moment...

Meta-kernel extension cache of size 36864 bytes created successfully.

 

##### RAMDISK CREATION PHASE #####

Determining proper RAMDISK file size.

Meta-kernel extension detected with size 36864 bytes.

Kernel binary not present in Kernel directory.

com.apple.Boot.plist not present in Plist directory.

Total RAMDISK size will be less than the minimum size.

RAMDISK of the minimum size will be created.

Creating RAMDISK image file...

RAMDISK image of size 524288 bytes created successfully.

 

##### RAMDISK FILE POPULATION PHASE #####

RAMDISK directory tree created successfully.

Copying Extensions.mkext to the RAMDISK.

RAMDISK image populated successfully.

 

##### BOOTABLE ISO CREATION PHASE #####

Creating El-Torito bootable ISO, please wait a moment...

Bootable ISO file of size 921600 bytes created successfully.

 

##### CLEAN-UP PHASE #####

Clean-up flag set to NOPROMPT, not prompting on file deletion.

MKext deleted.

Contents/initrd.img deleted.

 

SlimBuild Process Complete!

 

I will be ready for a new release package soon probably around build 1.9 :( keep up the good tests!!

~Galaxy

Link to comment
Share on other sites

I've now implemented a previous build system which stores the builds mkext and ramdisk in a previousbuilds folder along with an appended session id which is also appended onto the iso created by the script. this allows for some sembelance of version tracking between multiple runs of the script. I streamlined the plist integration as well as provided for backing that up during a "previous build" scenario as well. More to come soon...

~Galaxy

 

UPDATE: Heres the output from my newest build of slimbuild..

 

SlimBuild v1.8.4 ©Galaxy 2008.

Special Thanks To:

BladeRunner - com.apple.Boot.plist Ramdisk population.

 

This session's build string is qUxOL4

Check this session's files in PreviousBuilds/Build.qUxOL4.

Globalizing session build string.

 

##### MKEXT CREATION PHASE #####

Permissions are being set for the following extensions:

Extensions/AppleDecrypt.kext

Extensions/LegacyAppleIntelPIIXATA.kext

Extensions/NullCPUPowerManagement.kext

Extensions/SMBIOSEnabler.kext

Permissions set for meta-kernel extension cache creation.

Performing kextcache operation, please wait a moment...

Meta-kernel extension cache of size 36864 bytes created successfully.

 

##### RAMDISK CREATION PHASE #####

Determining proper RAMDISK file size.

Meta-kernel extension detected with size 36864 bytes.

Kernel binary detected with size 5074944 bytes.

com.apple.Boot.plist detected with size 4096 bytes.

Total RAMDISK size will be greater than the minimum size.

Total RAMDISK size is 5640192 bytes.

Creating RAMDISK image file...

RAMDISK image of size 5640192 bytes created successfully.

 

##### RAMDISK FILE POPULATION PHASE #####

RAMDISK directory tree created successfully.

Copying Extensions.mkext to the RAMDISK.

Copying mach_kernel to the RAMDISK.

Copying com.apple.Boot.plist to the RAMDISK.

RAMDISK image populated successfully.

 

##### BOOTABLE ISO CREATION PHASE #####

Creating El-Torito bootable ISO, please wait a moment...

Bootable ISO file of size 5844992 bytes created successfully.

 

##### CLEAN-UP PHASE #####

Clean-up flag set to SESSION, creating session Build payload.

PreviousBuild directory tree creation in progress.

MKext/Extensions.mkext appended and relocated.

Contents/initrd.img appended and relocated.

Plist/com.apple.Boot.plist appended and copied.

ISO/SlimBuild-Preboot.iso appended and copied.

Kernel/mach_kernel appended and copied.

 

SlimBuild Process Complete!

Link to comment
Share on other sites

Another update I have decided to make a seperate script for the purpose of "rebuilding" snapshots created by slimbuild as it makes bootable images.

 

Here is some preliminary output from what I deem "PreviousBuild"

 

PreviousBuild v1.0 ©Galaxy 2008.

 

##### CHOOSE BUILD PHASE #####

total 16

-rw-r--r--@ 1 galaxy staff 6148 Oct 12 05:35 .DS_Store

drwxr-xr-x 7 root staff 238 Oct 12 05:01 Build.Ewcbtm

drwxr-xr-x 7 root staff 238 Oct 12 05:00 Build.VCIMaM

drwxr-xr-x 7 root staff 238 Oct 12 04:58 Build.a52bIL

drwxr-xr-x 7 root staff 238 Oct 12 05:44 Build.qUxOL4

 

 

Please enter the build suffix of the build you wish to create a bootable image with.

NOTE: The suffix must be EXACTLY the same as the build folder otherwise the process will fail.

qUxOL4

Populating variables with build selection.

 

##### BOOTABLE ISO CREATION PHASE #####

Creating El-Torito bootable ISO, please wait a moment...

Bootable ISO file of size 89227264 bytes created successfully.

Bootable ISO built off Build.qUxOL4 snapshot.

ISO available at PreviousBuilds/Build.qUxOL4/ISO/PreviousBuild-Preboot-qUxOL4.iso.

 

PastBuild Process Complete!

 

UPDATE: I have decided to allow the switching of the script modes of slimbuild. The previousbuild script goes hand in hand with a new "cleanup phase" the cleanup phase can now delete a build's ramdisk image and meta-kernel extension without a prompt, delete the files with a prompt for each file, choose not to delete anything at all, or use the new session phase that i have implemented which does these PreviousBuild backups and goes hand in hand with someone who would be needing to make more than 1 bootable ISO. I'm debating on leaving PreviousBuild seperate or just creating a utility flag within slimbuild to allow you to backup the iso built from that session as well. Any comments ideas or suggestions would be greatly appreciated. I have run into a bit of an issue with the selection of the build dirs as seen above and if i do decide to keep previousbuild seperate, i will definitely need a better method for populating those dirs and allowing the user to select them aside from entering in cryptic build file suffixes. A new package will be out soon for testing just figured i'd keep this place up to date with my progress now that I have my mac back again.

Link to comment
Share on other sites

great stuff. pcwiz? any word on the gui? might be best to wait for 1.9 i spose.

 

galaxy - one tiny change i made to the version i posted - i put in an 'rm' to remove the ISO image, otherwise it doesnt replace it (just says it already exists). dunno if u've incorporated that.

Link to comment
Share on other sites

great stuff. pcwiz? any word on the gui? might be best to wait for 1.9 i spose.

 

galaxy - one tiny change i made to the version i posted - i put in an 'rm' to remove the ISO image, otherwise it doesnt replace it (just says it already exists). dunno if u've incorporated that.

 

yup i've accounted for it noticed it quite a while ago. :)

 

UPDATE: heres some output from the last run of my script before it goes 1.9 :D

 

SlimBuild v1.8.9 ©Galaxy 2008.

Special Thanks To:

munky - getting the public interested in slimbuild.

BladeRunner - com.apple.Boot.plist Ramdisk population.

Testers - for their input on the scripts usability.

 

##### PREVIOUSBUILD SESSION EXECUTED #####

This session's build string is 9fS9Nq

This session's files are available at PreviousBuilds/Build.9fS9Nq.

Globalizing session build string.

 

##### MKEXT CREATION PHASE #####

Permissions are being set for the following extensions:

Extensions/SMBIOSEnabler.kext -- permissions set.

All extensions have proper permissions for meta-kernel extension cache creation.

Performing kextcache operation, please wait a moment...

Meta-kernel extension cache of size 12288 bytes created successfully.

 

##### RAMDISK CREATION PHASE #####

Determining proper RAMDISK file size.

Meta-kernel extension detected with size 12288 bytes.

Kernel binary detected with size 5074944 bytes.

com.apple.Boot.plist detected with size 4096 bytes.

Total RAMDISK size will be greater than the minimum size.

Total RAMDISK size is 5615616 bytes.

Creating RAMDISK image, please wait a moment...

RAMDISK image of size 5615616 bytes created successfully.

 

##### RAMDISK FILE POPULATION PHASE #####

RAMDISK directory tree created successfully.

Copying Extensions.mkext to the RAMDISK.

Copying mach_kernel to the RAMDISK.

Copying com.apple.Boot.plist to the RAMDISK.

RAMDISK image populated successfully.

 

##### BOOTABLE ISO CREATION PHASE #####

Creating El-Torito bootable ISO, please wait a moment...

Bootable ISO file of size 1277952 bytes created successfully.

 

##### CLEAN-UP PHASE #####

Clean-up flag set to SESSION, creating PreviousBuild payload for this session.

MKext/Extensions.mkext appended and relocated.

Contents/initrd.img appended and relocated.

Plist/com.apple.Boot.plist appended and copied.

Kernel/mach_kernel appended and copied.

ISO/SlimBuild-Preboot.iso appended and copied.

 

This session's build string was 9fS9Nq.

All files from this session can be found at PreviousBuilds/Build.9fS9Nq

 

SlimBuild Process Complete!

Link to comment
Share on other sites

I've a modified com.apple.Boot.plist at the root of ram disk (that has the kernel location and my retail DVD UUID so I don't need to type any thing when booting retail DVD) so I booted without entering rd(0,1)/...... stuff on my system :)

 

And booted installation from USB flash drive. I've restored retail DVD to the 8 GB USB flash drive by Disk Utility then added USB flash drive UUID to com.apple.Boot.plist at the root of boot CD and also my kernel location then I've booted using my boot CD and after that pressed Esc then booted the installation from the USB flash drive :)

Link to comment
Share on other sites

I have finished off the last touches to the latest iteration to my script. It is now at version 1.9.1 with a few minor tweaks. I got around the hdiutil not overwriting the ISO Fiile during the creation process that munky mentioned earlier by adding a flag to the hdiutil makehybrid command line.

 

This build has a few new features, most notable its "PreviousBuild" scheme. Every time you run the script it stores a build profile with a random session string appended onto it. All files including the ramdisk, iso, mkext, kernel, and plist, are stored within this sessions build profile -- this in essence, gives you a "snapshot" of every time you run the script to work backwards from should you need to build anything else.

 

I am working on the compliment script to utilize these build snapshots to create a new functioning disk and it will also be called PreviousBuild. I am looking into the option of also allowing the user to modify the mkext from a PreviousBuild snapshot to add in or delete extensions and repackage the mkext. In any case, the build process has been slowed down a bit i added in some timeouts during script output so that the user can better follow what is going on in the script. By default the script is now set to hide all hdiutil output and its cleanup mode is set to the PreviousBuild mode where it stores snapshots. If you don't wish to use these snapshots you can simply change the CLEAN flag within the script to whichever option you'd like (the details about each flag are given in a comment above above them.)

 

Aside from a few cosmetic changes and the snapshot functionality it is as easy to use as ever. Simply copy in the necessary extensions, any kernel or boot.plist you would like to use and run the script as root by doing sudo sh slimbuild.sh or by executing sudo -s followed by ./slimbuild.sh. The script will give you its PreviousBuild session string at the beginning and end of execution for your reference (in the future it will have a log file for this as well). I am still looking into a compatiability option for those users of jmicron ata and others however this _should_ work as far as i know to make a preboot disk for such users. Let me know how it pans out.

 

NOTE: Do not be alarmed when you open the package and find that there are no files within the Contents directory! The bootloaders and all necessary files are there, they are just hidden so they are not as easily tampered with -- the side effect of this is also that when you mount your preboot ISO file or insert your burned disk the only file which will appear within the Finder is the initrd.img. All of this is perfectly normal and is done for convenience and safety. The Mkext folder within the package is also hidden as it is not needed by the user and is used simply for the scripts disk creation process. Hopefully that clears up any scares that may arise from seeing an empty disk or Contents directory, the files are still there and are safe! Also, any kernel and boot.plist provided NEEDS to be named mach_kernel and com.apple.Boot.plist respectively (these restrictions are more or less to account for the bootloader's liking for a certain naming style though in the case of the kernel is for proper script execution)..

 

And without further ado, SlimBuild 1.9.1...

slimbuildv1.9.1.zip

 

Good luck testers and new users alike!

 

~Galaxy

Link to comment
Share on other sites

I tried the new script - still sorting out some of the new functions. I ran it as a normal user - it failed as expected, but only after running for a period of time. It might be useful to add a test for user ID to the beginning of the script. e.g.,

 

# Make sure the user is Root
if [ $USER != "root" ]; then
  echo "Error ==> This script must be run as root"
  echo "Error ==> try [sudo ./slimbuild.sh] "
  exit
fi

 

It might help the new users to remember.

Link to comment
Share on other sites

I tried the new script - still sorting out some of the new functions. I ran it as a normal user - it failed as expected, but only after running for a period of time. It might be useful to add a test for user ID to the beginning of the script. e.g.,

 

# Make sure the user is Root
if [ $USER != "root" ]; then
echo "Error ==> This script must be run as root"
echo "Error ==> try [sudo ./slimbuild.sh] "
exit
fi

 

It might help the new users to remember.

 

yeah i was thinking that too. my old builder script used to do that but slimbuild wasn't ever released to the public until recently so i never really took it into consideration. its implemented in 2.0 though which will be out soon :D

Link to comment
Share on other sites

great stuff. pcwiz? any word on the gui? might be best to wait for 1.9 i spose.

 

galaxy - one tiny change i made to the version i posted - i put in an 'rm' to remove the ISO image, otherwise it doesnt replace it (just says it already exists). dunno if u've incorporated that.

 

I've been sooo busy lately working on 3 projects at once + school and all that. I haven't made much advancement on the GUI, but like I said once I get going I can finish it in a couple hours. I'll wait for the new script to come out so the work isn't wasted :D

Link to comment
Share on other sites

Not sure what the problem is, but I can't get a working copy. The CD boots just as before, but I( can't get it to activate the install DVD.

 

I copied the boot.plist, kernel and Extensions from the previous slimbuild directory. The cd is puilt without problem and I burn it using disk utility just as before.

 

When I boot the CD I het F8 and then Esc. I insert the dvd and wait until the activity stops and press enter. When the dvd responds I hit F8 and then at the boot prompt enter rd(0,1)/mach_kernel.voodoo -v rd=disk1s3 just as I did with the previous slimbuild.

 

The dvd spins, the lights flash and then it's back at the dvd prompt.

 

I din't know what I am missing - must be too tired. Going to bed!

 

Update I just created a CD with the original Slimbuild and with v1.9.1. To mee it appears that there is a structural difference between the two.

original slimbuild
/dev/disk5
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:		CD_partition_scheme						*7.6 Mi	 disk5
  1:	 Apple_partition_scheme						 6.6 Mi	 disk5s1
  2:		Apple_partition_map						 31.5 Ki	disk5s1s1
  3:				  Apple_HFS SlimBuild-Preboot	   6.5 Mi	 disk5s1s2


slimbuildv1.9.1
/dev/disk5
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:		CD_partition_scheme						*2.0 Mi	 disk5
  1:		Apple_partition_map						 31.5 Ki	disk5s1s1
  2:	 Apple_partition_scheme						 1.7 Mi	 disk5s1
  3:				  Apple_HFS SlimBuild-Preboot	   1.7 Mi	 disk5s1s2

 

don't know if this is useful or not.

Link to comment
Share on other sites

 Share

×
×
  • Create New...