Jump to content
10 posts in this topic

Recommended Posts

No matter what options I select during the installation on my system (including the defaults with no drivers enabled), the installation crashes either during or just after the "payload verification" stage, with a kernel panic similar to the attached screen. It looks like a disk problem (IOATA), and I am trying to install to a partition on a SATA disk. I should also mention that I see "unable to mount partition" messages with the -v flag during the installation boot from the DVD.

 

The BIOS is old (2007) and somewhat limited, but unless someone knows of an "unpublished" BIOS or mod for an ECS MCP61-PM AM motherboard (from a Gateway system ... what a nightmare they have been. never again ... ) I'm not sure what to do about that.

post-118805-1255395564_thumb.jpg

Thanks for the tip. The following boot line got me through the install:

-v -f maxmem=2048 debug=0x100

I selected drivers that corresponded to my hardware, installed, and tried to reboot. Chameleon v2 was installed by default as the default loader, and it came up and recognized all my partitions. I chose the new osx86 install (which was the default) and the machine rebooted. I tried a few more things, including the same command string above that got it through the install, but nothing worked. So I gave up and tried to boot into my Vista partition, but its loader was hosed; ditto for an XP partition.

 

After two hours of playing with the Vista install disc, bcdedit, and other crappy Windows boot tools, I finally got Vista working again ... only after completely disabling every other disk in the machine except the one with Vista on it. Only then could I repair Vista's MBR.

 

At any rate, the OSX install seemed to work, so it would be great to be able to use it if possible. I saved the install log and attached it here.

 

I don't see a system log to check for crash info (in /private/var/log/ unless it's somewhere else).

Installer_Log_13_Oct_2009.txt

Usually, then you have an instant reboot on system boot-up, it is the wrong kernel chosen. You have to boot with voodoo kernel. So use this options to boot (I hope you have the voodoo kernel installed)

voodoo -v -f maxmem=2048 debug=0x100

Note: voodoo may be named voodoo970 or voodoo950

Usually, then you have an instant reboot on system boot-up, it is the wrong kernel chosen. You have to boot with voodoo kernel. So use this options to boot (I hope you have the voodoo kernel installed)
voodoo -v -f maxmem=2048 debug=0x100

Note: voodoo may be named voodoo970 or voodoo950

Thanks. That was part of the problem: I had forgotten that I had selected minimal options in the last install while trying to troubleshoot the problem.

 

I have reinstalled to include Voodoo kernel 9.7.0 and the drivers that correspond to my hardware. Incidentally, if I include 'voodoo' at the beginning of the boot flags, I get kicked right back to the same boot flag entry screen. But it boots fine if I just enter:

-v -f maxmem=2048 debug=0x100

 

The display seems to be working fine, that's about it. No audio (onboard Realtek 888), no Ethernet (onboard Marvell Yukon 88E8039), no Firewire, etc. But at least its booting this far. Thanks.

try typing voodoo970.
Yup, tried that, but got the same kick-back to boot flag screen.

 

And now when I try to boot, it seems to go okay for a while, and then I get a black screen, which looks like a window server problem. Found this in windowserver.log:

Oct 14 18:10:11  [201] Server is starting up
Oct 14 18:11:11  [201] (iokit/common) I/O Timeout: IOKitWaitQuiet
Oct 14 18:11:11  [201] (iokit/common) I/O Timeout: Set a breakpoint at CGErrorBreakpoint() to catch errors as they are returned
Oct 14 18:11:13  [201] CGXMappedDisplayStart: Unit 0: no display alias property
Oct 14 18:11:13  [201] CGXMappedDisplayStart: Unit 1: no display alias property

About the kernel. Well do you really have voodoo kernel installed? If you can boot with no kernel_name flag, can probably mean that the default kernel is voodoo. So no need to type its name on boot up.
Yes, I believe so: I chose the Voodoo 9.7.0 kernel as an install option, and 'uname -a' showed a Voodoo based kernel. So having that as the default kernel is fine. But the windowserver problem is not. ;)

The good news is that after wiping the disk and reinstalling from scratch (again), that problem is gone. Now I get another error when I boot instead:

Interfacenamer: timed out waiting for IOKit to quiesce

After that the screen goes blank for a while, and then the monitor loses signal entirely.

 

I can't seem to find much in the way of a fix for this one.

×
×
  • Create New...