search

Botspot / vdesktop

Run a second instance of Raspbian inside Raspbian.
GNU General Public License v3.0
125 stars 21 forks source link

readme

vdesktop

Vdesktop runs any RPi operating system inside any RPi operating system. (like a VM)

See it in action:
animated screen recording
This script is excellent in these situations:

To download:

git clone https://github.com/Botspot/vdesktop

To run:

sudo ~/vdesktop/vdesktop

Supported operating systems:

Vdesktop has been tested to successfully run:

Unsupported operating systems:

Vdesktop does not appear to run:

After running once, vdesktop will create a file in /usr/bin. So from now on you can simply run vdesktop. (with no sudo)

Usage:

Boot a .img file: vdesktop /home/pi/2020-08-20-raspios-buster-armhf.img
Boot a usb drive: vdesktop /dev/sda
Boot a directory: vdesktop /home/pi/raspbian-stretch/
A second word specifies the boot mode: cli, or gui. If none specified, gui mode is assumed.

Variable & env file usage:

This new version of vdesktop allows many options to be customized.
For example, you can prevent vdesktop from logging in automatically to the guest.

VDESKTOP_AUTO_LOGIN=no vdesktop /dev/sdc

In the above example, the VDESKTOP_AUTO_LOGIN value will not be preserved for the next command you run in the terminal. If you want such a behavior, do something like this:

export VDESKTOP_AUTO_LOGIN=no
vdesktop /dev/sdc

To change a setting permanently, go edit the settings.env file.

BOOT_MODE=gui
UMOUNT_ON_EXIT=yes
USERNAME=pi
PASSWORD=raspberry
MOUNTPOINT=/media/pi/vdesktop
ENABLE_ROOTMOUNT=yes
#ENABLE_VIRGL=no
#LOCAL_BINARIES=yes
NSPAWN_FLAGS=''
#AUTO_LOGIN=yes

Did you notice anything different? None of these variables are prefixed with VDESKTOP_. Why not? Well, this allows there to be two variable sets, one of which overrides the other.
If the env file contains BOOT_MODE=cli, but on the terminal you set VDESKTOP_BOOT_MODE=gui, which one should vdesktop obey? Turns out the "VDESKTOP_"-prefixed variable will take priority.

Variable explanation:

How does it work?

Vdesktop uses a systemd-nspawn container to 'boot' its devices with. This is very similar to a chroot.
Systemd-nspawn is much faster than other methods because it doesn't use any emulation. Why would you need emulation anyway, when you want a Pi to run its own OS?
Try out systemd-nspawn yourself:

sudo systemd-nspawn -bD /media/pi/USB-DRIVE

(Where /media/pi/USB-DRIVE is the path to an externally connected usb device with Raspberry Pi OS flashed to it.)
With that command, you'll see the SD card boot up. After manually logging in yourself, you can change settings, run updates, etc, as long as it can be done in the command-line.

What about an image file?

This is harder to do, since it involves mounting the img first, but here you go:

sudo -i
LOOP="$(losetup -fP --show /path/to/your-raspbian.img)"
mount -o rw "${LOOP}p2" /media/pi/vdesktop
mount -o rw "${LOOP}p1" /media/pi/vdesktop/boot
systemd-nspawn -bD /media/pi/vdesktop
umount -fl /media/pi/vdesktop/boot
umount -fl /media/pi/vdesktop
losetup -d "$LOOP"

What if you want graphics?

This is even harder. Launch Xephyr from a host's terminal, then connect to it from within the guest.

From a terminal running on the host system:

Xephyr :1

A black window will appear. Assuming you've already ran the necessary systemd-nspawn command and logged in as user pi, to make the container/guest system connect to the Xephyr window, run this in the guest's console:

export DISPLAY=:1
/usr/bin/startlxde-pi

If the graphics look bad, you will have to restart certain services. From within the guest's console:

eval "pcmanfm --desktop --profile LXDE-pi; sleep 20; pcmanfm --desktop --profile LXDE-pi" &
lxpanelctl restart
sleep 10
lxpanelctl restart

What if you want everything to work automatically, without requiring any user interaction?

This is too long to post here. After all, it takes the entire vdesktop script to do this. Here's what it does:

Directory Tree:

To do: