AnVAL (ACPI Loader)

[valv]

Sorry for late reply.. been testing booter...

Yeah, i know that one, i also have it on my test booter; pretty handy though there's already a way to do the same with a ramdisk.

Check the original patch and some talk about ramdisks, plus some of what i've been up to.

Ramdisk !? sounds like I misunderstood something about Data volatility issues related to this, like if a crash occurs u can say good bye to ur data. through resets and sleep, there's no problem preserving files on a ramdisk,but when u switch off u lose everything on it. That was my first feeling about it, till I learned from your linked post, that u load a .dmg file from disk. Cool but, what about the time spent to load the ramdisk image? is it minimal? will the memory remain locked? Using a ramdisk at boot for something like a liveDVD, sure I can understand, for what can it be beneficial when compared to loading stuff directly from disk? speeding boot-time? With this, we can really do nifty things, I know, but at this point, my imagination's gone out of ideas.

 

Or how about, in the ./postflight install script we could use a certain script / logic as under:

Run a uname -a in the background -> it's output at the end would have either:

1) i386

or

2) x86_64

 

Now, based on that info, we could create sub-routined code to re-build the mkexts. :pirate2:

sure but, if we need to have boot capabilities on both archs, we still have the limitation kextunpack is actually making.

on the other side, If we only needed to provide one arch-boot, kextunpack does this already (we can even force things with using --arch argument). then we adapt the mkext building process like u suggested. am afraid that this would not satisfy some people (willing to boot in x32 & x64). should we keep choice or not? what do u think?

Greetz,

[Freaky Chokra]

........................

sure but, if we need to have boot capabilities on both archs, we still have the limitation kextunpack is actually making.

on the other side, If we only needed to provide one arch-boot, kextunpack does this already (we can even force things with using --arch argument). then we adapt the mkext building process like u suggested. am afraid that this would not satisfy some people (willing to boot in x32 & x64). should we keep choice or not? what do u think?

Greetz,

 

Hi valv. There is lots to read today. Hope you have time and enough patience to go on today, buddy.

 

Firstly, About the above. Yeah, we could keep a choice. But as I said, If we run:

     The uname utility writes symbols representing one or more system charac-
    teristics to the standard output.
    The following options are available:
    -a      Behave as though all of the options -mnrsv were specified.
    -m      print the machine hardware name.
    -n      print the nodename (the nodename may be a name that the system is
            known by to a communications network).
    -p      print the machine processor architecture name.
    -r      print the operating system release.
    -s      print the operating system name.
    -v      print the operating system version.

uname -v prints out as x86_64.

 

The -p gives out i386, I just tried it to narrow down the txt output.

Why do this? I reason out this way:

If the output of uname -v is not i386, that means, the user is probably running things in 64-bit mode. Even kernels, kexts, and certain 64-bit apps. Geekbench for example. and certain apps like Citrix, etc. I know so, coz today itself I tried.

 

That app is a hiccup. After I installed it, the server had some bug, hence I'd to boot to windows to get work done.

Then, when I tried booting to SnowLeo, there was kernel panics caused by com.deterministic.something something.

I booted to Leopard, found the cause, it was Citrix Kext. Removed it. Still I couldn't boot for four hours! read on...

 

Now you see, that user would benefit, if this script ran, rebuilt kexts in 64 bit mode. That would make his next boot up much simpler.

Those, who are on i386, a different script would run, again, rebuilding kexts, of 32-bit mode.

The kextcache rebuilding commands, I've found on the net itself, some1 was kind enuf to xplain it in detail.

 

Now, what went on today.........

Finally, I'm done thoroughly testing your bootloader. And modifying the com.apple.Boot.plist. You can see as under.

Including the boot flags that you had attached a screenshot of.

 

I'm currently using this:

 

Well, as the Citrix thing caused problems. Then, when I fixed from Leo and booted here, I'd made all changes simultaneously.

That included editing the DSDT, editing the com.apple.Boot.plist, and removing the NullCPUPowerManagement.kext that blocked IntelCPUPowerManagement.kext.

 

Also, I checked your compiled DSDT, U optimized it!!! I noticed the changed ASCII values to hex. Something beyond my capacity. Now, other things too.

