24.11.2010 23:15, Hugo Mills wrote:
[]
>>> When starting a VM with SDL video output, I end up with a black
>>> screen containing a (blinking) text-mode cursor in the top left
>>> corner. The kvm process dies immediately. It is impossible to
>>> console-switch to a text VT (Ctrl-Alt-F1), or indeed do anything at
>>> all from the main display. Using VNC video output for the guest works
>>> OK.
>>
>> Please don't run kvm as root without $DISPLAY set and without specifing
>> VNC output. This is the only way to let libSDL to open framebuffer
>> console on the same VT as your X is running, and thus ruin X -- only
>> when running as root it has necessary permissions to do that.
>
> h...@ruthven:~ $ sudo bash -c 'echo $DISPLAY'
> :0.0
>
> $DISPLAY _is_ set.
>
> This has always worked before now -- it's only a recent change
> (last couple of months, I think).
Please try to run, say, xterm there instead of bash or kvm. sudo is
what breaks the thing, I've seen many cases like this before in #kvm
IRC channel.
If that changed recently, it should be the change in sudo, who stopped
exporting XAUTHORITY data, or something like this.
The wording there wasn't exactly correct (but the retitle was right).
$DISPLAY may be set, the key thing here is that it's inaccessible.
>> This is on the same theme as complaining that `rm -rf /' destroys your
>> system - yes it does when run as root, don't do that. I understand this
>> is not right comparison - rm is designed to remove files, while kvm is
>> not designed to ruin X session.
>
> I'll settle for some way of starting a qemu/kvm session as an
> ordinary user that will let me set up bridged networking for the
> resulting VM. That way, I won't need to run as root...
This actually very simple, if you run just a handful of guests not more.
This bugreport isn't the best place but I'll give some hints anyway.
You pre-create a few tap devices, say tap-kvm1 and tap-kvm2, in
/etc/network/interfaces or /etc/rc.local, using `ip tuntap' command,
like this:
ip tuntap add dev tap-kvm1 mode tap group kvm1group
ip link set tap-kvm1 up
brctl addif br0 tap-kvm1 # whatever bridge you want it on
There, kvm1group is some group defined in /etc/group - this group
will be able to use that tap device. Or you can use some user
there instead of group.
Now, add your user(s) to:
a) kvm group for /dev/kvm access,
b) tun group for /dev/net/tun access
(you may add udev rule and the group itself) -
this is all users allowed to mess with some tun/tap
devices in general
c) the tun1group, to access to this particular tap device.
If you choose to grant access to a user, this step is
not needed obviously.
And after all this, you just run kvm normally but specify
a pre-configured tap device for its -net argument, and request
it to not run any ifup/ifdown scripts (or edit /etc/kvm/kvm-ifup):
kvm ... -netdev type=tap,ifname=tap-kvm1,script=no,id=n1 \
-device virtio-net-pci,netdev=n1 \
...
Or something like this.
> Possibly also something that detects that SDL is going to do Bad
> Things and warns you about it?
In theory it should be able to run on vga console too, but I don't
know if anyone ever tested that (SDL is designed to work there).
Strictly speaking I'd say it's SDL bug - it is SDL who fights with
X for the vt.
>> I'm retitling this bug to reflect actual situation more closely, and
>> downgrading it to a wishlist, so that the information will be easy to
>> find. Maybe we can actually do something with this someday.
>
> At least it'll help others who have the same issue.
That's exactly why I keep it.
Thanks!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
