Jump to content

Project: Installable DVD Patch


47 posts in this topic

Recommended Posts

BIG NOTE: I'm writing this AFTER the fact. Meaning, I took some notes while doing it but not enough to recant my exact steps and describe them accurately.

 

First real thing I did on my image was patch for SSE2 booting (Patch the DVD boot sector so it can boot on SSE2 machines), and copy a new oah750d so I can install.

 

After that, I tried the same method everyone else tries, update the Extensions folder on the DVD with the ones I think I need and burn. This didn't work.

 

What I noticed is every time time I would change anything in the /System/Library/Extensions directory, during the booting process the /System/Library/Extensions.mkext file wouldn't load and instead it would attempt to load all of the extensions in that directory.

The extensions directory on the DVD is very small. Not much in here. So that's why it will always fail if it doesn't load the Extensions.mkext file.

 

So after digging (when I started this I didn't have any knowledge of extensions, kexts or mkexts, or anything related to how Darwin really worked) I found out a few facts:

1. The Extensions.mkext is usually (I'll explain) a file containing all of the necessary kexts necessary to 'boot' the system. This file is generated based on specific flags in each kext's Info.plist file stating if its a necessary kext for booting. This file is generated, and regenerated on demand or whenever the system detects the Extensions.mkext timestamp is older than the timestamp on the Extensions directory.

2. When you add a new directory to the Extensions directory, the Extensions directory's timestamp itself gets modified and this tells the system to ignore the Extensions.mkext file because it's outdated and there are new Extensions so the system should rebuild the cache.

 

Now, #1. This works differently from the DVD and what gets installed on the HD. Everything works as described once installed on the HD, but the install DVD seems to already contain a pre-packaged Extensions.mkext that contains all of the necessary extensions to boot the system (At least on a real native Development system). They probably did this because they know the system can't create a new Extensions.mkext file on the DVD because, well, it's read only.

 

And #2. This kicked my ass all around and I don't know why. I could NEVER get it to read my Extensions.mkext once I modified the Extensions directory in any way. When I removed the entire Extensions directory, the system would then read the mkext file again but it wouldn't boot. I had to actually export all of the Extensions from the mkext and merge what is in the /System/Library/Extensions directory on the DVD. This is where and why I'm getting the Extension already loaded conflicts when booting from the DVD and what I think is the issue with the USB drivers on some machines.

 

So, up to this point, I learned that since I can't ever get the Extensions.mkext file to load AND keep the Extensions directory, I decided to just package everything I need into the Extensions.mkext file. I tried to just put all my extensions in the Extensions directory and removing the Extensions.mkext file but that was REAL slow too boot (And I don't entirely remember if it worked or not). But it turned out not to be important to keep the Extensions directory on the DVD because it doesn't seem to use this directory anyway. I'll explain this later also. And remember, the Extensions.mkext file is just a cache file and what I learned later is the system does NOT copy this file from the DVD to the HD. I'll explain later.

 

I found there are three utilities I needed:

 

mkextunpack - this will extract mkext files. I used this to extract the Extensions.mkext from the Darwin DVD and the OSX86 DVD.

kextcache - This is what you use to repack your own kextcache file.

lsmod - This will allow you to list what is inside "bill of materials" file and will tell you what is in the PAX file.

pax - This allows you to extract/create PAX files.

 

The biggest issue for me was when booting from the OSX86 DVD I would get the "still waiting for root device".

 

This seemed to be because it couldn't find my hard drives, which is partially true. It actually can't find your controllers. When it's 'waiting for root device' its actually waiting to find the DVD you're booting from. That's what it considers the "root device" at that point, since obviously we haven't setup any hard drives yet so there are no other root devices.

 

I installed Darwin on my machine and watched the install. I compared this to booting the OSX86 Dev DVD. The OSX Dev DVD would freeze up with the "looking for root device" prior to getting to this:

 

AppleIntelPIIXPATA: ICH5 ATA/100 (CMD 0x1F0, CTR 0x3F4, IRQ 14, BM 0xf000

AppleIntelPIIXPATA: ICH5 ATA/100 (CMD 0x170, CTR 0x374, IRQ 15, BM 0xf008)

 

Ok, so the issue is probably with AppleIntelPIIXPATA. Let's check them.

 

In order to do this, I extracted all of the extensions for Darwin and OSX86 using mkextunpack. You have to unpack both the PPC and the i386 versions from the OSX86 Dev DVD but only i386 from Darwin. I'm using Darwin for X86 of course.

 

to do, I created 3 directories:

 

drwxr-xr-x 232 root wheel 7888 Aug 28 17:40 extensions.darwin801.mkext.i386

drwxr-xr-x 190 root wheel 6460 Aug 28 17:46 extensions.osx86.mkext.i386

drwxr-xr-x 255 root wheel 8670 Aug 28 17:47 extensions.osx86.mkext.ppc

 

*Note - You will have to work as root. Or you'll be sudo'ing every command. These files need to all have the ownership of root:wheel in order to be repacked.

 

So now let's compare the AppleIntelPIIXPATA (I really don't need the PPC directory and I won't even compare anything in here for now, but I want to keep this so I can repack these into the Extensions.mkext)

 

-rwxr-xr-x 1 root wheel 76408 Aug 28 17:40 extensions.darwin801.mkext.i386/AppleIntelPIIXATA.kext/Contents/MacOS/AppleIntelPIIXATA

-rwxr-xr-x 1 root wheel 76712 Aug 28 17:46 extensions.osx86.mkext.i386/AppleIntelPIIXATA.kext/Contents/MacOS/AppleIntelPIIXATA

 

Slightly different sizes... I'm going to assume these are very similar, probably contain the same code basically.

 

Let's check the Info.plist files.

 

-rwxr-xr-x 1 root wheel 10282 Aug 28 17:40 extensions.darwin801.mkext.i386/AppleIntelPIIXATA.kext/Contents/Info.plist

-rwxr-xr-x 1 root wheel 3275 Aug 28 17:46 extensions.osx86.mkext.i386/AppleIntelPIIXATA.kext/Contents/Info.plist

 

Woah, very different. Seems the Info.plist contains information about the devices it should identify in the system to load this driver. It looks like Apple removed all but the required devices that are in the Development machine from being recognized, so this extension never loads and sees hardware other than hardware in the Devlelopment machine.

 

This theory was confirmed by opeing the plist file with the "Property List Editor". The OSX86 version contains 4 entries under "IOKitPersonalities", ICH6 ATA/100, ICH6 Serial ATA, Parallel ATA, Serial ATA. The Darwin version contains 17 entries, ICH ATA, ICH0 ATA, ICH2, ICH3, ICH4, ICH5, and so on. There's my ICH5.

 

I was afraid to replace the actual binary, thinking the binary file may have more/different code in that is needed for OSX86, so instead I just copied Darwin's Info.plist file.

 

I also thought I should add some other extensions that Darwin showed in kextstat when running, such as AppleI386PCI.kext, AppleI386GenericPlatform.kext, ApplePS2Controller.kext.

 

*Note: When extracting the kext's from the mkext files, you will lose the structure that the are actually stored with in the /System/Library/Extensions directory. They are stored 'flat' inside the mkext. For instance, on the Darwin CD, there is a "ApplePS2Controller.kext" which inside contains ApplePS2Keyboard.kext, ApplePS2Mouse.kext, ApplePS2Trackpad.kext. I had added just "ApplePS2Controller" from the Darwin CD which contained these 3 directories, to the mkext. If you extract the mkext, you will see the other 3 PS2 directories right under the root of your extracted directory instead of under ApplePS2Controller.kext. If you didn't gather this yet, .kext is basically just a directory... same as .pkg and .mpkg and a ton of other things in OSX. You can get into this by right clicking and picking "Show Package Contents" or get to it in a shell by just changing directories.

 

I also added the extensions I originally found on the OSX86 DVD under /System/Library/Extensions, which is where I think some of my conflicts are coming from when booting from the DVD... working on fixing this.

 

So, the darwin Extensions I added were:

JUST the Info.plist from AppleIntelPIIXATA.kext

AppleGenericPCATA.kext (Found in /System/Library/Extensions/IOATAFamily.kext/Contents/PlugIns/ on the Darwin CD)

AppleOnboardPCATA.kext (/System/Library/Extensions/IOATAFamily.kext/Contents/PlugIns/)

AppleVIAATA.kext (/System/Library/Extensions/IOATAFamily.kext/Contents/PlugIns/)

ApplePS2Controller.kext (Contains ApplePS2Keyboard.kext, ApplePS2Trackpad.kext, ApplePS2Mouse.kext)

 

So I ended up with these directories on my HD.

 

drwxr-xr-x 8 root wheel 272 Aug 28 21:11 extensions.osx86.cd

drwxr-xr-x 7 root wheel 238 Aug 28 21:08 extensions.osx86.mkext.additional

drwxr-xr-x 189 root wheel 6426 Aug 28 21:07 extensions.osx86.mkext.i386

drwxr-xr-x 3 root wheel 102 Aug 28 21:07 extensions.osx86.mkext.i386.old

drwxr-xr-x 255 root wheel 8670 Aug 28 17:47 extensions.osx86.mkext.ppc

 

Directories should be obvious, the extensions.osx86.cd contains all of the extensions on the osx86 cd, mkext.additional contains the additional extensions i'm adding to the mkext, mkext.i386 and mkext.ppc are the original extracted extensions and mkext.i386.old contains the old extensions I pulled out of mkext.i386 (Currently only contains the Info.plist from AppleIntelPIIXATA)

 

So to build your mkext, you do this:

 

kextcache -a i386 -a ppc -m Extensions.mkext extensions.osx86.cd extensions.osx86.mkext.i386 extensions.osx86.mkext.ppc extensions.osx86.mkext.additional

 

You should end up with a file that looks like this:

-rw-r--r-- 1 root wheel 17508393 Aug 28 21:11 Extensions.mkext

 

*Note: the size is different now than what's on the test dvd because I'm continuously changing/adding things.

 

Great! Take that Extensions.mkext and put it on your DVD, remove the Extensions directory and burn.

 

Reboot.

 

"Your hardware configuration is not supported by Darwin x86".

 

{censored}.

 

I patched the boot sector on the DVD, but when the new drives/partitions were initialized, they weren't patched.

 

I edited the three boot files I found that contained the same string that I modified on the DVD, boot, boot1u and cdboot.

 

Reburn... reboot...reinstall... reboot (probably could have fixed it other ways, but I didn't care)

 

*Note: I got passed this initially by just leaving the DVD in. Since that was patched, that boot loader would start first and if I didn't hit a key, it wouldn't try installing, but instead just boot OSX86 on the HD.

 

Success! Sorta.

 

Now, OSX86 see's my DVDROM drive and Hard drives just fine.

The installer installs and everything installs! Reboot!

 

Uh oh. Gray screen with the circle with a line through it.

 

That basically means the same thing, "unable to find root device" (this time it is looking for your hd)

 

Boot to Darwin and look at the volume. None of my extensions got copied to the HD.

 

Guess what. Extensions are not copied from the mkext... or the /System/Library/Extensions directory from the DVD obviously because there are so few of them in there to begin with. Extensions are actually in the "Essentials.pkg" You can see them by going on the DVD and going into /System/Installation/Packages/Essentials.pkg/Contents and typing "lsbom Archive.bom"

 

Ok, time to modify the Archive to contain the right extensions..

 

.... and after about an hour or two of trying that, I gave up. Basically I ungziped the Archive, extracted with pax, tried to repackage and create a new .bom (bill of materials) file. Didn't work. During install OSX would puke on it and give me errors such as "BomFatalError - cpio read error: bad file format" and "Package Authoring Error: Package "Essentials.pkg" is using a depreciated archive. Ok so whatever.

 

I decided to create my own packages that contained the extensions I needed. I also created a package to copy the SSE2 hacks over that Maxxuss has made.

 

(its getting late and I'm tired of typing this, want to get back to hacking, so the rest will be short)

 

I created these packages, found the information on how to modify the installer and added them in.

 

From the darwin install CD I decided I wanted to use the IOATAFamily.kext but I was afraid of putting the entire thing out there, knowing the Darwin version will only contain i386 versions (won't be fat) and the binaries may not contain the same functions.

 

Other info:

 

On my i865 based machine, rebooting doesn't work. I get stuck at "MACH Reboot" (if I booted with -v) otherwise it sits there with the little spinny thing. Shutting down however works fine, and the machine powers off properly.

Setting my HD to never sleep doesn't work. The HD still goes to sleep.

 

 

There will probably be lots of questions... I can attempt to answer some, but {censored} PLEASE google for info before asking me stupid {censored} like "how did you change directories?" or "whats a terminal?" I'm not going to answer those questions. No, it's not because I'm any better than you, I just think if you can find the info googling, at least attempt that first. I probably have a lot more info to share with people that they can't find easily, and I'd rather spend my time doing that and working on making more extensions work.

 

Oh and everything I've done above... remember... I am new to this. Everything above can probably be done better or different. My way is no where near perfect. If you have ideas or suggestions, please let me know.

 

My main goal is to help the community.

 

And meanwhile, enjoy.

Link to comment
Share on other sites

What I noticed is every time time I would change anything in the /System/Library/Extensions directory, during the booting process the /System/Library/Extensions.mkext file wouldn't load and instead it would attempt to load all of the extensions in that directory.

The extensions directory on the DVD is very small.  Not much in here.  So that's why it will always fail if it doesn't load the Extensions.mkext file.

 

 

I hope this is the right forum for this.

 

What happens if you "touched" the Extensions.mkext file after adding other kexts to the directory?

Would this allow it to load and then load the additional kexts in the directory?

 

I can't use the patch since my md5 checksum is different, so I'll be reproducing all the steps documented above. So I'm thinking about shortcuts ;)

Link to comment
Share on other sites

I hope this is the right forum for this.

 

What happens if you "touched" the Extensions.mkext file after adding other kexts to the directory? 

Would this allow it to load and then load the additional kexts in the directory?

 

I can't use the patch since my md5 checksum is different, so I'll be reproducing all the steps documented above.  So I'm thinking about shortcuts  :D

 

Tried the touching, i touched -a, -m, even -t with the exact date and time of the ones on the DVD... same issue...

 

Now, this may just have been me... but I got sick of dealing with it and took this route.

 

Yes, please, respond here to questions regarding my process. And I'm sure my process above is missing some steps, because i'm going based on memory... but I will help you recreate it as best as I possibly can.

 

You can make your own packages too if you want, just use PAX and extract the Archive from SSE2 and AdditionalExtensions and create your own package.

Link to comment
Share on other sites

Here's a site I used to learn how to make packages.

 

http://www.osxgnu.org/info/osxpackages.html

 

Or you can use this software:

 

http://s.sudre.free.fr/Software/Iceberg.html

 

But, that software doesn't fully work on OSX86... and I don't know squat about xcode so I can't recompile it... I asked lamer0 to do it, he's going to do it tomorrow possibly.

 

Read this if you want to learn how packages work and how they get installed.

 

http://developer.apple.com/documentation/D...reDistribution/

 

Read this if you want to see basically how to add packages to the install..

 

http://www.macosxhints.com/article.php?sto...003120216030560

 

And, I think that's enough for now.

Link to comment
Share on other sites

Thanks, bender12. In case anyone is confused, this is the thread for those interested in working with bender12 on improving his work. All other comments about the DVD can take place in the other thread.

Link to comment
Share on other sites

hi bender12, thx for your stuff. now my question:

 

say we can pack our own package into the installer now, wouldnt be possible to stuff anything like drivers or even custom apps into some pkg into the dev-dvd? if we can do that users, if not any users, are just a click away to install anything, given they know what they are doing, like "click this for SSE3 cpus only" when one is using a SSE2 cpu. :D

Link to comment
Share on other sites

and I don't know squat about xcode so I can't recompile it...

 

Hi bender,

 

Thanks for the great work and sharing.

 

Compiling with xcode seems to be easy. See for example: Post #2

 

ps. I have an Intel 865gbf board + Celeron D w/SSE3. I installed it using the xplode method. It is very stable except w/o coregraphics. I've been trying to get AppleIntel[89]*.kext loaded to see if I can get coregraphics working.

Link to comment
Share on other sites

hi bender12, thx for your stuff. now my question:

 

say we can pack our own package into the installer now, wouldnt be possible to stuff anything like drivers or even custom apps into some pkg into the dev-dvd? if we can do that users, if not any users, are just a click away to install anything, given they know what they are doing, like "click this for SSE3 cpus only" when one is using a SSE2 cpu.  :D

 

I think if you are to have any chance of installing this, you should make a custom SSE2 package and add it to the OSInstall.mpkg

 

During installation you would go into custom settings and tick the sse2 package, which will install the patched binaries over the system (sse3) ones

 

Does this make sense?

Link to comment
Share on other sites

I think if you are to have any chance of installing this, you should make a custom SSE2 package and add it to the OSInstall.mpkg

 

During installation you would go into custom settings and tick the sse2 package, which will install the patched binaries over the system (sse3) ones

 

Does this make sense?

 

That's what he did already, you can select if you want to install the maxxus sse2 patch or not

Link to comment
Share on other sites

yeah I can install from bender12's devdvd patch fine on sse3.

 

what im saying is since this is now a done job for selecting 'binaries' for specific cpus, its now just a matter of clearing/trimming the routines for this cpu sensitive task, no?

 

so next step is to add essential(PS2/open ati nv video/sound etc) drivers into a package into the install IMO. the problem is, how can I admin the installer.app to install the drivers/anything at a certain time, for example after the factory packages finished?

 

or does it not matter because once packages are in the 'Custom' submenu, everything there will just install after factory morsels?

Link to comment
Share on other sites

@ bender1

 

so you say that trying to edit the essential.pkg is worthless ? i got your same cpio {censored}.

 

I want to repackage it without all the ppc extensions, the nvidia & ati drivers and add some stuff.

 

there must be some way to do that

 

Well, the only way I can think of doing all of that would be to add some scripts into my package to walk the directory structure of the extensions and remove the ppc part using lipo. But personally, I don't think it's that much of a big deal to strip those. Doesn't take up too much room on the system.

 

As far as removing the incompatible video drivers, agan I was going to just do that with a script during the AdditionalExtensions.pkg or make a seperate package that way users can Check or Uncheck the option to remove them during install.

 

I've decided I don't want to mess with the standard packages included with the DVD, but rather give the users options on what to do. One option could be to remove the ATI/NVidia drivers, until we get working ones (if we ever do).

Link to comment
Share on other sites

Hi you misunderstood me , not using lipo, i mean all the pure ppc extensions, the one that are skipped if you do a kextcache -e -a i386 , there are around like 100 worthless ppc extensions and also the AppleTPMACPI.kext that is not needed and only causes slowdowns with a cracked rosetta :)

Link to comment
Share on other sites

iwant to help out just tell me what you need and ill get to work on it this seems to be the only project going anywhere im in tired of reading post like "i have no sound""i cant see my hdd"

i have time on my hands so let me know how i can help

Link to comment
Share on other sites

I got everything working the way i like thx to your suggestion to add a postinstall script to your addictional extension package, i've added a bunch of extensions to your bundle too.

 

The script basically deletes the worthless/notworking extensions.

 

I also made my own mkextcache in i386 mode kextcache -e -a i386 with the modified ata for nforce 3 and copied it on the dvd

 

I also force force the dvd and the installed os to boot with x86pc since that seems the most compatible mode.

 

I've added maxxus oah0750d to it too, that seems to stop a bunch of random atserver crash

 

I've burned it and it works like a champ :P

 

Thx for your work and suggestions bender1

Link to comment
Share on other sites

I got everything working the way i like thx to your suggestion to add a postinstall script to your addictional extension package, i've added a bunch of extensions to your bundle too.

 

The script basically deletes the worthless/notworking extensions.

 

I also made my own mkextcache in i386 mode kextcache -e -a i386 with the modified ata for nforce 3 and copied it on the dvd

 

I also force force the dvd and the installed os to boot with x86pc since that seems the most compatible mode.

 

I've added maxxus oah0750d to it too, that seems to stop a bunch of random atserver crash

 

I've burned it and it works like a champ :)

 

Thx for your work and suggestions bender1

 

What nforce3 ata driver are you using?

 

Did the one from AppleOnboardPCATA.kext not work?

 

This is what is defined in the plist for that.

 

<key>NVIDIA nForce ATA</key>

<dict>

<key>CFBundleIdentifier</key>

<string>com.apple.driver.AppleOnboardPCATA</string>

<key>Hardware Vendor</key>

<string>NVIDIA</string>

<key>IOClass</key>

<string>AppleNVIDIAnForceATA</string>

<key>IOProviderClass</key>

<string>AppleOnboardPCATAChannel</string>

</dict>

Link to comment
Share on other sites

What nforce3 ata driver are you using?

 

Did the one from AppleOnboardPCATA.kext not work?

 

This is what is defined in the plist for that.

 

                <key>NVIDIA nForce ATA</key>

                <dict>

                        <key>CFBundleIdentifier</key>

                        <string>com.apple.driver.AppleOnboardPCATA</string>

                        <key>Hardware Vendor</key>

                        <string>NVIDIA</string>

                        <key>IOClass</key>

                        <string>AppleNVIDIAnForceATA</string>

                        <key>IOProviderClass</key>

                        <string>AppleOnboardPCATAChannel</string>

                </dict>

 

i have a nforce3 revision2 a gigabyte GA-k8ns-939 and it wasn't recognized, it was using the generic ata so no udma. I've recompiled it adding the hw id of my chipset, there's a thread somewhere on the board.

 

It also hardlocks in acpi mode

Link to comment
Share on other sites

Just my thoughts here!

 

I'm not sure where this thread is going, but i was thinking about making things as generic as possible, i understood that was the whole point. Anyone can download the Darwin & DevDVD iso and pick the needed/missing kexts from it.

 

Personally i think most of the magic should be done in the pre- & postflight scripts ie. (re)moving kexts that will halt some specific configured system. So the dvd should be as bare as possible

but with a few (a lot!?) options in the custom installation to disable/remove specific kexts.

 

Fe. an option: Disable firewire extensions? [V]

all this does is 1 or 2 line of shellscript code in a postflight script, something like

"mkdir -p /Extensions.disabled && mv -v /System/Library/Extensions/*FireW* /Extensions.disabled/"

or

fe. an option: Disable ATI extensions? [ ]

which, if checked does the following in the postflight script

"mkdir -p /Extensions.disabled && mv -v /System/Library/Extensions/*ATI* /Extensions.disabled/"

Link to comment
Share on other sites

.... and after about an hour or two of trying that, I gave up.  Basically I ungziped the Archive, extracted with pax, tried to repackage and create a new .bom (bill of materials) file.  Didn't work.  During install OSX would puke on it and give me errors such as "BomFatalError - cpio read error: bad file format" and "Package Authoring Error: Package "Essentials.pkg" is using a depreciated archive.  Ok so whatever.

 

 

 

What did you use to create the pax archive?

 

It appears that the Archive.pax file is using an older cpio format:

 

utopia:~/TigerX86/Essentials.pkg/Contents% file Archive.pax
Archive.pax: ASCII cpio archive (pre-SVR4 or odc)

 

By default pax or cpio creates a different type of archive.

 

utopia:~/TigerX86/Essentials.pkg/Contents% file test.pax
test.pax: ASCII cpio archive (SVR4 with CRC)

 

I'm not sure how to use pax but for cpio you need the option

 

-H cpio

 

to create the older archive format that the installer appears to be using.

eg

 

find System | cpio -o -H cpio > Archive.pax

 

I haven't tested this... yet.

 

Maybe this might help.

Link to comment
Share on other sites

Just my thoughts here!

 

I'm not sure where this thread is going, but i was thinking about making things as generic as possible, i understood that was the whole point. Anyone can download the Darwin & DevDVD iso and pick the needed/missing kexts from it.

 

Personally i think most of the magic should be done in the pre- & postflight scripts ie. (re)moving kexts that will halt some specific configured system. So the dvd should be as bare as possible

but with a few (a lot!?) options in the custom installation to disable/remove specific kexts.

 

Fe. an option: Disable firewire extensions?    [V]

all this does is 1 or 2 line of shellscript code in a postflight script, something like

"mkdir -p /Extensions.disabled && mv -v /System/Library/Extensions/*FireW* /Extensions.disabled/"

or

fe. an option: Disable ATI extensions?    [ ]

which, if checked does the following in the postflight script

"mkdir -p /Extensions.disabled && mv -v /System/Library/Extensions/*ATI* /Extensions.disabled/"

 

Heh, we're thinking very alike. My next patch will do this, sorta.

 

I am removing KNOWN bad extensions, such as ATI and NVDA kext's. The firewire stays, because I haven't had any issues with firewire in my OSX86 boxes.

 

But you're right.. a more 'generic' installation would be to ONLY install the base kext's required to boot...

 

Personally I'm not going to tackle that project. I'm trying to make something thats still easy to install but more comatible with most hardware.

Link to comment
Share on other sites

What did you use to create the pax archive?

 

It appears that the Archive.pax file is using an older cpio format:

 

utopia:~/TigerX86/Essentials.pkg/Contents% file Archive.pax
Archive.pax: ASCII cpio archive (pre-SVR4 or odc)

 

By default pax or cpio creates a different type of archive.

 

utopia:~/TigerX86/Essentials.pkg/Contents% file test.pax
test.pax: ASCII cpio archive (SVR4 with CRC)

 

I'm not sure how to use pax but for cpio you need the option

 

-H cpio

 

to create the older archive format that the installer appears to be using.

eg

 

find System | cpio -o -H cpio > Archive.pax

 

I haven't tested this... yet.

 

Maybe this might help.

 

When I was trying to repackage the pax/bom files in the Essentials.pkg, I did try doing pax with the cpio option... didn't work for me, but I didn't spend entirely too much time on it.

Link to comment
Share on other sites

I am removing KNOWN bad extensions, such as ATI and NVDA kext's.  The firewire stays, because I haven't had any issues with firewire in my OSX86 boxes.

 

But you're right.. a more 'generic' installation would be to ONLY install the base kext's required to boot...

 

Personally I'm not going to tackle that project.  I'm trying to make something thats still easy to install but more comatible with most hardware.

 

Hi bender, thanks for all your effort.

 

Another problematic extension could be AppleFPMemDriver.kext

 

It gives people (myself too) problems with USB devices (mouse, keyboard, printer...)

Link to comment
Share on other sites

When I was trying to repackage the pax/bom files in the Essentials.pkg, I did try doing pax with the cpio option... didn't work for me, but I didn't spend entirely too much time on it.

 

I might work on this, if you feel it is useful.

 

I was thinking about making a list of all the files in the archives and seeing where the filess we've patched live. So they can be replaced.

 

However I'm a little bit behind in the patch list. I don't know what new developments there have been since the Maxxus 0.4 package. So I may not know everything that needs to be repackaged.

Link to comment
Share on other sites

I might work on this, if you feel it is useful.

 

I was thinking about making a list of all the files in the archives and seeing where the filess we've patched live.  So they can be replaced.

 

However I'm a little bit behind in the patch list.  I don't know what new developments there have been since the Maxxus 0.4 package.  So I may not know everything that needs to be repackaged.

 

Actually I know enough probably now to recreate the entire package... but thats actually not what I want to do anymore. That modifies too much of the system.

 

The way it works now, if you only select the SSE3 Package (which means, copy over the SSE3 files because the files that are actually on the DVD in the respective locations that normally would get copied during the BaseInstall.pkg, are the SSE2 cracked versions), you basically get the same install as the original DVD.

Link to comment
Share on other sites

You guys are way ahead of me... where's your patch?! ;)

 

Hehe, yeah, I'm going to work on one but I'm studying for my exams right now so I haven't got enough time.

 

My plans are to include other language packages in the DVD, so that the installer asks what your language is and installs it or (if this is too hard) al least have it copied to the system.

Link to comment
Share on other sites

 Share

×
×
  • Create New...