You recommended adding IRQ to RTC. I still don't know how. I'm using a modified (rather appended) version of the DSDT posted by BlackCH and DB1 @ [How to] ASUS P5K-VM guide by them.

About the erroneous lines of code I'd commented out, and why it wouldn't compile… Silly as it may seem, but I jumped at the availability of the latest iASLME May 2010 version which is 64 bit.

There is a WHY so & How To on the error. HERE:

My DSDT, which is based on P5K-VM DSDT version 3.2, had certain lines. The lines which I had commented out. The error as seen in the post I mentioned above, was due to ZERO difference between Min and Max values in the end return function.

 

Now, After merging changes made by you, and removing the ALS0 and SMS0 functions, which are general emulators (on desktops) for fake Keyboard Illumination and Sudden Motion Sensor respectively, didn't need to be included. <- I think so.

I had several Kernel Panics due to these lines. Till yesterday everything was fine. But not today. :whistles:

 

Next, as I had put in all the last flags of your Boot.plist into mine too, and enabled the IntelCPUPower.kext, many things were causing kernel panic.

ACPIPlatform followed the KPs caused by AppleSMC.kext loading due to the SMS device. After removing that, CPUpower and ACPIPlatform together.

 

After, fixing these errors, by removing few lines from DSDT, viz. FireWire (cause I have none, and never will!), certain AR11, AR12, etc params in the DSDT inserted by DB1.

Then, I tried compiling the DSDT using the older iASLMe. IT Worked! That'e when I thought there was something wrong with the newer iASLME. And found how to do it. The newer iASLME is supposed to be better and detect errors, and facilitate in compiling for 64 bit systems or on 64-bit systems.

 

So finally done, booted using -f -v. Booted perfectly. But on rebooting, INTELCPUPower caused problems over and over again. SO I again reinstalled the NullCPU… And deleted all your lines from my Boot.plist to carry on one step at a time.

Then rebooted couple of times, using -f -v. Rebuilt kexts every time from Root login.

 

Then, finally, started adding one line at a time.

 

Starting with UpdateACPIVersion=true. No other lines added. Went smooth, completely functional and booting to desktop.

 

Next, oemSDDT=No. Smooth, completely functional and booting to desktop.

Next, oemFADT=No. Smooth, completely functional and booting to desktop.

 

Next, oemSSDT=Yes. Smooth, completely functional and booting to desktop.

Next, oemFADT=Yes. Smooth, completely functional and booting to desktop.

 

I'm attaching the video I spoke about. Here: boot_output_FreakyChokra_previously_02.mp4.rar

Just unRar it to view it.

 

The error I told you about, it lists all the possible ??DT.aml files that it could not find.

 

After trying out the above lines, several of those "not found" errors have disappeared. Probably, as you found out that in "nomaj's" case, he was using a genuine Macbook, same way probably this bootloader could also read our FADT and SSDT tables. Or it did in my case. So, that's today's discovery.

If it did or if that's what it is supposed to do, great thing. If it wasn't supposed to do so, but did anyways -> again super great!

But the errors were minimized: the ones you would see in the attached VDO.

Lastly, As of yet, I'm running the DSDT without an IRQ for RTC. Tee hee. Coz I don't know how to.

 

And, with the lines posted above as "=Yes", Machine is still smooth, and stable. But more importantly, bit faster than before. Checked with Geekbench.

Additionally, I haven't tried removing SleepEnabler.kext and other things that get the PC to sleep using OSX, to try if loading original Mobo tables can give original Mac Desktop functionality, ok? As in enabling SpeedStep, or Sleep, or detecting hardware, etc.

That feat is yet unaccomplished. Probably tomorrow.

 

Phew! See you then, valv!

Hope this would help you all! You and Andy.

 

Now, I'll probably doze off. More to do tomorrow!

 

Sayonara! It's Golden Week since yesterday!

Freaky Chokra

[Azimutz]

Back.. @Freaky, sorry for just aswering now. You asked about VoodooHDA.. i'm a complete noob at that it's still a bit over my knowledge. I'm not even using VoodooHDA atm as it causes me a lot of kp's while testing booter and not only.

 

@valv, ramdisks are being overlooked and that's no surprise because as you may have already noticed, there's not much info around about using them; even those commands to handle ramdisks are absent from the Help file. Most people think they are only useful to load retail DVD on a pre-boot disc but that's not true. We can load ramdisks from any were and they can hold from a simple file to complete configs. Don't get mistaken by the "ram" on ramdisk; anything loaded by the booter it's loaded into ram and thus it's volatile data, meaning when we reboot/shutdown it's gone and has to be loaded again. Just to answer some of your doubts:

- loading a ramdisk from HDD it's pretty fast, slower when loading from USB, obviously; the data on it matters, the more the slower it gets.

- the main purpose is to load alternate files/configs.

But, this is another matter. I will share my experience soon... now let's go to business...

 

About the booter installer.. slept over it, didn't dream of it but, been thinking. I failed to see were that TestExtensions key would fit!? maybe you're talking about the "philosophy" behind it?.. Anyway, copy the mkext can be useful (how about not touching at all on the kexts/mkext?) and things should go more or less like @Freaky conceptualized on his last post.

As i see it, we should do something on these lines:

- first, we let the user choose what to do, just install booter or also process "extras".

For that we need to remove the unpack routine from the postinstall scripts on Standard, HFS and FAT packages! That way, if we just want to install the booter we can bypass any "extra" stuff. As it is, the unpacking it's done at the end of those scripts, meaning that even if we unselect Extras on the installer, it will still unpack & remove the mkext.. not good.

 

- next we need to merge the unpack routine with the kextcache one (in postinstall script on Post package) on separate scripts.

 

- next we either let the user choose what to do (easier) or get things automated.

 

- if we automate things:

-- check the system we are booted on; if Leo, the existing routines are fine to use!

-- if it's Snow, we check the kernel like @Freaky suggested or ask the user to choose according and so on...

 

- the mkextunpack command it's the major pain in... how do we handle it? I think there's a solution but, i'm not tuning in atm... maybe later...

As it is, people would always end up with one arch mkext.

 

Makes sense?

The sky is the limit here... We can also make just a booter installer and have people doing the rest. For instance, have the installer installing the "Preference Pane"

and people could tweak what they need before reboot. Preference Pane would need some updating.. already needs, anyway.

We also need to consider, is everyone going to use the installer all the time? Updating the booter, unless there are major changes on boot0 and boot1*, is a matter of replacing boot file. In case of first install, we don't even need to care about unpacking mkext as supposedly there's none in use.

Many things to consider.. when i start thinking of them, i quickly jump to "do it by hand, Azi"

As i stated, i have nothing against installers; i'm just against the way most people use them on OSx86! I learned/learn a lot of stuff just by looking at the scripts present

on most installers, they are very educational; if most people did the same before and after they use them...

 

Going on for some more testing....

 

Edit =======================

 

@Freaky, some remarks:

- you don't need to specify arch=x86_64 and certainly not both arch=x86_64 & -x64 (same stuff! -x64 is used on PC-EFI; it's also on Chameleon for compatibility).

If your CPU is recognized as 64 bit capable, the booter will boot into k64 by default. This is how it works on Chameleon.

 

- this "0:0" & this "root:wheel" are the same thing

Edited May 4, 2010 by Azimutz

[Kasakka]

what about Graphic Card? did u patched it with dsdt already? I think this may not be related to bootloader. u better investigate other parts.

post your DSDT, will see what could be done (or not).

 

Attached is my DSDT.dsl and the original (dsdt_AWRDACPI.dsl) extracted in Win7 with iasl. Everything I've added or changed has been marked with comments.

 

If someone can take a look at it and figure out what I'm doing wrong it would be much appreciated.

 

Abit IP35 (P35, ICH9R in ACHI mode)..probably pretty close to reference board since Abit never bothered adding any cool features to these.

Core2Quad Q9550

GTX 260 896 MB, 2xDVI

Only extra kexts are FakeSMC and modified IONetworkingFamily for Marvell 88E056 Gigabit Ethernet support. Tried with and without SleepEnabler.

 

The system shuts down (power off) but when waking up by hitting a key on keyboard or mouse I can hear the hard drives spinning up but get black screen and it seems nothing works because if I try to use Spotlight to launch something there is no HDD activity. Sleep is the only thing that doesn't seem to work...

kasakka_dsdt.zip

[Trauma!]

Hy Valv and Andy,

 

I've tested your loader since i'm quite interested in ACPI experiments. But I did not push the tests that far, since it seems like my config file is ignored (no theme override, no GraphicsEnabler).

 

I've used Wait options to see what's happen, and it look like smbios.plist, dsdt and kext files gets loaded. But not the com.apple.boot.plist...

 

Any clue ?

[Azimutz]

I've used Wait options to see what's happen, and it look like smbios.plist, dsdt and kext files gets loaded. But not the com.apple.boot.plist...

 

Any clue ?

Hi @Trauma. I can give some input on that. Andy merged TennisGeek's patch into his branch; the "config" part interacts with Boot.plist loading. I have the patch on my test booter, merged without changing any of the rest; works properly, but Andy made some changes to the patch so, you better take a look on that direction

[Trauma!]

Hey Azymuth,

 

I'ts look like the problem come from that part. actually andy's booter only load the config file form the target partion and note from the booter partition.

 

In my setup i use a booter partion (on wich my extra folder is) then next i load the the Apple raid boot helper partition. If i move my extra folder to the boot helper partition, GE works again.

 

So actually Anv's booter wont be able to load a non embeded theme... This should be corrected i think.

 

Thanks for the TennisGeek's patch; i'll look into it and will try to fix that behavior.

 

Bye.

[Azimutz]

Hi have to a correction, Andy didn't changed the patch, he just used another diff TG posted here (sorry Andy ).

I'll have to look at this better but, try changing here to bt(0,0) or add

"bt(0,0)/Extra/",

...

I think it's using the Override paths by default, only rd(0,0)/Extra/ and /Extra/ are checked plus the others, no bt(0,0)/Extra/.

Checking...

 

Yep, i can't see any other reason. I used the code on the other topic i pointed you; can't see why TG changed it later?! The other code was fine!

I only used the "config=" part and i implemented it a bit different, mainly without removing "canOverride" and "loadOverrideConfig" stuff;

this stuff is needed and has nothing to do with "config=". Config=blabla.plist is a one time thing to test another Boot.plist just by using another

name for it (not another path).

"loadOverrideConfig" is permanent override.. well, not anymore, i added a key to disable it; it can be pretty annoying

 

I don't really quite get that Theme problem.. Lebidou explained it one time but, as i never stumbled on it As far as i understood we could only use another

theme if the booter had been compiled with theme embedded?? or something like it.. whatever. I've been compiling the booter my self for at least the last two months,

without theme embedded and i never had any problem.

 

i'll pm you with the stuff i've been working on.. just cleaning it

[Freaky Chokra]

Attached is my DSDT.dsl and the original (dsdt_AWRDACPI.dsl) extracted in Win7 with iasl. Everything I've added or changed has been marked with comments.

 

If someone can take a look at it and figure out what I'm doing wrong it would be much appreciated.

 

Abit IP35 (P35, ICH9R in ACHI mode)..probably pretty close to reference board since Abit never bothered adding any cool features to these.

Core2Quad Q9550

GTX 260 896 MB, 2xDVI

Only extra kexts are FakeSMC and modified IONetworkingFamily for Marvell 88E056 Gigabit Ethernet support. Tried with and without SleepEnabler.

 

The system shuts down (power off) but when waking up by hitting a key on keyboard or mouse I can hear the hard drives spinning up but get black screen and it seems nothing works because if I try to use Spotlight to launch something there is no HDD activity. Sleep is the only thing that doesn't seem to work...

Hi Kasakka, I'll be going through your DSDTs today.

 

However, in the meantime, Can you do some quick checking and modifications to your mobo?

As your mobo isn't much different from mine, except that it has G35 chipset, mine has G31 chipset. ICH9 is common here. Errata. <- edited on May 6 2010, 09:56 AM.

So is the Southbridge and Marvell 88E056 Gigabit Ethernet.

Probably all other registers and Chipsets are pretty much the same. Doesn't matter. But your BIOS is Award. Mine is AMI.

