Bootloader issues? MB v5.2.0

[Tagny Daggart]

Hi all,

I've been enjoying a slick Hack since July without much of an issue. However, today, I "upgraded" my bootloader using the new MB 5.2.0. Ever since doing so, I can only boot via Safe Mode. When I try to boot normally (actually with the boot flag -v), it seems to run complete through the paces just fine, but the machine just stops when it gets to the point of turning on the GUI for some reason. I know the machine hasn't frozen completely, the verbose trace changes when I disconnect/reconnect my MagicMouse just fine. (EDIT: web services are NOT working as previously thought)

See my profile for my machine details, but the highlights are: i7-3770K, GA-Z77-UD5H, using the IGA HD4000.

After spending a whole day troubleshooting, I decided to create a new, bootable partition with a fresh copy of ML.

I used Unibeast 1.5.3 and my copy of ML from the App Store onto another partition of my normal SSD. This partition is called 'Installer'.

I was able to boot into the Unibeast-installed 'Installer' partition just fine without any boot flags and I ran the ML Installation against a 3rd partition on the same drive: 'Mountain Lion'. This appeared to go very smoothly (and quickly since everything is on an SSD). Unfortunately, again, I cannot boot into the fresh partition unless I use Safe Mode.

Since all 3 drives are on the same physical disk, and hence use the same boot-loader, I must surmise that Chimera is the issue.

I then tried downgrading to Chimera 1.11.1, but nothing has changed.

Anyone ever face something like this before?

EDIT: I've now just installed ML to a new partition located on another physical disc that never had a bootloader installed (of course, it does now). I have the exact same issue. I cannot boot the fresh ML install except in safe mode.

Surely this must be something specific to my rig, right? Otherwise, these forums would be packed to the hilt with this issue.

 

[neilhart]

So when you run Unibeast installer, the /Extra/org.chameleon.Boot.plist file that the Unibeast Installer uses to boot contains the "PCIRootUID=1" argument. Some systems are very sensitive to this and some just don't care. When you reboot using the USB stick to get into your new installation so that you can run Mulitibeast, the argument is used again. If you run either EasyBeast or UserBeast this argument is not written to your /Extra/org.chameleion.Boot.plist. If it is needed you will have to add it.

You test if it is needed by pausing the boot and manually entering the argument to see if this is your problem.

good luck
neil

 

[Asus-Freak]

Had the same problem on both a Asus and Gigabyte box. Didn't have time to troubleshoot so I just ran 5.1.3 to recover and chase the issue later. Quite often, fixing something that's not broke is painful...

 

[Tagny Daggart]

Hi Neil, thanks for the suggestion. I've tried adding the boot flags "PCIRootUID=1" and "PCIRootUID=0" and in neither case was there any difference. =/

 

[Tagny Daggart]

Tried downgrading to MB 5.1.3 and selected all the options I normally require. Machine still is not booting without the '-x' boot flag. I wonder what has changed? And to think that I can't even get a fresh install on a fresh partition to boot makes me really puzzled.

 

[neilhart]

If you can boot using the USB installer? Then you can rip the installer and put the /Extra from the installer onto your target partition. All you need is to use "ShowAllFiles.app so that you can see the contents of the USB installer. Examine the installer's /Extra and it's contents. There is really no reason not to put that onto your partition. I would clone the partition with SuperDuper!. Then you can start removing things until you find the key items required to boot.

neil

 

[Tagny Daggart]

Hey guys, thanks for the help.

Its a new day and having gotten some sleep, I approached this more methodically. I'm not precisely sure what broke or why, but I suspect that somewhere along the line, one of my Extensions had gotten corrupt but I didn't notice because I had a good boot cache. Then, once I started installing the new boot loader, etc. I ignored the boot cache and started booting from a now corrupt extension. This is just a theory, but its how I can make sense out of what has happened. I'm not entirely sure why I struggled with the new install on a fresh partition though =/

To repair this on my primary boot volume, I compared extensions with the fresh install. There were a couple that were not found in my fresh install, namely: RemoteVirtualInterface.kext and TrustedDataSCSIDriver.kext. I don't know what the first one does, but I know the second one was installed by my Drobo desktop software. I nuked them both, then copied over the remaining kexts from the fresh install, then used KextWizard to repair permissions and rebuild the boot cache, etc. and I was back in business!

Whew!

Thanks again for your help!