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 an
> /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
w
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.
--
Ubu
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 recei
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
** 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 ubun
** 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 ar
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 sends
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 t
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 successfully
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 noti
I can confirm this. Pulling the ethernet cable plug doesn't make the
interface disappear for at least a minute, either.
The script I used for verification:
while true; do sleep 2; ifconfig eth0 | grep "inet Adresse"; done
- - -
m...@piccard:~$ lsb_release -rd
Description: Ubuntu 8.10
Release:
** Attachment added: "dhcpdump.txt"
http://launchpadlibrarian.net/20781255/dhcpdump.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 ubuntu.
--
Ubunt
Public bug reported:
What I expect to happen:
When booting Ubuntu, I expect the computer to get a DHCP lease and to
have networking available as soon as Gnome starts up.
What happens instead:
1 - The boot hangs at the boot splash screen for some 20 to 30 seconds
(already reported as https://bug
14 matches
Mail list logo
