|Ralph Rönnquist f3b94e01c7||1 year ago|
|README.adoc||2 years ago|
|bootstrap-dialog.sh||1 year ago|
|bootstrap-egress.sh||1 year ago|
|bootstrap-help.txt||2 years ago|
|bootstrap.sh||1 year ago|
|build-ascii-amd64-target||1 year ago|
|build-ascii-i386-target||1 year ago|
|build-beowulf-amd64-target||1 year ago|
|build-beowulf-arm64-target||1 year ago|
|build-beowulf-armhf-target||1 year ago|
|build-beowulf-i386-target||1 year ago|
|build-unstable-i386-target||2 years ago|
|clean-disk-dialog.sh||2 years ago|
|clean-disk.sh||2 years ago|
|qemu.sh||1 year ago|
This project holds some scripting that I use for making a QEMU virtual machine in which to build Devuan distribution ISOs for the VM machine architure. My host is an amd64 machine with Devuan ASCII plus some carious additions for other purposes, and it’s not a clean environment for building distribution ISOs even for amd64 distributions. But it serves well as host for ISO building VMs especially for i386 and amd64, and possibly some generic arm variants.
A command to make an ISO builder VM, and start it would be
$ ./bootstrap.sh ascii i386 $ ./qemu.sh i386 ascii-i386.img
Upon the first start, login as root:toor to run
complete the OS set up, and then finalizing the set up for
su - ralph to become the non-root user, and then go
debian-installer/build to go crazy with ISO building.
The host is set up with
+ a VDE networking solution for the QEMU VMs + a dnsmasq server for DHCP and DNS forwarding + an apt-cacher-ng for caching packages + an NFS server for a debian-installer workspace tree
The last is done so that all configurations and residue of ISO building is actually held outside of the VM image, allowing them to be 2G disk images that merely provide the target architecture build system.
The VDE networking solution includes setting up a
tap with an IP
iptables rules to provide traffic forwarding.
$ sudo ip tuntap add tap0 mode tap user ralph $ sudo iptables -t nat -A POSTROUTING -j MASQUERADE $ vde_switch -daemon
dnsmasq is quite versatile, it needs a fair number of
parameters in it’s set up:
$ sudo ip tuntap add tap0 mode tap user ralph $ sudo ip link set tap0 up $ sudo ip address add 10.10.10.1/24 dev tap0 $ sudo dnsmasq -i tap0 -a 10.10.10.1 -I lo -I wlan0 -I eth0 \ -K -D -N -b --dhcp-sequential-ip \ -F 10.10.10.2,10.10.10.254,255.255.255.0,10.10.10.255
Note: if that dnsmasq starts to compete about port 53 with some other
local DNS service, you may need to move
tap0 with the
dnsmasq as well as the
apt-cacher-ng service into a network
namespace. That might of course require virtual cabling out of the
namespace as well, since at least
need outward network access.
apt-cacher-ng set up is a bit more involved, and I’ll leave out
the details from here. In my set up it services port
The host is
nfs server, providing access to the $SHARE directory,
which for me is
/home/ralph/kvm/ISO/share on the host.
The QEMU VM is
nfs client, mounting the directory as
~ralph in the VM has a link to
which is duly set up on the host.
Note: the debian-installer workspace is managed on the host, in particular checking out the building branch appropriately. The VMs are only used for preparing the ISOs.
The VM is firstly set up with an OS of the targeted distribution by
running the host’s
debootstrap with configurations geared towards
the targeted distribution. There available
configurations are held as supporting files, such as
build-ascii-i386-target. The configuration is loaded before running
debootstrap, with the
$INCLUDE packages included in that run, and
$EXTRA packages added into a generated
in the VM image.
debootstrap run is followed by some "finalizations" to make the
VM image bootable (with
extlinux), to import the build user’s ssh
key for the VM
root user, and lastly to pass the
bootstrap-egress.sh script into a target
chroot for some further
finalization steps with that file system.
bootstrap-egress.sh steps are performed by the host kernel, but
"confined" to the target chroot.