Hope that isn't the limiting factor…

 

Well, my motherboard everything works perfectly. Only sleep and wake were issues.

Till @DB1 figured out that the motherboard USB voltage needed to be changed from regular 5V to +5VSB.

There are jumpers for it. Usually the default is pin 1-2. You need to move the jumper from pin 1-2 to 2-3 for all that are available. All USB voltage regulators, and one distinct Keyboard Power labeled as KBPWR. Same jumper switching method. These devices aren't "jolted awake" by the necessary "voltage". Hence, the changes.

And see if that would give any results?

 

Next, as you have said that your DSDT has GFX section patched. However, GTX 260 is new. Not yet featured in Macbooks or MacPros.

Maybe, its Power Management isn't correctly being identified… That we'll need to disassemble and check.

 

Lastly, I suggest you don't remove the new SleepEnabler version 10.6.x (yes there is an "X" there, it's the new convention). Note the "V" is in capitals as under. Use it exactly as it is shown.

 

And use pmVersion=19 if your Snow Leopard is 10.6.3.

OR -> pmVersion=18 if your Snow Leopard is 10.6.2.

OR -> pmVersion=17 if your Snow Leopard is 10.6.1.

DO use the NUllCPUPowermanagement. It won't prevent Sleep. It Simply Blocks the cursed IntelCPUPowerManagement.kext from Apple. IT'S Pure EVIL! Grrr

 

Till then, simply wait and post the results soon.

It'll be better if few of us could be IM'ing. MSN or GTalk. Can it be possible? You know where to find the ID's.

[BuXb]

the installer does not install to many volumes on USB drives. This has been a well known error which got fixed in other installers months ago.

[valv]

uname -v prints out as x86_64.

try this echo $HOSTTYPE

sorry guys, have many networking stuff to test (for my office, whole architecture's rework). time is being just on me these days. I'll be back soon.

Greetz

[Freaky Chokra]

try this echo $HOSTTYPE

sorry guys, have many networking stuff to test (for my office, whole architecture's rework). time is being just on me these days. I'll be back soon.

Greetz

 

Hey valv.

 

Tested it. Confirmed simple output of x86_64.

 

That should get things ahead a little bit.

 

Regards,

Freaky Chokra

[Trauma!]

Hi have to a correction, Andy didn't changed the patch, he just used another diff TG posted here (sorry Andy ).

I'll have to look at this better but, try changing here to bt(0,0) or add

"bt(0,0)/Extra/",

...

I think it's using the Override paths by default, only rd(0,0)/Extra/ and /Extra/ are checked plus the others, no bt(0,0)/Extra/.

Checking...

 

Yep, i can't see any other reason. I used the code on the other topic i pointed you; can't see why TG changed it later?! The other code was fine!

I only used the "config=" part and i implemented it a bit different, mainly without removing "canOverride" and "loadOverrideConfig" stuff;

this stuff is needed and has nothing to do with "config=". Config=blabla.plist is a one time thing to test another Boot.plist just by using another

name for it (not another path).

"loadOverrideConfig" is permanent override.. well, not anymore, i added a key to disable it; it can be pretty annoying

 

I don't really quite get that Theme problem.. Lebidou explained it one time but, as i never stumbled on it As far as i understood we could only use another

theme if the booter had been compiled with theme embedded?? or something like it.. whatever. I've been compiling the booter my self for at least the last two months,

without theme embedded and i never had any problem.

 

i'll pm you with the stuff i've been working on.. just cleaning it

 

@Azimuth: Your where right, it seems only the overide paths are used. By adding

"bt(0,0)/Extra/",

it fixed both of my problems (GE and themes loading). BTW i do not understand why it's only scaning the overide paths ? And do this override isn't redundante with the rescan option ? I don't really understand the use of this patch... config= options is there to handle this. Another usless options added to chameleon i think.

 

About the theme override, in the past (RC4 and older) it was only possible to override the default theme when using an "embedtheme" build of the booter. Non embedded GUI version of the booter was not able to load themes, wich was stupid. I guess Asere fixed that...

[valv]

@Azimuth: Your where right, it seems only the overide paths are used. By adding it fixed both of my problems (GE and themes loading). BTW i do not understand why it's only scaning the overide paths ? And do this override isn't redondente with the rescan option ?

 

About the theme override, in the past (RC4 and older) it was only possible to override the default theme when using an "embedtheme" build of the booter. I guess Asere fixed that...

@Azimutz and Trauma! thanks for this, It seems like a good time for an update.

going to rebuild.

 

Greetz,

[Freaky Chokra]

@Azimutz and Trauma! thanks for this, It seems like a good time for an update.

going to rebuild.

 

Greetz,

 

I'm in! I'm in! Bring in the new stuff! On that note, what is "GE", as in for the booter?

 

Btw, valv. AnV's that new fakesmc.kext for Snow, Leo, and Tiger...

 

I tried installing it today. No success. You got any?

To get it working I even upgraded my BlackCH XxX 10.5.6 with AnVXnU 9.8.0 kernel

to 10.5.8 combo update using Vanilla kernel 9.8.0 kernel.

 

Everything works perfectly except the Audio! It broke. As promised.

Anything you know why the new fakesmc.kext doesn't load in my Leopard install?

 

Regards,

Freaky Chokra

[Azimutz]

@Azimuth: Your where right, it seems only the overide paths are used. By adding it fixed both of my problems (GE and themes loading). BTW i do not understand why it's only scaning the overide paths ? And do this override isn't redundante with the rescan option ? I don't really understand the use of this patch... config= options is there to handle this. Another usless options added to chameleon i think.

 

About the theme override, in the past (RC4 and older) it was only possible to override the default theme when using an "embedtheme" build of the booter. Non embedded GUI version of the booter was not able to load themes, wich was stupid. I guess Asere fixed that...

About the Theme.. so, i understood it correctly. I never stumbled on the problem because, i was using RC4 (like most people) and it has theme embedded. When i started to compile it from the repo, i also used to embed theme, then by the time i started to compile without theme embedded, was probably fixed. Check the comment i pointed by Zef on rev 87, i thinks that's it... i only started compiling without theme embedded after that.

 

About TG's "config" patch.. it's still not added to Chameleon; Andy saw it and added it to his "branch", apparently without testing!?

About "config" it self, i said the same thing to TennisGeek.. "the thing is working fine, why mess with it??"; well, i talked too soon!

I went to try it and it doesn't work at all. There's no function on the code, to be called by "config" and load an alternate Boot.plist! I don't know why it is on the Help file at all?? Always assumed it was working and i must have confused it with another thing because, i was pretty sure i'd tested it working

So, TG's patch is fine, just needs to be implemented correctly. But the one Andy used is seriously screwed!!

As far as i can understand, the function is called on options.c and Override set as "true". Then, on the actual function, the screw up starts here; Override is "true" so dirspec becomes the "override paths" and there's nothing that changes it after, as Override continues to be "true". I'm just an apprentice so, i can be wrong

 

About "rescan".. i guess you are talking about ramdisks!? As it is, a Boot.plist on a ramdisk that's not aliased as bt(0,0), will always override the default one.

That's were loadOverrideConfig function comes in. It's also screwed on this booter, as TG's patch completely removes it. Not good, as i already mentioned.

 

Going to dinner now, after i'll send ya my stuff.. i added some comments to these functions that will help understanding them better.

And over here it's working like a charm... just finished testing install on EFI partition, passed.

See ya later mate...

 

 

@Azimutz and Trauma! thanks for this, It seems like a good time for an update.

going to rebuild.

 

Greetz,

Yes, this needs some serious fixing! If you can handle it, roll up your sleeves and do it, otherwise get Andy to work on it

That stuff i told Trauma to try, was just to be sure what the problem is.. it's not a fix!!

The "config" stuff i used is the one on this post, bar.diff.

[Freaky Chokra]

I'm in! I'm in! Bring in the new stuff! On that note, what is "GE", as in for the booter?

@Azimuth: Your where right, it seems only the overide paths are used. By adding it fixed both of my problems (GE and themes loading).

Btw, valv. AnV's that new fakesmc.kext for Snow, Leo, and Tiger...

 

I tried installing it today. No success. You got any?

To get it working I even upgraded my BlackCH XxX 10.5.6 with AnVXnU 9.8.0 kernel

to 10.5.8 combo update using Vanilla kernel 9.8.0 kernel.

 

Everything works perfectly except the Audio! It broke. As promised.

Anything you know why the new fakesmc.kext doesn't load in my Leopard install?

 

Regards,

Freaky Chokra

 

Whoooooopsss!

 

Was editing my post... and became a double post...

[Azimutz]

@Freaky, GE=GraphicsEnabler.

[atlee]

Installer fails, bootloader still gets installed but the installs stops somewhere around adding the Extra folder and kext's to the root drive. this would probably be similar to RC5 Pre8 correct?

 

GA-X58-UD3R, Core i7 920 10.6.3 bootflag arch=i386, and your installer includes quite a lot of kexts but shouldn't they be asked as options before clicking install as all system are different and don't need all the included kexts?

[valv]

hi all,

too much excitement and work arounds, but nothing! not so good news. First I merged a diff from Zef out of rev 87 (to fix back the theme thingy), compiled with and without embedtheme, same thing: themes not reacting. then I went hand-patching stringTable.c file putting bt(0,0)/Extra into it, rebuilt, booted from test-drive, and guess what ? always nothing, it is gone even harsher complaining about not willing to read some Bios Memory thing . went back and came with an untouched ( from my part ) update (as of today, like 4 hours ago) thanks Andy. minimal updates though (@Andy hope the best is coming soon if u read me). If anybody would like to test, here please boot.zip, nothing related to what we're at: sound fix + cpu type corrected ..

 

sorry guyz, when was stuck, heard your voices claiming for arch fix.. but I was already stuck. it doesn't seem that complicated though. simpler we go, faster and nicer the code would be. Something I cannot help asking about, is why so ? why do we have to extract things from mkext if it exists, add (old) kexts to same folder just to rebuild an mkext that is half working ? why not just trick kextcache to give as the magic of the -e arg. I know. this seems to be crazy, but tested on terminal and worked ok. only problem: time spent moving kexts on /S/L/E/ forth and back .

 

@Azi, would need some advice as of config=.diff file. it doesn't stick in. errors merging and noway to compile. any thoughts?

 

@Chokra, have got hard times too when trying Andy's fakesmc. at end it did work. don't take out sms0 from ur dsdt.

 

Greetz,

[valv]

Installer fails, bootloader still gets installed but the installs stops somewhere around adding the Extra folder and kext's to the root drive. this would probably be similar to RC5 Pre8 correct?

 

GA-X58-UD3R, Core i7 920 10.6.3 bootflag arch=i386, and your installer includes quite a lot of kexts but shouldn't they be asked as options before clicking install as all system are different and don't need all the included kexts?

ok, it is clearly that the installer would only work with leopard for now (this mis-directing ), have to update first post one day. regarding the choice to be given about kexts, then yes, u probably missed that button rights on the window.

[Bruce Wang]

My notebook is HP DV4 and it's BIOS is Insyde. When boot, before showing boot menu, it shows some texts like unable to read from BIOS or unable to identify BIOS and asks to run Dump-Bios or something then send the dumped file to somewhere. Just unable to find the app/script mentioned.

[valv]

My notebook is HP DV4 and it's BIOS is Insyde. When boot, before showing boot menu, it shows some texts like unable to read from BIOS or unable to identify BIOS and asks to run Dump-Bios or something then send the dumped file to somewhere. Just unable to find the app/script mentioned.

Are using the files from first post (i386 or installer?) ? same thing happened here but with a version I did not yet upload. really weird !

btw, do u still can boot into system? is acpi loaded ok?

[Bruce Wang]

Are using the files from first post (i386 or installer?) ? same thing happened here but with a version I did not yet upload. really weird !

btw, do u still can boot into system? is acpi loaded ok?

Yes, I can boot into system. I used the i386 file from the first post and manually installed it. Apart from the weird display at the beginning, everything looks OK.

[Freaky Chokra]

@Freaky, GE=GraphicsEnabler.

Thanks!

Uhm... very silly of Me.

Regards,

Freaky Chokra