OpenXT version 6 and later include build scripts that help you setup a build environment and build OpenXT.
The scripts use LXC Containers for the Linux bits (OpenEmbedded-based OpenXT core, Debian tools and Centos tools), and a KVM VM for the Windows tools.
It is recommended to use a recent 64 bits Debian version (Jessie / Stretch) as the host OS because:
- setup.sh depends on Apt
- 64 bits containers require a 64 bits host
- LXC is still relatively young, and earlier versions don't work that well
The setup step happens only once, as root, to install packages, create containers/VMs and more.
The build step should be run each time you need a new build.
Table of Contents:
$ apt-get install git
If you are using Ubuntu 14.04 or above, you'll also need the package `lxc-templates`.
The first build scripts exist in openxt.git (along with this README.md file), so clone that:
$ git clone git://github.com/OpenXT/openxt.git
You can of course clone your own fork. Be aware that there are another approximately 60 OpenXT repositories that will be checked out next.
Configuring the environment
Change to the
Run the following to see the list of options:
$ ./setup.sh -h
setup.sh will install the Linux containers package (lxc) and use it to create containers that will become potentially quite big (a whole build can take almost 100GB of disk space (without the WIndows VM)).
By default, lxc creates all the containers in /var/lib/lxc. If the partition for that directory is too small, the build will fail.
To change the location of the containers to, for example, /home/lxc, do the following (as root):
$ apt-get install lxc
$ echo "lxc.lxcpath = /home/lxc" > /etc/lxc/lxc.conf
Also, make sure that the lxc.lxcpath exists.
Run the following as
root or with
$ ./setup.sh [-u user] [...]
If you want your setup to include a Windows VM, use the -w options, as documented below.
setup.sh is re-entrant, you can always run it again later with the -w option if you don't want to bother with it for now.
The optional user parameter specifies the host user the build will run as, that may or may not already exist. If one is not supplied a user named
openxt will be created. If the openxt user is created, you will be prompted to set a password.
The script is re-entrant, but in the ideal case it will have to be called only once for the life of the build machine.
This will setup all the containers and configure the build environment.
The end result consists of:
- 3 new root containers named after the user and the type of container (example:
- A new directory in
/home/git named after the build user (example:
- 4 build scripts copied to the home directory of the build user (example:
- The ssh key to ssh to the containers (example:
Setting up the Windows VM
The build scripts can also be used to setup a Windows VM (using KVM), and automatically build the tools in it as part of the main build process.
To add a Windows VM to the 3 containers, provide the script with the URL of a Windows 7/10 iso using the
$ ./setup.sh -w http://inyourdreams.microsoft.com/win10x86.iso
The Windows setup process requires quite a lot of user interaction, since the scripts can't control anything that happens in Windows, at least until the Build Daemon is installed.
To setup a Windows virtual machine as part of the setup step of the build scripts, just use the -w option, followed by the URL of a Windows ISO.
setup.sh will setup Windows last. Once the script reaches that point, it tell you to VNC to it to set it up.
Here's what to do:
$ sudo apt-get install vncviewer
$ vncviewer <Windows VM>:<port> # The script should tell you what the port is
- You can use any VNC viewer, such as the one included as a Google Chrome app. Search for "VNC Viewer for Google Chrome" under Apps.
Once VNC is connected;
- Once you're in the VM, start a custom Windows install.
- It will fail to find a disk driver, so click "Load driver", and navigate to
viostor in the second CDROM, then the subfolder that corresponds to your version of Windows.
- Finish the installation. The VM won't automatically come back after the first reboot, so type "continue" and setup.sh will restart it.
- While Windows is completing the install, Windows 10 will get stuck while configuring the network. On the "Let's connect you to a network" screen, click the "Skip for now" button in the lower left corner to continue.
- Optional: once the installation is done, you can finally fix the erratic mouse by going to the control panel and disable "Enhanced Pointer Precision" under Mouse Properties, Pointer Options.
- Go to the Device Manager and update the driver of the ethernet card using "NetKVM" from the second CDROM.
- Open powershell as Administrator (right click menu item, select "Run as Administrator") and type:
- "Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Bypass", then Y [enter].
- "Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass", then Y [enter].
- "Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass", then Y [enter].
- In the start menu, type UAC [enter], and disable user access control.
- Update Windows
- Beware of the side effects of installing Windows updates. For example, the network connection may be taken down until a reboot is done after performing some updates.
- Download and install git for Windows (e.g., https://git-scm.com), open an Administrator cmd window and:
git clone https://github.com/OpenXT/openxt.git
- Optional: add "
-mirror http://<your_mirror>" if you wish to use a mirror to download the various installers
- Optional: add "
-proxy <your_proxy>" if you want the downloads to go through a proxy (only supported by Cygwin as of yet)
- Ignore messages about missing packages. These are packages that the script will install.
- Near the end of the first run, for a long time the message "Click the OK button to execute these tasks and update the configuration of this computer." will be displayed. The script it still running. Wait until the script finishes before proceeding.
- The script will install packages and stuff, and prompt you to reboot a couple of times. Re-run the script as Administrator after each reboot.
- .Net 3.5 will be installed as a dependency. This will require some user interaction.
- Towards the end:
- There is a dialog titled "Create Private Key Password". Press "None". There will then be a prompt in the command window to "Enter PFX password", just hit Enter.
- When prompted with the "Security Warning" about installing the certificate, select "Yes". NOTE: the default is "No" so be careful not to hit Enter.
- After the last reboot, the BuildDaemon should start. IMPORTANT: allow winbuildd through the firewall when asked. The BuildDaemon is what will be used for further Windows interaction.
- You can now close VNC and type "continue" in setup.sh
Running the build
Run the build script as the build user from above:
- Login as the user and go to the root of its home folder (example:
su - openxt)
- Run the following (running build.sh in a screen session is usually a good idea, it's safer and remotely accessible):
$ screen ./build.sh
When the script is finished the build is done. The build output can be found in a directory named after the date (example:
If a Windows VM was created as part of the setup,
build.sh will use it to build the Windows guest tools.
Note: if the build fails, just run
build.sh again, using the
-n option to specify the build number. For example:
./build.sh -n 160301-1
build.sh uses the external
fetch.sh script to update the git mirrors and start the git service if needed.
The build inside the containers will be done against your local git mirror. Running
git pull inside the containers will pull from the mirror, not from the OpenXT GitHub repositories.
You should run
fetch.sh manually after each reboot (to start the git service), and whenever you need the mirror updated.
Just use the build output to install OpenXT the usual way, whether using the ISO or the netboot files.
In addition to that, there will be a Debian repository and an RPM repository that can be put on a web server and used to install the tools.
- On the host:
sudo apt-get install apache2
sudo cp -r debian /var/www/html
- In a Jessie Debian VM on the guest:
echo "deb http://host/debian jessie main" >> /etc/apt/sources.list
apt-get install openxt-audio openxt-v4v openxt-vusb openxt-xenmou
Setup Step Details
The scripts have been mostly tested on a fresh install of Debian Jessie 64 bits, but other (Debian-based) configurations should work too.
In more details, the script will:
- Create the user if it doesn't exist
- Configure the user if needed by generating an ssh key pair and add him to the sudoer list
- Install packages needed to create LXC containers, a git service and more
- Create a separate LXC network for that user:
192.168.$(( 150 + UID % 100 )).0/24
Once that's done, the main setup script will then create LXC containers for the user, and use container-specific
setup.sh scripts to configure them.
3 containers will be created:
- $USER-oe: To build the core of OpenXT, based on OpenEmbedded
- $USER-debian: To build the Debian tools
- $USER-centos: To build the RPM tools
Note: In the main setup.sh, each container creation is a one-line function call that can be commented out if the user doesn't want that particular container.
A separate git mirror will also be created for the user. build.sh will fetch it each time it's called.
Note: once the user has a build environment setup, it's important that he fetches the git mirrors before trying to pull anything in the build tree, to get the most recent version of the repository.
setup.sh will finally copy build.sh to the user's home directory.
Build Step Details
A successfully setup user can run
./build.sh to start a build. That script will:
- Fetch the git mirrors
- Start a git service if needed.
- Start the containers if they're not already running, which requires root privileges and therefore will ask for the user's password to sudo.
- Use container-specific build.sh scripts to build each container
After about 5 to 8 hours, if everything went well, there will be an OpenXT build in a directory named after the current date.
Note: In the main build.sh, each container build is a one-line function call that can be commented out if the user doesn't want to build that particular container.