Re: [Bug 426497] Re: kqemu mode not compiled for karmic

2009-10-29 Thread Traumflug
Am 28.10.2009 um 18:21 schrieb Nigel Pallett: The problem occurs when I'm using virt-manager or virsh to run the Virtual Machines under kqemu. I can't help here as I use qemu without any managers. Typical strategy here is to try find out which commands these managers try to launch and

[Bug 426497] Re: kqemu mode not compiled for karmic

2009-10-27 Thread Traumflug
Shht. The kqemu packages still work great in combination with qemu built from source. -- kqemu mode not compiled for karmic https://bugs.launchpad.net/bugs/426497 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in ubuntu. --

Re: [Bug 426497] Re: kqemu mode not compiled for karmic

2009-10-27 Thread Traumflug
/usr/bin/qemu: invalid option -- '-domid' That's odd, as qemu doesn't have a feature domid. Even the unavailable options are listed with qemu -help. Are you sure to use the newly compiled qemu? which qemu will tell you. Which sources are you using? I'm using the plain sources from

[Bug 426497] Re: kqemu mode not compiled for karmic

2009-10-25 Thread Traumflug
About half of Intel's Core 2 Duo processor models shipping today do _not_ support KVM, much less lower end processors like Celeron, Atom, etc.. There are quite reasons to run qemu on such lower-spec'd machines. -- kqemu mode not compiled for karmic https://bugs.launchpad.net/bugs/426497 You

[Bug 311968] Re: DHCP very slow and unreliable

2009-10-14 Thread Traumflug
It's Intel e1000e on board of a Dell Vostro 200 (Foxconn custom MoBo). Please find dmesg output attached. The first 25 seconds are the boot process, around second 66 I attempted to get networking as described above. BTW., The hang in the boot process vanished somewhere at 9.04 beta, as network is

[Bug 311968] Re: DHCP very slow and unreliable

2009-10-13 Thread Traumflug
Well, I don't know about the Desktop CD, but I have Karmic installed on the hard disk already. In addition to the original report I have to re-add two lines to /etc/network/interfaces: auto eth0 iface eth0 inet dhcp to disable nm-applet on the ethernet card. These two lines were default at the

[Bug 311968] Re: DHCP very slow and unreliable

2009-10-13 Thread Traumflug
To get some light into the issue I've recorded the DHCP conversation done by my Mac running Mac OS X 10.4.11, and of my Ubuntu box. Please see attached files, One for the always-successful Mac, one for a failed Ubuntu try and one for a successful Ubuntu try. They are different, while the Mac

[Bug 311968] Re: DHCP very slow and unreliable

2009-10-13 Thread Traumflug
** Attachment added: Ubuntu failure.txt http://launchpadlibrarian.net/33623158/Ubuntu%20failure.txt ** Changed in: dhcp3 (Ubuntu) Status: Incomplete = Confirmed -- DHCP very slow and unreliable https://bugs.launchpad.net/bugs/311968 You received this bug notification because you are

[Bug 311968] Re: DHCP very slow and unreliable

2009-10-13 Thread Traumflug
** Attachment added: Ubuntu success.txt http://launchpadlibrarian.net/33623146/Ubuntu%20success.txt -- DHCP very slow and unreliable https://bugs.launchpad.net/bugs/311968 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dhcp3 in

[Bug 311968] Re: DHCP very slow and unreliable

2009-05-09 Thread Traumflug
Unfortunately, after the release of Jaunty, this is still an issue. Things get worse, as some applications (e.g. Firefox, Pidgin) obviously trust some hidden notification system on the unavailability of the network. I can bring up the network as described above and ping arbitrary hosts

[Bug 68037] Re: DHCP client doesn't react to link state changes

2009-04-26 Thread Traumflug
For me it looks like this is resolved in 9.04. Pulling and/or plugging the ethernet cable is almost instantly (within 2 seconds) detected by the indicator in the top Gnome menu bar. -- DHCP client doesn't react to link state changes https://bugs.launchpad.net/bugs/68037 You received this bug