PW 2.2 with Ubuntu 6.10 (Edgy) host -- almost there!

H

hkoster1

Member
PW 2.2 with Ubuntu 6.10 (Edgy) host -- almost there! [SOLVED]

I'm trying to get PW 2.2 going on the 32-bit version of Ubuntu Edgy on a 64-bit computer -- currently with the latest update on PW 2.2. This is what I did:

1. Make sure to unload the old vm-main and hypervisor kernel modules from before the PW 2.2 update (just in case they're still there).

2. Attend to the dash vs. bash issue... I changed /bin/sh to /bin/bash in /usr/bin/parallels-config, /usr/bin/parallels, and all scripts in /usr/lib/parallels/autostart. I may have missed a few...

3. Run "sudo parallels-config" --> everything compiled OK and modules loaded OK (there are four now: vm-main, hypervisor, virtualnic and vm-bridge).

4. Started Parallels with the command (in a terminal, as user) "parallels &". This seemed to start OK, but output to the terminal was
X Error: BadDevice, invalid or uninitialized input device 169
Major opcode: 147
Minor opcode: 3
Resource id: 0x0
Failed to open device
X Error: BadDevice, invalid or uninitialized input device 169
Major opcode: 147
Minor opcode: 3
Resource id: 0x0
Failed to open device
Click to expand...
as before. Ignoring this, I configured a Linux 2.6 VM, then popped in a Knoppix liveCD. Booting started OK, then failed at the hardware autodetection stage. A similar thing happened when I booted the Mepis liveCD. Finally, I tried the Ubuntu Edgy liveCD, it also hung (but the reason why was hidden behind the splash screen); I tried Ctl-Alt-Del (why I don't know) and booting resumed and gave me the familiar Gnome desktop.

Before installing anything in this VM, I would like to clear up why Knoppix failed to autodetect the VM hardware -- I consider its method among the best in Linuxland. Would it be related to the above terminal messages, I wonder?

Any thoughts would be appreciated.
 
Last edited:
David Corrales said:
Currently, Parallels is not compatible with 64bit host operating systems.
Click to expand...

Oh please, my post says clearly that I'm running a 32-bit OS, don't confuse the OS with the hardware...

Refer also to the PW 2.2 User Guide, page 12, Hardware requirements for host OS: OK to have a 64-bit computer as long as the OS is 32-bit.
 
That darned dash vs. bash issue... [SOLVED]

hkoster1 said:
2. Attend to the dash vs. bash issue... I changed /bin/sh to /bin/bash in /usr/bin/parallels-config, /usr/bin/parallels, and all scripts in /usr/lib/parallels/autostart. I may have missed a few...
Click to expand...

Indeed, missed a few... Changed the following instances in /usr/lib/parallels:
autostart/drivers_stop:#! /bin/bash
autostart/iscripts:#!/bin/bash
autostart/drivers_start:#!/bin/bash
autostart/parallels:#!/bin/bash
autostart/parallels: /bin/bash $script_dir/drivers_start
autostart/parallels: /bin/bash $script_dir/drivers_stop
config.guess:#!/bin/bash
config.sub:#!/bin/bash
gettext.sh:#!/bin/bash
ltmain.sh: if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/bash ||
tools/mimelink:#!/bin/bash
tools/network.sh:#!/bin/bash
Click to expand...
That did the trick, PW 2.2 compiling and running fine now on Ubuntu 6.10 (Edgy), 32-bit version (of course).
 
I intend to use a VM to try various other OS'es, and started with Debian Etch (kernel 2.6.17-k7). I configured a Linux-2.6 VM with 1024MB of memory (a little less than the maximum recommended amount of 1136MB). The installation went OK (needed to deactivate PCMCIA checking), but on reboot some problems appeared:

1. sometimes an AGP-related kernel bug stops the boot process cold;

2. at other times booting recovers from the AGP-bug, only to stop cold during configuring CUPSD; and

3. else none of these problems appear, and the boot proceeds cleanly.

Once it boots cleanly, it is also more likely to reboot cleanly.

I found some references stating that upping the memory to the recommended maximum solves the AGP bug, but that's not how it works in my case: lowering or increasing the memory (but never more than recommended maximum) makes no difference: either (1), (2) or (3) above occurs. Usually, the boot succeeds after a couple of tries, sometimes at the first try, but it may on occasion also be the fourth or fifth try.

Is this a defect in the Parallels VM? Or in my AMD-64 motherboard? Or a real kernel bug? Or anything not yet mentioned? Any thoughts appreciated!
 
You must log in or register to reply here.
Back
Top