Monthly Archives: August 2011

Update to Chameleon Bug

Posted on by

Note: As of myHack 2.1 this bug has been resolved and is no longer an issue – although if you do not have your VESA graphics mode defined on problem systems the apple logo will not be centered, but rather, it will be in the top left of the screen and you will not be able to see the spinner wheel – the system will boot though.

After a few more hours of meklort toying around and me helping to test the builds this problem has been solved, well for the most part…

Chameleon build 1407+ boots as would be expected with -v boot flag, without flags
however there is a minor problem still. The apple logo will appear in top left corner of screen, the rest of the screen is blank (black) and no spinner is visible. If patient though it will boot still, rather than hanging. Having a VESA resolution defined in the Boot plist will avoid this undesirable behavior on effected systems, but at least it will still boot even without, so that’s good enough for free software as they say.

I will be releasing an update to the myHack app with a newer build of Chameleon as well as a few other small changes in the days to come.

Original Post:

So I woke up refreshed this morning and meklort was kind enough to tell me what to replace in boot.c to get builds 1214-1220 to boot. I narrowed down the cause to a single commit.

You can read more here: http://forge.voodooprojects.org/p/chameleon/issues/146/

So by modifying drivers.c and reverting this change I got build 1394 to work as expected but there is probably a better solution to this problem, I’m going to wait until I hear back from the Chameleon team before deciding if I release the next revision of myHack with my alteration of Chameleon 2.0 or with a solution that they come up with.

For now just define the VESA graphics mode in the Boot.plist as I described in my last post.

Chameleon Bug and myHack 2.0 RC4+

Posted on by

Note: As of myHack 2.1 this bug has been resolved and is no longer an issue – although if you do not have your VESA graphics mode defined on problem systems the apple logo will not be centered, but rather, it will be in the top left of the screen and you will not be able to see the spinner wheel – the system will boot though.

So I managed to reproduce and track down this bug that a few people reported to me in build 1332 of Chameleon that I used in myHack RC4+. The bug is as follows:

After boot menu, if booting without flags – instant reboot

After boot menu, if booting with -v boot flag it brings you to a black screen, with a white bar on top that flickers, but that is as far as it goes.

After boot menu, if booting with -f or -x boot flags it will boot.

While the exact cause of this isn’t yet clear to me I have narrowed it down considerably by downloading, compiling and testing many many revisions of the chameleon trunk starting with the one I knew worked that I used in myHack RC3-  (2.0 RC5 revision 1203) my results were as follows:

  • 1221 = broken (bug I mentioned above is reproduced, all future revisions including 2.0 final – r1394 – share this bug)
  • 1220 = can’t boot (other bug)
  • 1219 = can’t boot (other bug)
  • 1217 = can’t boot (other bug)
  • 1216 = build failed
  • 1214 = build failed
  • 1203 = works

 

So going through svn, so much has been changed between then and now it’s hard for me personally to figure out how to fix it, nothing obvious jumps out of me, but I only dabble a bit when it comes to Chameleon’s rather insane code structure.

I spent way more time on this than I should have (hours and hours), but I really wanted to drop the RC from myHack with a nice clean 2.0 Chameleon without the RC on it either, it doesn’t appear I will be able to do that until this bug is fixed – or at least I would prefer not to.

I did find a simple work around though – if you add a VESA graphics mode to your boot plist it will boot normally, in revision 1203 this isn’t needed, but everything after that (that works) apparently needs it on _some_ graphics cards – the card I was testing with is a 9800GTX+. It shouldn’t need it but I recalled from a similar issue I ran into a couple years ago that it might be the case, and indeed it was.

So if you are having this issue open up org.chameleon.Boot.plist and add:

    <key>Graphics Mode</key>
<string>1024x768x32</string>

for 4:3 displays – or for 16:9 something like:

    <key>Graphics Mode</key>
<string>1280x720x32</string>

etc…

NOTE: The VESA mode you define must be supported by your graphics card bios and your monitor, using ?video at the chameleon boot prompt will give you a list of the modes supported by your graphics card.

I’ve passed these findings along to cosmo1t and meklort and I’m sure they will look into the matter further, but the information I posted above will help in the meantime if you happen to run into this problem.

myHack 2.0 RC4.1

Posted on by

This version is now deprecated, consult the downloads page for a link to the latest version.

This version was downloaded 42431 times.

This is just a minor edit of RC4′s resources. arch=i386 in boot plist caused more trouble than it was worth, i thought it might make things easier on people who relied on older kexts that are 32bit only, since 64bit apps can still run in userspace as long as there are x86_64bit instructions available in the CPU regardless of if the kernel itself is running i386 or x86_64 I didn’t think it would cause any trouble.

But it does cause some trouble, because some 32bit only kexts loaded for people who weren’t expecting them to load – this is what resulted in some blank screen issues for a few people with some graphics cards (x3100 was referenced in particular for one users report).

So anyway no reason to really download all over again, but just remove arch=i386 line from org.chameleon.Boot.plist or type arch=x86_64 at the boot prompt if you are having any issues with the latest version of myHack.

Download was updated and is still available on the myHack 2.0 RC4 release page, if you have RC4 already though please don’t waste the bandwidth – you can just edit the plist in Resources.

About v0ltr0n

Posted on by

So I’ve seen a lot of speculation and buzz around the web about this, being someone who is “in the loop” I wanted to inform the public as to what exactly is going on.

As many know our good friend Nawcom has taken a much needed break from the scene, he may or may not return, either way I wish him the best, I have always valued his contributions and witticisms over the years – he was even kind enough to update myHack 1.x for me while I was taking my own break from the scene. He is and will be missed.

Meklort has shifted his focus toward the development of XNU/Xen – a truly inspired idea which I can’t wait to see come to life. He has been gracious enough to pass what work was done on v0ltr0n into my tender loving care, this includes the much anticipated and sought after kernel patcher and kext patcher modules for Chameleon.

Now as many (if not all of you) know, my focus has always been on Vanilla installations, mostly because I find that they are the most worth the effort, but also because I like sharing knowledge and understanding of how and why things work. I do, however, see the value in a more flexible simplified installation that handles patching in a *CLEAN* way.

Unlike automated or shared dsdt patches and using all sorts of poorly pieced together kext’s and kernels these modules can do a lot of patching but they do so without altering the system files. The boot loader does the patching dynamically, in memory, rather than writing changes to the disk. So it’s basically the best of both worlds, it extends support to a wider array of hardware without leaving a mess of your system. I’m quite fond of this idea for non-vanilla installations or for new user’s to get their feet wet.

So, I will work in what little spare time I have to try and bring what is there to you. It won’t be the full scope of what v0ltr0n set out to be, at least not until I have a LOT more time to work on trying to extend the code further. It will however, among other things, bring the ability to boot lion with an unmodified kernel on many 64bit legacy intel and intel atom systems. There is no AMD support, yet, there is no magical hardware detection that will find everything for your system and make as much of it work as possible, yet, but in time we will see how it goes.

It may be a little while before I release this code. Adequate measures need to be put in place to ensure it is not stolen by *some* people who have been stealing credit and code from the rest of us and putting their own name on it for some sort of personal gain, be it a hero complex, some sort of financial gain, or just trying to make up for a lack of manhood. Meklort was quite clear (and I could not possibly agree more) that he does not want this code used without authorization and I am going to do whatever I can to ensure his wishes are carried out.

So there it is, what the future holds, but please be patient, it may be a while before I’m ready to release this. I wanted to at least clear things up so that the speculators had some real information to work with rather than wild guesses.

myHack 2.0 RC4

Posted on by

This version is now deprecated, consult the downloads page for a link to the latest version.

This version was downloaded 42431 times.

So I tracked down the cause of the FPE (Floating Point Exception), thanks to one of the people reporting the bug providing me with a kernel dump. The reason why I couldn’t reproduce the error is obvious, I am on an x86_64 kernel, the error would only occur on systems running legacy_kernel which forces i386 only operation. The cause? I was using a long integer for calculating the byte count for file transfers…

Why is this a problem on i386 systems?

64bit systems have a long integer range of −9223372036854775808 to +9223372036854775807

32bit systems only have a range of −2147483648 to +2147483647

So when the byte count reached over +2147483647 it starts subtracting and goes all the way back to −2147483648, then division by zero happens and the universe unravels.

Summary of changes from myHack 2.0 Release Candidate 3:

  • Bugfix: Resolved floating point exception on i386 systems
  • Increased resolution on file transfers that are less than 1MB to 1KB for more accurate reporting
  • Updated Chameleon to revision 1332
  • Updated Patched_10.7_AppleRTC.kext to new version see blackosx’s comment HERE for details
  • myHack now installs Chameleon modules
  • Cleaned up and further optimized code – should launch faster now
  • Removed x86_64 instructions to lighten binary further
  • Updated myHack Chameleon theme
  • Added arch=i386 kernel flag to default org.chameleon.Boot.plist

Todo:

  • Update myFix
  • Something special that will be revealed once it is ready

Make sure to read the release pages for myHack 2.0 RC1, RC2, and RC3 if you have not done so already, for a complete list of changes, contents and features.

Additional details of the myHack app’s contents will be maintained on the downloads page. Credits and further instructions will be maintained on the guide page.

Feel free to comment on this post but for support or to report a problem you encounter – please use the newly opened myHack forum instead.