How to launch an XFCE Desktop using chroot? (Using Xnest Console)

Although the virtualized OS is an ARM RC2, that should not factor into the specific problem I’m asking about here which is more generic in nature.

Host: x64 openSUSE 12.2
Guest: openSUSE ARM 12.2

Method of virtualization:
QEMU translation using the package “qemu-linux-user”
File system is a standard chroot

Display Method
Using an Xnest console

Based primarily on the openSUSE ARM on chroot HCL
https://en.opensuse.org/HCL:Chroot

Problem:
Although I have been able to launch the VM using the XFCE file system, I am able only to launch a graphical application in a blank Xnest console. When I attempt to start the xfce Desktop, I get an error that a display is already running. I suppose I might be able to specify a different display but I’d prefer to be running only one display… So I need some insight where in my process I should be specifying the xfce Desktop, eg maybe when I lauched the Xnest console is it possible to simultaneously specify the xfce desktop?
**
Specific Error**
At the very end of the steps I describe below, when I attempt to launch the xfce Desktop, I get the following two errors simultaneously.
The error is displayed two ways, both from the chroot console and the Xnet console
(Graphical)

Unable to contact settngs server
Did not receive a reply. Possible causes include the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken

(chroot console)

> startxfce4
/usr/bin/startxfce4: X server already running on display localhost:1
Xlib:  extension "RANDR" missing on display "localhost:1".

(gst-plugin-scanner:4801): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstdc1394.so': /usr/lib/gstreamer-0.10/libgstdc1394.so: undefined symbol: dc1394_iso_release_all

Following is a complete description of all steps taken installing and running the VM. It starts by using the same steps described in the HCL to the point where a CLI console works. From the point after describing how to exit, I’ve been able to launch a blank Xnest console but am unable to start XFCE.

Summary of steps
For clarity (hopefully) although I tried to always specify whether the command is entered into a Host Console or a Chroot Console, I additionally prepended a hash (#) to any commands which should run in the Host Console.

If you’re running a non-x86 OS (eg ARM, Sparc, Alpha, etc) on your x86 machine, you’ll need to install QEMU translation. This is different than running full QEMU-KVM. Once installed, you only need to run the script to enable functionality

# zypper in qemu-linux-user
# qemu-binfmt-conf.sh

Download an appropriate file system
Index of /ports/armv7hl/distribution/12.2/images
XFCE image for a graphical system openSUSE-12.2-ARM-XFCE-rootfs-*.tbz

Note: Download the following image if you don’t want an image which includes a Desktop
JeOS image for a minimal system openSUSE-12.2-ARM-JeOS-rootfs-*.tbz

On the Host machine,
Open a console and browse to your preferred location, create a root directory for your chroot as follows, copy your downloaded compressed file system described earlier to your current directory. The following tar command uncompresses the file into the chroot directory

# mkdir rootfs
# sudo tar xvjf *.tbz -C rootfs

**
Prepare the environment:**

# mount --bind /proc rootfs/proc
# mount --bind /sys rootfs/sys
# mount --bind /dev rootfs/dev
# mount --bind /dev/pts rootfs/dev/pts
# cp /etc/resolv.conf rootfs/etc/
# chroot rootfs

You’re now in your chroot and can do anything ou want. Suggest updating

# zypper ref
# zypper up

If you’re running a non-Desktop file system, these instructions should be sufficient, when you wish to exit, simply type the following in your chroot console. Note that if desired you can launch yast(curses mode).

# exit

Because this post is about the XFCE image, additional steps are required to deploy a graphical console on the local machine

From within the chroot console

export DISPLAY=:0.0

Open a console on the Host and type the following


# xhost +

You should then be able to launch a blank graphical console by typing the following in the chroot console

Xnest -ac :1

Since the existing chroot console is being used to instantiate the blank Xnest console, you will need to open a second chroot console to execute commands in the chroot

# chroot rootfs

In this second console which is now running in the chroot, type the following to send commands to the Xnest console

export DISPLAY=localhost:1

From there you can launch a GUI app, for example YAST2, eg

yast2

But, note that these steps only support launching a blank Xnest console with black background. I have been unable to launch an XFCE desktop, results in an error as I described above in this post, I have found the command to launch XFCE and tried typing the following

startxfce4

TIA,
TSU

Hi,

I practically know nothing about virualization.
But I do know that XFCE is a desktop, and that file systems are ext2, ext3, ext4, FAT, NTFS, etc.

Maybe I’m wrong in the context of virtualization (still I don’t believe so, that’s why I write).

Good luck
Mike

:slight_smile:
Seems my choice of words was unclear.
You are entirely right that XFCE is a Desktop and not a file system, in this case though I was actually referring to a pre-packaged file system which contains XFCE.

So,
As long as I’m posting in this thread I might as well also provide an update to my investigation. I have not gotten any response in this or any other forum how to launch a Desktop in Xnest, maybe it is possible and maybe not but it seems no one really knows. It’s still a good way to display a non-graphical text console and launch specific graphic applications from another Host console. In fact,

My attention then has moved towards two possible alternatives…

  1. Remote access to the VM using TCP/IP. Seems to me a heavy-handed approach to displaying on the same machine but it may be the only way. By default this seems to be how virt-manager/KVM works in any case.

  2. I have been looking at the new capabilities of displaying a console using systemd. The problem is, there is very sparse (and that’s no exaggeration) today about doing this, and although my 12.2 system reports support for agetty.service it’s hard to know if all requirements are installed and available. I might explore this instead after I upgrade to 12.3 to be assured of having a fully featured systemd. In any case, the minimal description of the systemd serial console is promising, It’s supposed to be automatic “everything” without special configuration and should support both text and graphical display by default.

TSU