Qemu and other emulators: what changed

Revision 2 to 3. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		This note covers setting up Qemu on an x86-based development system running Linux. This allows native (rather than cross) development tools to be run, which can be useful:
2	2
3	3		- where the target system has performance/resource issues (e.g. some ARM systems)
4	4		- is not run natively due to company policy (older versions of Microsoft Windows)
5	5		- is quite simply unavailable at a reasonable price (e.g. SGI MIPS systems or the Chinese MIPS-based systems).
6	6
7	7		It also briefly mentions User Mode Linux for x86 and the Hercules emulator for IBM zSeries mainframes despite the fact that these are not particularly relevant to Free Pascal, and Docker containerisation. It does not consider x86-on-x86 virtualisation systems such as VMware, Microsoft Hyper-V or Oracle VirtualBox, and only considers Linux KVM as a foundation technology for Qemu.
8	8
9	9		## The Host System
10	10
11	11		In the current case, the host is a Compaq rack-mount server running at around 3GHz with several Gb RAM; be warned that performance will drop off drastically with a lower specification system. It has two internal drive cages, the first is connected to a RAID controller and is used for the host operating system and tools, the second is connected to a SCSI controller and contains 6x discs each of which is used for a different guest system.
12	12
13	13		The host IP address is 192.168.1.22 and the system is named pye-dev-07, the default gateway and name server are on 192.168.1.1. Guest systems are on the 192.168.22.x subnet and are named pye-dev-07a (192.168.22.16), pye-dev-07b (192.168.22.17) and so on, they have their own gateway 192.168.22.1 which is known to the site router and firewalls.
14	14
15	15		The host operating system is Debian "Squeeze", the host normally runs headless and may be accessed by SSH, X using XDMCP, or VNC. The display manager is gdm since this has a better XDMCP implementation than the alternatives, however in practice graphical login is most often handled by VNC.
16	16
17	17		The following guests are implemented:
18	18
19	19		pye-dev-07a
20	20		Debian on ARM (little-endian, armel) using Qemu
21	21
22	22		pye-dev-07b
23	23		Debian on MIPS (little-endian, mipsel) using Qemu
24	24
25	25		pye-dev-07c
26	26		Slackware x86 13.37 using Qemu
27	27
28	28		pye-dev-07d
29	29		Slackware x86 13.37 using User Mode Linux
30	30
31	31		pye-dev-07e
32	32		Windows 2K using Qemu
33	33
34	34		pye-dev-07f
35	35		Debian on zSeries using the Hercules emulator
36	36
37	37		pye-dev-07g
38	38		Debian on 68k using the Aranym emulator
39	39
40	40		Originally, pye-dev-07a was earmarked for big-endian ARM, but this appears to be being phased out by Debian so is probably no longer a viable target. Anybody planning to port FPC to the AVR-based Arduino?
41	41
42	42		In general, multiple guests can run simultaneously although this has not been exhaustively tested recently.
43	43
44	44		In the case of Linux the guest systems are each installed on an 18Gb disc, in the case of Windows a 36Gb disc is used. Each disc is assigned a label using e2label (arm, armel and so on), so that the startup script can mount it by name irrespective of which drive cage slot it's in.
45	45
46	46		## Debian Guest using Qemu
47	47
48	48		Select a suitable Debian mirror and version, for example
49	49
50		-	~~` `[`http://ftp.de.debian.org/debian/dists/squeeze/main/`](http://ftp.de.debian.org/debian/dists/squeeze/main/)`...`~~
	50	+	```text
	51	+	http://ftp.de.debian.org/debian/dists/squeeze/main/...
	52	+	```
51	53
52	54		Fetch a kernel and initrd image for Debian Squeeze, as below.
53	55
54	56		For ARM (little-endian):
55	57
56		-	~~` .../main/installer-armel/current/images/versatile/netboot/vmlinux-2.6.32-5-versatile`\~~
57		-	~~` .../main/installer-armel/current/images/versatile/netboot/initrd.gz`~~
	58	+	```text
	59	+	.../main/installer-armel/current/images/versatile/netboot/vmlinux-2.6.32-5-versatile
	60	+	.../main/installer-armel/current/images/versatile/netboot/initrd.gz
	61	+	```
58	62
59	63		In addition for this architecture you also need:
60	64
61		-	~~` `[`http://people.debian.org/~aurel32/qemu/armel/initrd.img-2.6.32-5-versatile`](http://people.debian.org/~aurel32/qemu/armel/initrd.img-2.6.32-5-versatile)~~
	65	+	```text
	66	+	http://people.debian.org/~aurel32/qemu/armel/initrd.img-2.6.32-5-versatile
	67	+	```
62	68
63	69		For MIPS (little-endian):
64	70
65		-	~~`.../main/installer-mipsel/current/images/malta/netboot/vmlinux-2.6.32-5-4kc-malta`\~~
66		-	~~`.../main/installer-mipsel/current/images/malta/netboot/initrd.gz`~~
	71	+	```text
	72	+	.../main/installer-mipsel/current/images/malta/netboot/vmlinux-2.6.32-5-4kc-malta
	73	+	.../main/installer-mipsel/current/images/malta/netboot/initrd.gz
	74	+	```
67	75
68	76		Copy these to the disc reserved for the guest, e.g. /export/mipsel.
69	77
70	78		Create a filesystem for Qemu, e.g.:
71	79
72	80		``` bash
73	81		# qemu-img create -f qcow mipsel_hda.img 16G
74	82		```
75	83
76	84		Expect that to round up to around 17.1 Gb, if it doesn't then experiment. Start Qemu, telling it what kernel, initrd and filesystem to use:
77	85
78	86		For ARM (little-endian):
79	87
80	88		``` bash
81	89		# qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.gz \
82	90		-hda armel_hda.img -append root=/dev/ram
83	91		```
84	92
85	93		Note that the above command requires X access, e.g. ssh with the -X option.
86	94
87	95		For MIPS (little-endian):
88	96
89	97		``` bash
90	98		# qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta -initrd initrd.gz \
91	99		-hda mipsel_hda.img -append "root=/dev/ram console=ttyS0" -nographic
92	100		```
93	101
94	102		Install the guest operating system as usual, splitting the disc into 16.5Gb for / with the remainder (around 700Mb) as swap. This will be slow, 8 or 9 hours is not implausible, so make sure that nobody's about to turn off your mains or disconnect you from the Internet.
95	103
96	104		Don't worry if it tells you it's not installing a loader- it's not needed since the kernel and initrd are loaded into memory by the host.
97	105
98	106		Boot the operating system and set network addresses etc. Use 192.168.22.16 or similar, with a gateway of 192.168.22.1.
99	107
100	108		For ARM (little-endian):
101	109
102	110		``` bash
103	111		# qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile \
104	112		-initrd initrd.img-2.6.32-5-versatile -hda armel_hda.img -append "root=/dev/sda1"
105	113		```
106	114
107	115		For MIPS (little-endian):
108	116
109	117		``` bash
110	118		# qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta \
111	119		-hda mipsel_hda.img -append "root=/dev/sda1 console=ttyS0" -nographic
112	120		```
113	121
114	122		Finally, you should be able to boot the operating system with an operational network. This relies on having /etc/qemu-ifup and /etc/qemu-ifdown files (see below), and passes additional parameters to them in shell variables. In outline:
115	123
116	124		For ARM (little-endian):
117	125
118	126		``` bash
119	127		# qemu-system-arm -M versatilepb -m 256 -hda armel_hda.img \
120	128		-kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile \
121	129		-append 'root=/dev/sda1 text' \
122	130		-net nic,macaddr=00:16:3e:00:00:01 -net tap,ifname=tun1
123	131		```
124	132
125	133		For MIPS (little-endian):
126	134
127	135		``` bash
128	136		# qemu-system-mipsel -M malta -m 256 -hda mipsel_hda.img \
129	137		-kernel vmlinux-2.6.32-5-4kc-malta -no-reboot \
130	138		-append 'root=/dev/sda1 console=ttyS0' -nographic \
131	139		-net nic,macaddr=00:16:3e:00:00:02 -net tap,ifname=tun2
132	140		```
133	141
134	142		Remember that if you change the network interface type or MAC address you will probably need to delete entries from the guest's /etc/udev/rules.d/z??_persistent-net.rules file.
135	143
136	144		## Windows 2K Guest using Qemu
137	145
138	146		Use dd to save a .iso image of the installation CD. Create a filesystem image:
139	147
140	148		``` bash
141	149		# qemu-img create -f qcow2 win2k.img 32G
142	150		```
143	151
144	152		Boot using startup script as below. Note that this must specify a non-default network card, since Qemu's current (as of 2011) default is not supported by Windows 2K.
145	153
146	154		TODO: run with kernel support module.
147	155
148	156		## KVM on a Linux host
149	157
150	158		KVM (Kernel-based Virtual Machine) is an enabling API supported on more recent x86 and x86-64 (AMD64) systems, this replaces the older KQemu kernel module which is now deprecated by both Qemu and the kernel.
151	159
152	160		KVM is typically enabled by the host system BIOS. If not enabled by the BIOS it cannot be enabled by the kernel or by (a suitably privileged) application program, since the x86 architecture requires power to be cycled to change the state of this facility. The result of this is that KVM might be unavailable (no /dev/kvm device) even if it shown as supported by the CPU flags in /proc/cpuinfo.
153	161
154	162		## Common Qemu startup, ifup and ifdown scripts
155	163
156	164		There is much commonality irrespective of whether the guest is running Linux or Windows.
157	165
158	166		First startup script (e.g. /export/C):
159	167
160	168		``` bash
161	169		#!/bin/sh
162	170
163	171		mount -L mipsel
164	172		cd /export/mipsel
165	173		. ./C-2
166	174		```
167	175
168	176		Second startup script for ARM (little-endian):
169	177
170	178		``` bash
171	179		#!/bin/sh
172	180
173	181		# Routine startup of a Qemu guest relies on (the host) running /etc/qemu-ifup
174	182		# to condition ARP, forwarding etc.
175	183
176	184		QEMU_ID=1
177	185		QEMU='qemu-system-arm -M versatilepb'
178	186		QEMU_RAM='-m 256'
179	187		QEMU_HD='-hda armel_hda.img'
180	188		QEMU_CD=''
181	189		QEMU_BOOT="-kernel vmlinuz-2.6.32-5-versatile -append 'root=/dev/sda1 text' -initrd initrd.img-2.6.32-5-versatile"
182	190		# QEMU_MONITOR='-monitor stdio -nographic'
183	191		# QEMU_MONITOR='-nographic'
184	192		QEMU_VGA=''
185	193		VNC_ID=$(($QEMU_ID+1))
186	194		# QEMU_VNC="-vnc :$VNC_ID -k en-gb"
187	195		QEMU_VNC=''
188	196		QEMU_NET="-net nic,macaddr=00:16:3e:00:00:0$QEMU_ID -net tap,ifname=tun$QEMU_ID"
189	197		QEMU_GUEST_IP_ADDRESS=192.168.22.17
190	198		QEMU_GUEST_IP_GATEWAY=192.168.22.1
191	199		QEMU_HOST_GATEWAY_IF=eth1
192	200		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY_IF
193	201
194	202		echo * $QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
195	203		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
196	204
197	205		screen -S QEMU_$QEMU_ID \
198	206		sh -c "$QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
199	207		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC"
200	208
201	209		cd ..
202	210		```
203	211
204	212		Second startup script for MIPS (little-endian):
205	213
206	214		``` bash
207	215		#!/bin/sh
208	216
209	217		# Routine startup of a Qemu guest relies on (the host) running /etc/qemu-ifup
210	218		# to condition ARP, forwarding etc.
211	219
212	220		QEMU_ID=2
213	221		QEMU='qemu-system-mipsel -M malta'
214	222		QEMU_RAM='-m 256'
215	223		QEMU_HD='-hda mipsel_hda.img'
216	224		QEMU_CD=''
217	225		QEMU_BOOT="-kernel vmlinux-2.6.32-5-4kc-malta -append 'root=/dev/sda1 console=ttyS0' -no-reboot"
218	226		# QEMU_MONITOR='-monitor stdio -nographic'
219	227		QEMU_MONITOR='-nographic'
220	228		QEMU_VGA=''
221	229		VNC_ID=$(($QEMU_ID+1))
222	230		# QEMU_VNC="-vnc :$VNC_ID -k en-gb"
223	231		QEMU_VNC=''
224	232		QEMU_NET="-net nic,macaddr=00:16:3e:00:00:0$QEMU_ID -net tap,ifname=tun$QEMU_ID"
225	233		QEMU_GUEST_IP_ADDRESS=192.168.22.18
226	234		QEMU_GUEST_IP_GATEWAY=192.168.22.1
227	235		QEMU_HOST_GATEWAY_IF=eth1
228	236		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY_IF
229	237
230	238		echo * $QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
231	239		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
232	240
233	241		screen -S QEMU_$QEMU_ID \
234	242		sh -c "$QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
235	243		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC"
236	244
237	245		cd ..
238	246		```
239	247
240	248		Second startup script for Windows:
241	249
242	250		``` bash
243	251		#!/bin/sh
244	252
245	253		# Routine startup of a Qemu guest relies on (the host) running /etc/qemu-ifup
246	254		# to condition ARP, forwarding etc.
247	255
248	256		QEMU_ID=4
249	257		QEMU=qemu
250	258		QEMU_RAM='-m 256'
251	259		QEMU_HD='-hda win2k.img'
252	260		QEMU_CD='-cdrom Windows2k-SP4.iso'
253	261		QEMU_BOOT='-boot c'
254	262		QEMU_MONITOR='-monitor stdio'
255	263		QEMU_VGA='-vga cirrus'
256	264		VNC_ID=$(($QEMU_ID+1))
257	265		QEMU_VNC="-vnc :$VNC_ID -k en-gb"
258	266		QEMU_NET="-net nic,macaddr=00:16:3e:00:00:0$QEMU_ID,model=rtl8139 -net tap,ifname=tun$QEMU_ID"
259	267		QEMU_GUEST_IP_ADDRESS=192.168.22.20
260	268		QEMU_GUEST_IP_GATEWAY=192.168.22.1
261	269		QEMU_HOST_GATEWAY_IF=eth1
262	270		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY_IF
263	271
264	272		echo * $QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
265	273		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
266	274
267	275		screen -S QEMU_$QEMU_ID \
268	276		$QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
269	277		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
270	278
271	279		cd ..
272	280		```
273	281
274	282		/etc/qemu-ifup (for both Linux and Windows):
275	283
276	284		``` bash
277	285		#!/bin/bash
278	286
279	287		# if-up file for qemu, heavily cribbed from the command sequence embedded in
280	288		# User Mode Linux. MarkMLl.
281	289
282	290		echo Running /etc/qemu-ifup $1 $2...
283	291
284	292		# For compatibility with UML the only parameter here is $1 which is the
285	293		# interface name. I've put in a reference to $2 so we can see it if anything
286	294		# changes.
287	295
288	296		# I'm going to assume that qemu is always run by root. This is fairly
289	297		# reasonable since it allows guest OSes to be fired up which themselves might
290	298		# give access to confidential data etc. if compromised.
291	299
292	300		# Here's my equivalent to the host-side UML setup for Qemu. We're hamstrung
293	301		# here by the fact that the emulator is not telling us what IP address it's
294	302		# trying to enable, there isn't a 1:1 correspondence between IP addresses and
295	303		# interfaces since the latter depends on the order the sessions are started.
296	304		#
297	305		# As a hack, assume that the caller exports QEMU_GUEST_IP_ADDRESS (e.g.
298	306		# 192.168.17.16), QEMU_GUEST_IP_GATEWAY (e.g. 192.168.17.1) and
299	307		# QEMU_HOST_GATEWAY_IF (e.g. eth0).
300	308
301	309		echo * modprobe tun
302	310		modprobe tun
303	311
304	312		echo * ifconfig $1 $QEMU_GUEST_IP_GATEWAY netmask 255.255.255.255 up
305	313		ifconfig $1 $QEMU_GUEST_IP_GATEWAY netmask 255.255.255.255 up
306	314
307	315		X=`cat /proc/sys/net/ipv4/ip_forward`
308	316		if [ "$X" == "0" ]; then
309	317
310	318		# Use either this...
311	319
312	320		# echo Global forwarding is not enabled. Please refer to the administrator
313	321		# echo responsible for this machine, enabling it might be a security hazard.
314	322
315	323		# ...or this.
316	324
317	325		echo Forcibly enabling global forwarding, note that this might be a security hazard.
318	326		echo * echo 1 \> /proc/sys/net/ipv4/ip_forward
319	327		echo 1 > /proc/sys/net/ipv4/ip_forward
320	328		X=`cat /proc/sys/net/ipv4/ip_forward`
321	329		if [ "$X" == "0" ]; then
322	330		echo Unable to enable global forwarding. Please refer to the administrator
323	331		echo responsible for this machine.
324	332		fi
325	333		fi
326	334
327	335		echo * route add -host $QEMU_GUEST_IP_ADDRESS dev $1
328	336		route add -host $QEMU_GUEST_IP_ADDRESS dev $1
329	337
330	338		echo * echo 1 \> /proc/sys/net/ipv4/conf/$1/proxy_arp
331	339		echo 1 > /proc/sys/net/ipv4/conf/$1/proxy_arp
332	340		X=`cat /proc/sys/net/ipv4/conf/$1/proxy_arp`
333	341		if [ "$X" == "0" ]; then
334	342		echo -n Retrying
335	343		while [ "$X" == "0" ]; do
336	344		sleep 1
337	345		echo -n .
338	346		echo 1 > /proc/sys/net/ipv4/conf/$1/proxy_arp
339	347		X=`cat /proc/sys/net/ipv4/conf/$1/proxy_arp`
340	348		done
341	349		echo OK
342	350		fi
343	351
344	352		echo * arp -Ds $QEMU_GUEST_IP_ADDRESS $1 pub
345	353		arp -Ds $QEMU_GUEST_IP_ADDRESS $1 pub
346	354
347	355		echo * arp -Ds $QEMU_GUEST_IP_ADDRESS $QEMU_HOST_GATEWAY_IF pub
348	356		arp -Ds $QEMU_GUEST_IP_ADDRESS $QEMU_HOST_GATEWAY_IF pub
349	357
350	358		# Set up experimental UDP proxies. Depending on the protocol of interest
351	359		# messages in one or both directions might need to be relayed.
352	360		#
353	361		# UDP port 79 is used for Dialarm signals, a unidirectional proxy is
354	362		# adequate for this but detection of hosts changing state (i.e. being
355	363		# added to or removed from the population of cooperating systems) is far
356	364		# more responsive if a bidirectional proxy is available.
357	365
358	366		PROXY_ID=1
359	367		case "$1" in
360	368		tun1)
361	369		PROXY_ID=2
362	370		;;
363	371		tun2)
364	372		PROXY_ID=3
365	373		;;
366	374		tun3)
367	375		PROXY_ID=4
368	376		;;
369	377		tun4)
370	378		PROXY_ID=5
371	379		;;
372	380		tun5)
373	381		PROXY_ID=6
374	382		;;
375	383		tun6)
376	384		PROXY_ID=7
377	385		;;
378	386		tun7)
379	387		PROXY_ID=8
380	388		;;
381	389		esac
382	390
383	391		# echo * udp-broadcast-relay -f $PROXY_ID 79 $QEMU_HOST_GATEWAY_IF $1
384	392		# /usr/local/src/udp-broadcast-relay/udp-broadcast-relay-0.3/udp-broadcast-relay \
385	393		# -f $PROXY_ID 79 $QEMU_HOST_GATEWAY_IF $1
386	394
387	395		# Alternatively use this one which is oriented towards IP addresses
388	396		# rather than interfaces.
389	397
390	398		# Note attempt to counteract any niceness applied to Qemu itself.
391	399
392	400		ps ax \| grep 'udp-proxy[ ]-z 79 ' >/dev/null 2>&1
393	401		if [ $? != 0 ]; then
394	402		echo * udp-proxy -z 79 $QEMU_GUEST_IP_ADDRESS
395	403		/usr/bin/nice --adjustment=20 /usr/local/src/udp-proxy/udp-proxy -z 79 $QEMU_GUEST_IP_ADDRESS
396	404		else
397	405		echo * Already running udp-proxy -z 79 $QEMU_GUEST_IP_ADDRESS
398	406		fi
399	407
400	408		# echo * udp-proxy -z 13264 $QEMU_GUEST_IP_ADDRESS
401	409		# /usr/local/src/udp-proxy/udp-proxy -z 13264 $QEMU_GUEST_IP_ADDRESS
402	410
403	411		echo .../qemu/qemu-ifup completed.
404	412		```
405	413
406	414		/etc/qemu-ifdown (for both Linux and Windows):
407	415
408	416		``` bash
409	417		#!/bin/sh
410	418
411	419		echo * route del -host $QEMU_GUEST_IP_ADDRESS dev $1
412	420		route del -host $QEMU_GUEST_IP_ADDRESS dev $1
413	421
414	422		echo * ifconfig $1 down
415	423		ifconfig $1 down
416	424		```
417	425
418	426		In actual fact, these operations were cribbed from User Mode Linux (below) where they are embedded inside a host library.
419	427
420	428		## Slackware x86 Guest using User Mode Linux
421	429
422	430		User Mode Linux runs a guest kernel as a standard program, i.e. there is no emulation or virtualisation involved. The guest kernel can be allocated either physical discs or filesystems contained in files.
423	431
424	432		Put a .iso corresponding to a recent Slackware DVD in /export/uml. Unpack the initrd using zcat and cpio, save it as an ext3 image initrd_unpacked. Using dd create an empty file root_fs_slackware which will be partitioned and formatted during installation.
425	433
426	434		Use the sources from e.g. a recent Slackware to compile kernel plus modules with ARCH=um using a suffix -uml. Save the kernel to /export/uml/linux, install the modules and then copy them into the initrd filesystem.
427	435
428	436		Boot the UML kernel, telling it to use the initrd image and DVD iso:
429	437
430	438		``` bash
431	439		# ./linux ubd0=initrd_unpacked ubd1=root_fs_slackware fake_ide ubd2r=slackware-13.37-install-dvd.iso rw
432	440		```
433	441
434	442		Run fdisk and setup as normal, you might need to tell it to install to /dev/ubd1 and use /dev/ubd2 for source. Finally, copy the modules onto the target filesystem.
435	443
436	444		When complete start up like this:
437	445
438	446		``` bash
439	447		# Routine startup of a UML guest relies on (the host) running /usr/lib/uml/uml_net
440	448		# to condition ARP, forwarding etc.
441	449
442	450		echo * ./linux ubd0=initrd_unpacked ubd1=root_fs_slackware fake_ide ubd2r=slackware-13.37-install-dvd.iso \
443	451		root=/dev/ubdb1 eth0=tuntap,,,192.168.1.22
444	452
445	453		screen -S UML_3 \
446	454		./linux ubd0=initrd_unpacked ubd1=root_fs_slackware fake_ide ubd2r=slackware-13.37-install-dvd.iso \
447	455		root=/dev/ubdb1 eth0=tuntap,,,192.168.1.22
448	456
449	457		cd ..
450	458		```
451	459
452	460		Note that this is usually run from an X session, since the multiple virtual consoles appear as separate xterms. Also see [1](http://wiki.freepascal.org/linux/kernel/user_mode_VM).
453	461
454	462		## Debian 68k Guest using Aranym
455	463
456	464		``` bash
457	465		# apt-get install aranym
458	466		```
459	467
460	468		I (MarkMLl) note this installs bridge-utils but instead am going to use my standard Qemu-style startup scripts, which themselves were originally based on sequences executed internally by UML; note that Hercules for zSeries (above) is the odd-one-out here since the guest uses SLIP for networking.
461	469
462	470		Referring to <https://wiki.debian.org/Aranym/Quick>, download <https://www.freewrt.org/~tg/dc11m68k.tgz> and check its signature. Unpack, noting a kernel vmlinuz-2.6.39-2-atari, a filesystem image dc11.img.xz and a configuration file aranym.config.
463	471
464	472		In aranym.config, change the ETH0 section to read:
465	473
466		-	~~`Type = ptp`\~~
467		-	~~`HostIP = 192.168.22.1`\~~
468		-	~~`AtariIP = 192.168.22.22`\~~
469		-	~~`Netmask = 255.255.255.0`~~
	474	+	``` pascal
	475	+	Type = ptp
	476	+	HostIP = 192.168.22.1
	477	+	AtariIP = 192.168.22.22
	478	+	Netmask = 255.255.255.0
	479	+	```
470	480
471	481		Change the startup script runaranym to read:
472	482
473	483		``` bash
474	484		#!/bin/sh
475	485
476	486		QEMU_GUEST_IP_ADDRESS=192.168.22.22
477	487		QEMU_GUEST_IP_GATEWAY=192.168.22.1
478	488		QEMU_HOST_GATEWAY=eth0
479	489		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY
480	490
481	491		/etc/qemu-ifup tap7
482	492
483	493		cd "$(dirname "$0")"
484	494		SDL_AUDIODRIVER=dummy; export SDL_AUDIODRIVER
485	495		aranym-mmu -l -c aranym.config
486	496
487	497		/etc/qemu-ifdown tap7
488	498		```
489	499
490	500		Uncompress the image file:
491	501
492	502		``` bash
493	503		# unxz dc11.img.xz
494	504		```
495	505
496	506		Using xterm on a graphical login, run the startup script:
497	507
498	508		``` bash
499	509		# runaranym
500	510		```
501	511
502	512		The result of that should be a console for the guest Debian system.
503	513
504	514		On the guest console, login as root with password root, and immediately change the password to something appropriate using the passwd command. Change the hostname in /etc/hostname and /etc/hosts, the IP address etc. in /etc/network/interfaces, and the nameserver in /etc/resolv.conf. Reboot and check that the network is operational by pinging from the guest to the site router (e.g. 192.168.1.1) and then pinging the guest (192.168.22.22) from any convenient system; if this doesn't work fix it before continuing.
505	515
506	516		Then as described on <https://wiki.debian.org/Aranym/Quick> run the three commands:
507	517
508	518		``` bash
509	519		# dpkg-reconfigure openssh-server
510	520		# apt-get update
511	521		# apt-get install popularity-contest
512	522		```
513	523
514	524		Finally edit /root/profile to remove the reminder to run the above. It should now be possible to login using SSH, and to continue to configure and use the system like any Debian guest.
515	525
516	526		## Debian zSeries Guest using Hercules, without VM
517	527
518	528		Hercules is a commercial-grade emulator for IBM mainframes, it is available as a standard package for e.g. Debian and related Linux distributions. Once the emulator is running, enter
519	529
520		-	~~`ipl 120`~~
	530	+	```text
	531	+	ipl 120
	532	+	```
521	533
522	534		to boot Linux from device 120. Hopefully SSH will be operational so you won't need to interact with the console, but if you do then prefix each line that is to go to the guest operating system (i.e. rather than to the console itself) with a dot.
523	535
524	536		Refer to the URL in the script below for more details.
525	537
526	538		Startup:
527	539
528	540		``` bash
529	541		#!/bin/sh
530	542
531	543		# PREREQUISITE: Boot with ipl 120
532	544
533	545		# Note that this makes no attempt to support IPv6.
534	546
535	547		iptables -t nat -A POSTROUTING -o eth1 -s 192.168.22.0/24 -j MASQUERADE
536	548		iptables -A FORWARD -s 192.168.22.0/24 -j ACCEPT
537	549		iptables -A FORWARD -d 192.168.22.0/24 -j ACCEPT
538	550		echo 1 > /proc/sys/net/ipv4/ip_forward
539	551		echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
540	552
541	553		# http://www.josefsipek.net/docs/s390-linux/hercules-s390.html
542	554
543	555		screen -S HERC_5 \
544	556		hercules
545	557
546	558		cd ..
547	559		```
548	560
549	561		Configuration:
550	562
551		-	~~`CPUSERIAL 000069 # CPU serial number`\~~
552		-	~~`CPUMODEL 9672 # CPU model number`\~~
553		-	~~`MAINSIZE 256 # Main storage size in megabytes`\~~
554		-	~~`XPNDSIZE 0 # Expanded storage size in megabytes`\~~
555		-	~~`CNSLPORT 3270 # TCP port number to which consoles connect`\~~
556		-	~~`NUMCPU 2 # Number of CPUs`\~~
557		-	~~`LOADPARM 0120.... # IPL parameter`\~~
558		-	~~`OSTAILOR LINUX # OS tailoring`\~~
559		-	~~`PANRATE SLOW # Panel refresh rate (SLOW, FAST)`\~~
560		-	~~`ARCHMODE ESAME # Architecture mode ESA/390 or ESAME`\~~
	563	+	``` pascal
	564	+	CPUSERIAL 000069 # CPU serial number
	565	+	CPUMODEL 9672 # CPU model number
	566	+	MAINSIZE 256 # Main storage size in megabytes
	567	+	XPNDSIZE 0 # Expanded storage size in megabytes
	568	+	CNSLPORT 3270 # TCP port number to which consoles connect
	569	+	NUMCPU 2 # Number of CPUs
	570	+	LOADPARM 0120.... # IPL parameter
	571	+	OSTAILOR LINUX # OS tailoring
	572	+	PANRATE SLOW # Panel refresh rate (SLOW, FAST)
	573	+	ARCHMODE ESAME # Architecture mode ESA/390 or ESAME
561	574
562		-	~~`# .-----------------------Device number`\~~
563		-	~~`# \| .-----------------Device type`\~~
564		-	~~`# \| \| .---------File name and parameters`\~~
565		-	~~`# \| \| \|`\~~
566		-	~~`# V V V`\~~
567		-	~~`#--- ---- --------------------`\~~
	575	+	# .-----------------------Device number
	576	+	# \| .-----------------Device type
	577	+	# \| \| .---------File name and parameters
	578	+	# \| \| \|
	579	+	# V V V
	580	+	#--- ---- --------------------
568	581
569		-	~~`# console`\~~
570		-	~~`001F 3270`\~~
	582	+	# console
	583	+	001F 3270
571	584
572		-	~~`# terminal`\~~
573		-	~~`0009 3215`\~~
	585	+	# terminal
	586	+	0009 3215
574	587
575		-	~~`# reader`\~~
576		-	~~`000C 3505 /export/zlinux/rdr/kernel.debian /export/zlinux/rdr/parmfile.debian /export/zlinux/rdr/initrd.debian autopad eof`\~~
	588	+	# reader
	589	+	000C 3505 /export/zlinux/rdr/kernel.debian /export/zlinux/rdr/parmfile.debian /export/zlinux/rdr/initrd.debian autopad eof
577	590
578		-	~~`# printer`\~~
579		-	~~`000E 1403 /export/zlinux/prt/print00e.txt crlf`\~~
	591	+	# printer
	592	+	000E 1403 /export/zlinux/prt/print00e.txt crlf
580	593
581		-	~~`# dasd`\~~
582		-	~~`0120 3390 /export/zlinux/dasd/3390.LINUX.0120`\~~
583		-	~~`0121 3390 /export/zlinux/dasd/3390.LINUX.0121`\~~
	594	+	# dasd
	595	+	0120 3390 /export/zlinux/dasd/3390.LINUX.0120
	596	+	0121 3390 /export/zlinux/dasd/3390.LINUX.0121
584	597
585		-	~~`# tape`\~~
586		-	~~`0581 3420`\~~
	598	+	# tape
	599	+	0581 3420
587	600
588		-	~~`# network s390 realbox`\~~
589		-	~~`# 0A00,0A01 CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1`\~~
590		-	~~`0A00,0A01 CTCI -n /dev/net/tun -t 1500 192.168.22.21 192.168.1.22`~~
	601	+	# network s390 realbox
	602	+	# 0A00,0A01 CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1
	603	+	0A00,0A01 CTCI -n /dev/net/tun -t 1500 192.168.22.21 192.168.1.22
	604	+	```
591	605
592	606		Note that the guest network is configured as SLIP via a simulated CTC (Channel To Channel) device. Best not fooled with.
593	607
594	608		## Debian zSeries Guest using Hercules, with VM
595	609
596	610		This combination is unlikely to work using freely-available software, since Linux requires at least an S/390 G3 system while the most recent IBM VM available is VM/370. It might be technically possible to run a non-free VM on Hercules, but at the time of writing it is at best unclear whether this could be done legally.
597	611
598	612		This means that it is not, for example, possible to run a VM host with simultaneous Linux and MUSIC/SP guests.
599	613
600	614		## MUSIC/SP using Sim/390 or Hercules
601	615
602	616		This section is an outline only. Note that in the IBM ecosystem OS and VM are the names of specific operating systems, rather than being a generic abbreviation; in addition DOS is a '60s-era IBM operating system with no connection to Microsoft or PCs.
603	617
604	618		MUSIC/SP is a freely-available (but not open source) operating system which implements a subset of IBM's MVS API, i.e. is to some extent compatible with operating systems of the OS/360 lineage in particular OS/VS1, extended with some novel features including a filesystem with user-accessible directories. It does not provide an API compatible with Linux, and uses the EBCDIC character set.
605	619
606	620		Unlike other freely-available OS-compatible operating systems (see for example [2](http://www.ibiblio.org/jmaynard/), [3](http://gunkies.org/wiki/Installing_VM/370_on_Hercules), and the section below), MUSIC/SP provides TCP/IP networking. However this requires that the IUCV (Inter User Communication Vehicle) be provided by the underlying platform and that there is a suitable network support kernel for it to talk to: these are normally made available by IBM's VM operating system (VM/SP or VM/ESA, a sufficiently-recent version of which is not freely available).
607	621
608	622		Considering emulated environments, IUCV can be provided either by running a recent VM on top of Hercules, or by running the freely-available (but not open source) Sim/390 emulator on Windows. Hercules does not provide IUCV or a network support kernel directly (although as of early 2012 this might be being addressed), so while MUSIC/SP will run on Hercules it will not have TCP/IP-based networking facilities: use Sim/390 if you really need this.
609	623
610	624		Regrettably, the maintainer of MUSIC/SP and Sim/390 is no longer active, and while binaries and documentation remain available for download via [4](http://www.canpub.com/teammpg/de/mcgweb/) the sources are not.
611	625
612	626		## VM/370 using Hercules
613	627
614	628		This section is an outline only. Note that in the IBM ecosystem OS and VM are the names of specific operating systems, rather than being a generic abbreviation; in addition DOS is a '60s-era IBM operating system with no connection to Microsoft or PCs.
615	629
616	630		VM/370, which is freely available as the "SixPack" (currently v1.2 as of early 2013), provides a hypervisor running on the "bare metal" which can host multiple single- or multitasking operating systems such as the (provided) Conversational Monitor System (CMS) or derivatives of DOS or OS (e.g. VSE or MVS).
617	631
618	632		The CMS interactive environment is a distant cousin to unix, and is probably usable by anybody who remembers MS-DOS or older operating systems; the "SixPack" includes extensive but not complete online help. There is no networking API exposed to user programs: code and data may be moved between the host computer (running Hercules) and guest sessions by mounting files simulating tape devices, by simulations of an 80-column card punch and reader, or by a simulation of a line printer.
619	633
620	634		In common with other IBM operating systems of the era, the documented API is in the form of macros for an IBM-compatible assembler; other types of interface are available including diag codes for communication between CMS and VM, and virtualised hardware access using Channel Control Words (CCWs). The services provided are roughly comparable with MS-DOS v1 or CP/M, i.e. there are separate sets of macros for handling different classes of peripherals: do not expect to open the terminal, card reader or printer as a file. Particularly if the S/380 hack (see below) is applied, the GCC compiler and standard libraries may be used but most software development and maintenance is done using assembler.
621	635
622	636		## IBM S/370, S/390, and the S/380 "hack"
623	637
624	638		This section is an even sketchier outline.
625	639
626	640		As discussed elsewhere, the S/360 and S/370 architectures are limited to 24-bit addresses while the S/390 allows 31-bit addresses without, in general, breaking compatibility. There is an unofficial extension of the Hercules emulator (frowned upon by purists) that implements a non-standard "S/380" architecture and modifies the most-recent freely-available IBM mainframe operating systems (VSE nee DOS, MVS nee OS, and VM/370) to exploit this extension. Using this, there is sufficient available memory to run a large-scale compiler such as GCC natively on one of the classic IBM operating systems, with the important caveats that only one program can use this facility at a time (i.e. while a 31-bit GCC and a 24-bit make should work, two copies of the 31-bit GCC won't), and that in the case of VM one program means one program per computer rather than one program per virtualised system/login.
627	641
628	642		To make use of this, you need the Hercules-380 patch from [5](http://mvs380.sourceforge.net/), a classic operating system such as the VM/CMS "sixpack" from [6](http://vm370.31bits.net/vm370sixpack-1_2.zip), and possibly the MECAFF enhancement for additional terminal sessions and the IND\$FILE program. In practice, it is impossible to do any of this without joining Yahoo!, and subscribing to the Hercules-VM370, hercules-os380 and H390-VM groups.
629	643
630	644		## IA-64 (Itanium, Merced, McKinley etc.)
631	645
632	646		Terminally sketchy.
633	647
634	648		The FPC port targeting IA-64 exists in absolutely minimal form, i.e. a few skeleton files and that's about it. Since the IA-64 architecture appears to be heading in the same direction as its predecessor the iAPX-432, it's highly questionable whether any more work will be done on this architecture. However, for completeness (and because this author wants to be able to inspect some Itanium binaries)...
635	649
636	650		While a few systems turn up on eBay etc., the asking price tends to be dictated by what the seller paid a few years ago rather than by what anybody expects to pay today. There is a simulator, written by HP, called "Ski", which is now open source. See [7](http://www.gelato.unsw.edu.au/IA64wiki/SkiSimulator), [8](http://www.hpl.hp.com/research/linux/ski/download.php) plus the Sourceforge project repository.
637	651
638	652		(On a fairly complete development system running Debian) get the most recent Ski sources from Sourceforge. Run autogen.sh, installing e.g. autoconf, libtool and libelf-dev if necessary. Run make, install additional libraries such as gperf, bison, flex etc. as necessary. It might be necessary to edit syscall-linux.c to comment out the reference to asm/page.h which apparently isn't needed for very recent (Linux 3.x) kernels. On success get root and run make install.
639	653
640	654		Assuming the disc image is a file named /export/ia-64/sda (e.g. renamed from the downloaded sda-debian) then
641	655
642		-	~~`bski bootloader vmlinux simscsi=/export/ia-64/sd`~~
	656	+	```text
	657	+	bski bootloader vmlinux simscsi=/export/ia-64/sd
	658	+	```
643	659
644	660		Note the dropped final letter, that parameter is used as a prefix rather than being the name of a file or directory.
645	661
646	662		As with a number of other emulators described on this page, this requires an X session for the console.
647	663
648	664		This writer (MarkMLl) can't get networking running, either using the instructions at [9](http://www.hpl.hp.com/research/linux/ski/HOWTO-ski-networking.php) or using a tun/tap solution very roughly as suggested by [10](http://www.gelato.unsw.edu.au/IA64wiki/SkiVirtualNetwork). It might be necessary to try a much older host kernel, i.e. late 2.4 or early 2.6, however this is not currently being pursued due to lack of relevance.
649	665
650	666		The kernel from HP is 2.4.20, the filesystem is described as "Debian Sid" but from the kernel version is probably somewhere between "Woody" (3.0) and "Sarge" (3.1). I don't know how easy it's going to be to get this up to scratch, at the very least a working network is going to be a prerequisite.
651	667
652	668		------------------------------------------------------------------------
653	669
654	670		## Relative Performance
655	671
656	672		Performance is, in general, disappointing. Using an informal "torture test" which exercises the CPU and disc access:
657	673
658		-	~~`Compaq ProLiant ML530 G2, 2.8GHz, 3Gb, 8 jobs, 390W 0m12.170 79`\~~
	674	+	```text
	675	+	Compaq ProLiant ML530 G2, 2.8GHz, 3Gb, 8 jobs, 390W 0m12.170 79
659	676
660		-	~~`Linksys NSLU2, 266MHz 32Mb, 1 job, 7W 6m35.014s 46`\~~
	677	+	Linksys NSLU2, 266MHz 32Mb, 1 job, 7W 6m35.014s 46
661	678
662		-	~~`Qemu ARM, 1 job, 390W 42m58.925s 16,757`\~~
	679	+	Qemu ARM, 1 job, 390W 42m58.925s 16,757
663	680
664		-	~~`Qemu MIPS, 1 job, 390W 17m49.103s 6,949`\~~
	681	+	Qemu MIPS, 1 job, 390W 17m49.103s 6,949
665	682
666		-	~~`Qemu x86, 1 job, 390W 47m0.441s 18,330`\~~
	683	+	Qemu x86, 1 job, 390W 47m0.441s 18,330
667	684
668		-	~~`UML, 1 job, 390W 8m26.529s 3,289`\~~
	685	+	UML, 1 job, 390W 8m26.529s 3,289
669	686
670		-	~~`Hercules zSeries, 4 jobs, 390W 9m43.330s 3,790`~~
	687	+	Hercules zSeries, 4 jobs, 390W 9m43.330s 3,790
	688	+	```
671	689
672	690		The final column in the above list is the W-Mins to complete the job. These timings are without the benefit of kernel support from kqemu (obsolete) or KVM, but the fact that Qemu's support for MIPS is significantly better than that for other architectures, and the fact that the Hercules emulator is in all cases better than Qemu, does make one wonder how efficient the code is.
673	691
674	692		Compiling FPC 2.4.2 using time make NOGDB=1 OPT='-O- -gl' all :
675	693
676		-	~~`Host (x86, Linux, Debian):`\~~
	694	+	```text
	695	+	Host (x86, Linux, Debian):
677	696
678		-	~~` real 4m47.842s`\~~
679		-	~~` user 3m42.126s`\~~
680		-	~~` sys 0m33.506s`\~~
	697	+	real 4m47.842s
	698	+	user 3m42.126s
	699	+	sys 0m33.506s
681	700
682		-	~~`Slug (32Mb, ARM, Linux, Debian):`\~~
	701	+	Slug (32Mb, ARM, Linux, Debian):
683	702
684		-	~~` real 284m58.543s`\~~
685		-	~~` user 86m45.570s`\~~
686		-	~~` sys 20m46.500s`\~~
	703	+	real 284m58.543s
	704	+	user 86m45.570s
	705	+	sys 20m46.500s
687	706
688		-	~~`Qemu (ARM, Linux, Debian):`\~~
	707	+	Qemu (ARM, Linux, Debian):
689	708
690		-	~~` real 406m31.931s`\~~
691		-	~~` user 236m49.030s`\~~
692		-	~~` sys 148m58.110s`\~~
	709	+	real 406m31.931s
	710	+	user 236m49.030s
	711	+	sys 148m58.110s
693	712
694		-	~~`Qemu (x86, Linux, Slackware):`\~~
	713	+	Qemu (x86, Linux, Slackware):
695	714
696		-	~~` real 141m45.700s`\~~
697		-	~~` user 122m40.724s`\~~
698		-	~~` sys 17m15.670s`\~~
	715	+	real 141m45.700s
	716	+	user 122m40.724s
	717	+	sys 17m15.670s
699	718
700		-	~~`Qemu (x86, Windows 2000):`\~~
	719	+	Qemu (x86, Windows 2000):
701	720
702		-	~~` Elapsed 108m`\~~
	721	+	Elapsed 108m
703	722
704		-	~~`UML (x86, Linux, Slackware):`\~~
	723	+	UML (x86, Linux, Slackware):
705	724
706		-	~~` real 238m41.257s`\~~
707		-	~~` user 45m54.460s`\~~
708		-	~~` sys 3m44.140s`~~
	725	+	real 238m41.257s
	726	+	user 45m54.460s
	727	+	sys 3m44.140s
	728	+	```
709	729
710	730		Compiling Lazarus 0.9.30 using time make LCL_PLATFORM=gtk2 bigide :
711	731
712		-	~~`Host (x86, Linux, Debian):`\~~
	732	+	```text
	733	+	Host (x86, Linux, Debian):
713	734
714		-	~~` real 2m21.072s`\~~
715		-	~~` user 2m6.452s`\~~
716		-	~~` sys 0m12.285s`\~~
	735	+	real 2m21.072s
	736	+	user 2m6.452s
	737	+	sys 0m12.285s
717	738
718		-	~~`Slug (32Mb, ARM, Linux, Debian):`\~~
	739	+	Slug (32Mb, ARM, Linux, Debian):
719	740
720		-	~~` real 9385m49.319s`\~~
721		-	~~` user 67m23.460s`\~~
722		-	~~` sys 430m9.870s`\~~
	741	+	real 9385m49.319s
	742	+	user 67m23.460s
	743	+	sys 430m9.870s
723	744
724		-	~~`Qemu (ARM, Linux, Debian):`\~~
	745	+	Qemu (ARM, Linux, Debian):
725	746
726		-	~~` real 281m55.536s`\~~
727		-	~~` user 153m3.150s`\~~
728		-	~~` sys 53m27.470s`\~~
	747	+	real 281m55.536s
	748	+	user 153m3.150s
	749	+	sys 53m27.470s
729	750
730		-	~~`Qemu (x86, Linux, Slackware):`\~~
	751	+	Qemu (x86, Linux, Slackware):
731	752
732		-	~~` real 70m53.957s`\~~
733		-	~~` user 60m3.474s`\~~
734		-	~~` sys 8m8.801s`\~~
	753	+	real 70m53.957s
	754	+	user 60m3.474s
	755	+	sys 8m8.801s
735	756
736		-	~~`Qemu (x86, Windows 2000, default platform):`\~~
	757	+	Qemu (x86, Windows 2000, default platform):
737	758
738		-	~~` Elapsed 53m`\~~
	759	+	Elapsed 53m
739	760
740		-	~~`UML (x86, Linux, Slackware):`\~~
	761	+	UML (x86, Linux, Slackware):
741	762
742		-	~~` real 489m40.233s`\~~
743		-	~~` user 81m43.740s`\~~
744		-	~~` sys 7m51.280s`~~
	763	+	real 489m40.233s
	764	+	user 81m43.740s
	765	+	sys 7m51.280s
	766	+	```
745	767
746	768		## Graphical Access using VNC etc.
747	769
748	770		All of the above assumes that SSH is available so that shell (command line) sessions can be run over the network. Where necessary install e.g. the Debian ssh (or openssh, openssh-server etc.) package. It is also possible to run a program using a GUI over SSH by X forwarding, see the SSH client's -X option and the corresponding server configuration-file settings.
749	771
750	772		There are several ways of running a program using a GUI without forwarding the X protocol over SSH:
751	773
752	774		- Running Qemu or UML in an xterm.
753	775
754	776		- Using Qemu's host VNC support.
755	777
756	778		- Connecting to a Qemu (or UML etc.) guest using X.
757	779
758	780		- Connecting to a Qemu (or UML etc.) guest using VNC.
759	781
760	782		In all cases it is worth using a low-resource window manager such as FluxBox or xfwm rather than KDE or Gnome.
761	783
762	784		### Running Qemu or UML in an xterm or with host VNC support
763	785
764	786		This depends on the build options of the guest system kernel etc. In general, display resolution and depth will be limited by the emulated hardware, the network ports are associated with the host (rather than guest) system. See the Qemu documentation for details.
765	787
766	788		### Connecting to a Qemu (or UML etc.) guest using X
767	789
768	790		Install the Gnome Display Manager (gdm) on the guest system. This allows a desktop system to log into it using XDMCP, the desktop system determines the display resolution and depth.
769	791
770	792		### Connecting to a Qemu (or UML etc.) guest using VNC
771	793
772	794		This method also works well for arbitrary systems, even if Qemu etc. is not being used.
773	795
774	796		Install gdm and RealVNC (or, with limitations, TightVNC) on the guest system; the latter might be needed for ARM guests but RealVNC is to be preferred when available. This allows a desktop system to log into it using VNC, the guest system determines the display resolution and depth and network ports are associated with the guest (rather than host) system.
775	797
776	798		In /etc/inittab, insert something like this:
777	799
778		-	~~`6:23:respawn:/sbin/getty 38400 tty6`\~~
	800	+	```text
	801	+	6:23:respawn:/sbin/getty 38400 tty6
779	802
780		-	~~`# Added in lieu of trying to get it working in inetd.conf. MarkMLl.`\~~
	803	+	# Added in lieu of trying to get it working in inetd.conf. MarkMLl.
781	804
782		-	~~`8:23:respawn:/usr/local/vnc/vncshim-0-20`\~~
783		-	~~`# 9:23:respawn:/usr/local/vnc/vncshim-4-24`\~~
	805	+	8:23:respawn:/usr/local/vnc/vncshim-0-20
	806	+	# 9:23:respawn:/usr/local/vnc/vncshim-4-24
784	807
785		-	~~`# Example how to put a getty on a serial line (for a terminal)`\~~
786		-	~~`#`\~~
787		-	~~`#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100`~~
	808	+	# Example how to put a getty on a serial line (for a terminal)
	809	+	#
	810	+	#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
	811	+	```
788	812
789	813		Many systems limit the number of VNC servers that may be run per system (including localhost) as the side effect of a window manager XDMCP security precaution. If necessary, edit the window manager configuration file (gdm.conf, kdmrc etc.) to increase the number of sessions that each XDMCP client can request, e.g. in the case of gdm.conf:
790	814
791		-	~~`[xdmcp]`\~~
792		-	~~`Enable=true`\~~
793		-	~~`DisplaysPerHost=6`~~
	815	+	```text
	816	+	[xdmcp]
	817	+	Enable=true
	818	+	DisplaysPerHost=6
	819	+	```
794	820
795	821		Create /usr/local/vnc/vncshim-0-20 to read:
796	822
797	823		``` bash
798	824		#!/bin/bash
799	825
800	826		# This forms a shim between /etc/inittab and the VNC server, necessitated by
801	827		# the facts that (a) I can't get this command working reliably in inetd.conf
802	828		# and (b) lines in initab have restricted length.
803	829		#
804	830		# Note that the name of the file reflects the fact that it might request non-
805	831		# standard combinations of VNC port and X display number. MarkMLl.
806	832
807	833		# My preference is to select default linear dimensions that appear somewhere
808	834		# in the list of conventional graphics modes. 1200x960 fits inside a 1280x1024
809	835		# screen, even allowing that the title bar etc. will take additional space.
810	836
811	837		SIZE=1200x960
812	838
813	839		# The DPI setting can usefully be set to match the user's normal screen, leave
814	840		# undefined (commented out) if in doubt.
815	841
816	842		DPI='-dpi 96'
817	843
818	844		# Each VNC server running on a host must have a distinct suffix to prevent port
819	845		# and display number clashes.
820	846
821	847		SUFFIX=0
822	848
823	849		# Some option formats vary between RealVNC (top) and TightVNC (bottom).
824	850
825	851		OPTIONS='DisconnectClients=0 -NeverShared'
826	852		# OPTIONS='-dontdisconnect -nevershared'
827	853
828	854		####################### CHANGE NOTHING BELOW HERE ###########################
829	855
830	856		VNCPORT=570$SUFFIX
831	857		XDISPLAY=:2$SUFFIX
832	858
833	859		# Try to work out what this system is. Note particular care to allow spaces
834	860		# in the desktop name.
835	861
836	862		WHATAMI=`dirname $0`/whatami
837	863		if [ -x $WHATAMI ]; then
838	864		WHATAMI2=`$WHATAMI`
839	865		else
840	866		if [ -r $WHATAMI ]; then
841	867		WHATAMI2=`cat $WHATAMI`
842	868		else
843	869		WHATAMI2=$$
844	870		fi
845	871		fi
846	872		DESKTOP='-desktop '\'$WHATAMI2\'
847	873
848	874		# Optional Java viewer.
849	875
850	876		if [ -r `dirname $0`/classes/index.vnc ]; then
851	877		JAVA="-httpd `dirname $0`/classes -httpPort 580$SUFFIX"
852	878		fi
853	879
854	880		# This is the only way I can get it working the way I want, i.e. with reliable
855	881		# handling of spaces in the desktop name. I'm hardly proud of it.
856	882
857	883		rm -f `dirname $0`/.vncshim-$SUFFIX-1$SUFFIX
858	884
859	885		cat >`dirname $0`/.vncshim-$SUFFIX-1$SUFFIX <<EOT
860	886		#!/bin/sh
861	887		exec /usr/bin/Xvnc -geometry $SIZE $DPI -depth 16 $DESKTOP \
862	888		-rfbport $VNCPORT -rfbauth /root/.vnc/passwd-$SUFFIX $JAVA \
863	889		$OPTIONS -query localhost -once $XDISPLAY
864	890		EOT
865	891
866	892		chmod +x `dirname $0`/.vncshim-$SUFFIX-1$SUFFIX
867	893		exec `dirname $0`/.vncshim-$SUFFIX-1$SUFFIX
868	894		```
869	895
870	896		Create /usr/local/vnc/whatami to read:
871	897
872	898		``` bash
873	899		#!/bin/bash
874	900
875	901		echo -n "`hostname`, "
876	902		_WHATAMI=`uname -m`
877	903		if [[ $_WHATAMI == i?86 ]]; then
878	904		_WHATAMI='i586'
879	905		fi
880	906		if [[ $_WHATAMI == arm* ]]; then
881	907		_WHATAMI='arm'
882	908		fi
883	909
884	910		if [ -x `dirname $0`/whatami-$_WHATAMI ]; then
885	911		`dirname $0`/whatami-$_WHATAMI
886	912		else
887	913		uname -m
888	914		fi
889	915		```
890	916
891	917		Additional scripts e.g. whatami-arm can query /proc/cpuinfo, which is different for each architecture. Make sure that all scripts are set +x for root.
892	918
893	919		Use vncpasswd to set up password files /root/.vnc/passwd-0 etc.
894	920
895	921		So far, I find that RealVNC works fine when invoked as above, but TightVNC doesn't correctly invoke the display manager.
896	922
897	923		## Accessing "Unusual" Devices
898	924
899	925		This section covers devices such as audio (i.e. used for playing .wav files) and MIDI, and USB devices which are not claimed by the host or guest kernel.
900	926
901	927		### Sound/MIDI for Qemu
902	928
903	929		Don't expect this to be hi-fi quality, but it should be adequate for operator alerts etc.
904	930
905	931		#### Identifying the Host's Hardware
906	932
907	933		Obviously, a good starting point for this is using lspci and lsusb to determine what physical hardware is installed. The next stage is usually to consult dmesg output and to use lsmod to determine what subsystems the kernel has loaded hence what APIs are available. Graphical tools such as the KDE Info Centre can also be useful here, however identifying which API is most useful can be a bit of a black art.
908	934
909	935		The current writer (MarkMLl) has a Debian "Squeeze" host with USB-connected audio and MIDI devices, with the latter connected to a Yamaha tone generator. An alternative (and more conventional) configuration would be to have an internal soundcard, with both audio and MIDI output feeding a loudspeaker.
910	936
911	937		Knowing what hardware and subsystems are available, the remaining question is which subsystems Qemu can make use of. Running this command goes some way towards providing an answer:
912	938
913		-	~~`$ qemu -audio-help \|grep ^Name:`\~~
914		-	~~`Name: alsa`\~~
915		-	~~`Name: oss`\~~
916		-	~~`Name: sdl`\~~
917		-	~~`Name: esd`\~~
918		-	~~`Name: pa`\~~
919		-	~~`Name: none`\~~
920		-	~~`Name: wav`~~
	939	+	```text
	940	+	$ qemu -audio-help \|grep ^Name:
	941	+	Name: alsa
	942	+	Name: oss
	943	+	Name: sdl
	944	+	Name: esd
	945	+	Name: pa
	946	+	Name: none
	947	+	Name: wav
	948	+	```
921	949
922	950		For reasons that are unclear (roughly translated: I'd like some help here) I've had most success with OSS, starting Qemu with a script that includes these lines:
923	951
924	952		``` bash
925	953		export QEMU_AUDIO_DRV=oss
926	954		export QEMU_OSS_DAC_DEV=/dev/dsp1
927	955		export QEMU_OSS_ADC_DEV=/dev/dsp1
928	956		```
929	957
930	958		#### Selecting the Guest's Soundcard
931	959
932	960		Assuming that the guest is to have both audio and MIDI, common sense would suggest that the guest operating system should see both audio and MIDI hardware implemented by Qemu. According to <http://rubenerd.com/qemu-ad-lib-midi-win-31/>, this implies that Qemu should be recompiled with the capability of emulating an Adlib card, which for current versions of Qemu means running something like this:
933	961
934	962		``` bash
935	963		make clean distclean
936	964		./configure --audio-card-list=ac97,es1370,sb16,adlib
937	965		make
938	966		```
939	967
940	968		Irrespective of whether a custom Qemu is built or not, it's useful to check what devices it emulates:
941	969
942	970		``` bash
943	971		$ qemu -soundhw ?
944	972		Valid sound card names (comma separated):
945	973		pcspk PC speaker
946	974		sb16 Creative Sound Blaster 16
947	975		ac97 Intel 82801AA AC97 Audio
948	976		es1370 ENSONIQ AudioPCI ES1370
949	977		```
950	978
951	979		For some guest operating systems (e.g. Windows NT 4), adding Adlib emulation to Qemu is sufficient to get MIDI working with the Sound Blaster, i.e.
952	980
953	981		``` bash
954	982		$ qemu ... -soundhw sb16,adlib ...
955	983		```
956	984
957	985		In this case the guest uses only the standard Sound Blaster driver, possibly ignoring MPU-401 support.
958	986
959	987		For guest systems which don't benefit from this, there's little point adding something like an Adlib card if the guest operating system doesn't have a driver for it- which appears to be the case with Windows 2000. The current writer's preference is to select the ES13770, since as a straightforward PCI device it should be enumerated without difficulty by almost any guest operating system:
960	988
961	989		``` bash
962	990		$ qemu ... -soundhw es1370 ...
963	991		```
964	992
965	993		Having started Qemu, it's possible to query the emulated devices:
966	994
967		-	~~`(qemu) info pci`\~~
968		-	~~`...`\~~
969		-	~~` Bus 0, device 4, function 0:`\~~
970		-	~~` Audio controller: PCI device 1274:5000`\~~
971		-	~~` IRQ 11.`\~~
972		-	~~` BAR0: I/O at 0xc200 [0xc2ff].`\~~
973		-	~~` id ""`~~
	995	+	``` pascal
	996	+	(qemu) info pci
	997	+	...
	998	+	Bus 0, device 4, function 0:
	999	+	Audio controller: PCI device 1274:5000
	1000	+	IRQ 11.
	1001	+	BAR0: I/O at 0xc200 [0xc2ff].
	1002	+	id ""
	1003	+	```
974	1004
975	1005		The expected result of this is that the guest operating system would see audio hardware, but not MIDI. However in the case of Windows 2000 a MIDI device is emulated, so programs which use MIDI for e.g. operator alerts will work properly.
976	1006
977	1007		Anybody: need help here generalising this to other guest operating systems.
978	1008
979	1009		### USB for Qemu
980	1010
981	1011		As an example, a Velleman K8055 board is plugged into the host. First use lsusb to gets its vid:pid identifiers:
982	1012
983	1013		``` bash
984	1014		$ lsusb
985	1015		Bus 001 Device 005: ID 10cf:5500 Velleman Components, Inc. 8055 Experiment Interface Board (address=0)
986	1016		```
987	1017
988	1018		Now add these parameters to the Qemu command line:
989	1019
990	1020		``` bash
991	1021		qemu ... -usb -usbdevice host:10cf:5500 ...
992	1022		```
993	1023
994	1024		On the guest, lsusb should show the device available for use.
995	1025
996	1026		The Velleman board is unusual in that it has ID jumpers which set the last digit, i.e. multiple devices appear as 10cf:5500 through 10cf:5503. In cases where this facility is not available, the bus and device number can be used:
997	1027
998	1028		``` bash
999	1029		qemu ... -usb -usbdevice host:1.5 ...
1000	1030		```
1001	1031
1002	1032		Obviously, there's a risk here that devices will move around between invocations.
1003	1033
1004	1034		### USB for UML
1005	1035
1006	1036		There was supposedly a patch that mapped unused USB devices on the host into the guest. I'm not sure it made it into the standard release.
1007	1037
1008	1038		## QEMU User Emulation Mode in Chrooted Environment
1009	1039
1010	1040		In previous chapters QEMU's full system emulation mode was described: a complete guest system is emulated including bios and hardware. Although this approaches a real environment as close as possible, the overhead created by emulating a complete system is considerable. QEMU's user emulation mode allows to run "guest" code directly on the "host" system. The cpu is still emulated but system calls are translated into system calls on the host system. Libraries used by the "guest" code are the "guest" libraries, not the host libraries. To run a small program created for fe. ARM with no dependencies you can simply do a
1011	1041
1012		-	~~`$ qemu-arm program`~~
	1042	+	``` pascal
	1043	+	$ qemu-arm program
	1044	+	```
1013	1045
1014	1046		When the program has more and more dependencies, it becomes increasingly difficult to put all dependencies in locations that can be found by qemu-arm without messing up your host system. The solution that will be developed here is to create a chroot environment on the host in which all code is "guest" code. Advantage of this solution:
1015	1047
1016	1048		- the chroot isolates the guest from the host
1017	1049		- no need for vnc, ssh or any other solution to export screens.
1018	1050		- no booting of a guest OS system.
1019	1051		- guest "immersion" for user programs is almost complete. Only very low level and hardware related programming will notice the difference.
1020	1052		- a spectacular speed improvement for graphics (X) related tasks (running lazarus f.e.)
1021	1053		- hard disk resources are common to host and guest. Host can read and modify "guest" files but not the other way around.
1022	1054
1023	1055		Setting up the system.
1024	1056
1025	1057		For a better comprehension of what follows, here is the directory structure used in this how-to:
1026	1058
1027		-	~~`home`\~~
1028		-	~~` qemu`\~~
1029		-	~~` arm-linux-user`\~~
1030		-	~~` sparc-linux-user`\~~
1031		-	~~` scripts `\~~
1032		-	~~` disks // here are qemu images for the different systems emulated`\~~
1033		-	~~` chroot`\~~
1034		-	~~` mount `\~~
1035		-	~~` arm // here we'll chroot the arm environment`\~~
1036		-	~~` sparc `~~
	1059	+	```text
	1060	+	home
	1061	+	qemu
	1062	+	arm-linux-user
	1063	+	sparc-linux-user
	1064	+	scripts
	1065	+	disks // here are qemu images for the different systems emulated
	1066	+	chroot
	1067	+	mount
	1068	+	arm // here we'll chroot the arm environment
	1069	+	sparc
	1070	+	```
1037	1071
1038	1072		Get and build the latest qemu
1039	1073
1040	1074		``` bash
1041	1075		$ cd
1042	1076		$ git clone git://git.savannah.nongnu.org/qemu.git qemu
1043	1077		$ cd qemu
1044	1078		```
1045	1079
1046	1080		Build all emulations (full system and user emulation mode, all processors)
1047	1081
1048	1082		``` bash
1049	1083		$ ./configure --static to build
1050	1084		```
1051	1085
1052	1086		or only the user emulations needed
1053	1087
1054	1088		``` bash
1055	1089		$ ./configure --static --target-list=sparc-linux-user,arm-linux-user
1056	1090
1057	1091		$ make clean all
1058	1092		```
1059	1093
1060	1094		The --static option makes that qemu-arm and qemu-sparc are linked statically. Since they will be running in the chroot environment later on, they must be build without dependencies. Some distributions provide already statically linked binaries. fe qemu-arm-static on debian. Although they are not the latest and greatest, using these packages makes it somewhat easier. Building QEMU from source is really just a matter of minutes.
1061	1095
1062	1096		Now we need to copy the complete guest system into chroot/arm or chroot/sparc. There are several ways of doing this but when you don't have a real arm or sparc system at hand, using a QEMU image of a full system emulation as described in previous chapters is the easiest.
1063	1097
1064	1098		Mount the QEMU image.
1065	1099
1066	1100		WARNING: do not mount a qemu image when the associated guest is running!
1067	1101
1068	1102		Only raw QEMU images can be mounted as a loop-back device. If you have a qcow formatted image, convert it to a raw image.
1069	1103
1070	1104		``` bash
1071	1105		$ qemu-img convert disks/armel_hda.img -O raw disks/armel_hda.raw
1072	1106
1073	1107		$ cd chroot
1074	1108		$ su
1075	1109		# mount ../disks/armel_hda.raw mount -o loop,offset=32256
1076	1110		```
1077	1111
1078	1112		The offset is the start of the first partition on the ARM disk when the default disk layout was used during installation. If mount fails then the offset is probably wrong. To calculate the offset:
1079	1113
1080	1114		``` bash
1081	1115		# fdisk -lu ../disks/armel_hda.raw
1082	1116		```
1083	1117
1084	1118		Find the first sector of the partition that will be mounted as root. Calculate offset as (start sector number * 512). For the default SPARC debian etch installation using a sun partition table with a /boot first partition the offset is 98703360.
1085	1119
1086	1120		Check if the correct partition is mounted:
1087	1121
1088	1122		``` bash
1089	1123		# ls mount
1090	1124		```
1091	1125
1092	1126		Copy the complete system
1093	1127
1094	1128		``` bash
1095	1129		# cp -r mount/* arm/
1096	1130		# umount mount
1097	1131		```
1098	1132
1099	1133		Copy the QEMU arm emulator to the arm directory
1100	1134
1101	1135		``` bash
1102	1136		# cd arm
1103	1137		# cp ../../arm-linux-user/qemu-arm usr/local/bin
1104	1138		```
1105	1139
1106	1140		Our "guest" system is complete. Since we are sharing our "host" devices and system, we need to mount a few special directories:
1107	1141
1108	1142		``` bash
1109	1143		# mount --bind /proc proc
1110	1144		# mount --bind /dev dev
1111	1145		# mount --bind /sys sys
1112	1146		# mount --bind /tmp tmp
1113	1147		```
1114	1148
1115	1149		Why /tmp? The /tmp directory is used by the X window system. When you don't mount tmp on the host /tmp, you will get "can't open display 0:0" errors when trying to open a window in the guest.
1116	1150
1117	1151		We are going to use the host network:
1118	1152
1119	1153		``` bash
1120	1154		# sudo cp /etc/resolv.conf etc
1121	1155		```
1122	1156
1123	1157		Remains one last thing: the emulator is copied into the guest but how do we tell the system that the emulator needs to kick in when a "quest" elf is detected? This is done with binfmt_misc. A configuration script is included with QEMU that registers the QEMU user mode emulators with binfmt_misc: (on my system I had to do a chmod +x on the script)
1124	1158
1125	1159		``` bash
1126	1160		# ../../scripts/qemu-binfmt-conf.sh
1127	1161		```
1128	1162
1129	1163		When you look at this script at the end of the binary data you'll notice that the emulator is registered as /usr/local/bin/qemu-arm. And that is where we put it a few lines ago.
1130	1164
1131	1165		Launch the system:
1132	1166
1133	1167		``` bash
1134	1168		# chroot .
1135	1169		```
1136	1170
1137	1171		If all goes well:
1138	1172
1139	1173		``` bash
1140	1174		# uname -m
1141	1175		armv7l
1142	1176		```
1143	1177
1144	1178		Everything you do from here is in your "guest" system. To exit the "guest" system.
1145	1179
1146	1180		``` bash
1147	1181		# exit
1148	1182		```
1149	1183
1150	1184		And unmount the special directories.
1151	1185
1152	1186		``` bash
1153	1187		# umount proc
1154	1188		# umount dev
1155	1189		# umount sys
1156	1190		# umount tmp
1157	1191		```
1158	1192
1159	1193		Conclusion.
1160	1194
1161	1195		The ARM emulation works very well, except for gdb. On the contrary there are still quite some problems with the SPARC emulation. There is a bug in duplicating pipes which makes the use of bash impossible. The sh shell works but several unix commands don't function correctly. What works fine is fpc and lazarus! Programs can't be launched from inside lazarus. Because of the improved graphics speed when using the user emulation mode it is still worthwhile for using lazarus. Instead of starting a shell in chroot, you start directly lazarus:
1162	1196
1163	1197		``` bash
1164	1198		$ sudo chroot . /your/lazarus/dir/lazarus
1165	1199		```
1166	1200
1167	1201		To run the program compiled in lazarus, you can launch it from another "host" terminal:
1168	1202
1169	1203		``` bash
1170	1204		$ cd qemu/chroot/arm
1171	1205		$ sudo chroot . /your/program/dir/project
1172	1206		```
1173	1207
1174	1208		Here also gdb is not working.
1175	1209
1176	1210		## Docker images
1177	1211
1178	1212		Docker uses various APIs provided by the underlying operating system to isolate programs in separate namespaces.
1179	1213
1180	1214		The implication of this is that every Docker container has its own process space (i.e. processes in different containers might have the same numeric PID), network space (processes in different containers can have different routing, firewall rules and so on), filesystems (except that they share kernel files and a number of crucial libraries and configuration files) and so on.
1181	1215
1182	1216		Containerisation is distinct from virtualisation in that all containers which are running on the same host computer make use of the same host kernel, it is not possible for one container to use a different kernel (e.g. for development or deployment test purposes), and there is no absolute guarantee that a container taken over by malicious code cannot subvert the remainder of the system.
1183	1217
1184	1218		*Note that there are pitfalls for the unwary. For example, having Docker installed and the Docker daemon running can break Qemu networking if this expects to have bridged access to the host interface rather than to be sitting on its own private subnet.*
1185	1219
1186	1220		One thing that does work however, is running a 32-bit container on a 64-bit host, and in most cases the Linux kernel APIs are sufficiently backwards-compatible that the programs and libraries from an older release of a distro can run on a much more recent host. One of the cases which will be discussed here runs a container containing 32-bit Debian "Lenny" from 2008 on a host running Debian "Buster" from 2019, this combination allows e.g. compatibility with the GTK v1 widget set (no longer supported by more recent distreaux) to be tested.
1187	1221
1188	1222		### Docker fundamentals
1189	1223
1190	1224		This is not the place for a full discussion of the care and feeding of Docker, but it's worth establishing a few basic concepts.
1191	1225
1192	1226		- Host: the physical computer running e.g. Qemu (with or without KVM) or Docker.
1193	1227
1194	1228		- Guest: on a virtualised system (Qemu etc.), a completely separate memory space with its own kernel.
1195	1229
1196	1230		- Container: on a Docker based system, a group of application programs sharing the host kernel but largely isolated from the rest of the host system using various namespace mechanisms.
1197	1231
1198	1232		Looking specifically at Docker:
1199	1233
1200	1234		- Dockerfile: a succinct description of what is to go into a Docker image.
1201	1235
1202	1236		- Image: the Docker analogue of a bootable filesystem, initially built with reference to a Dockerfile.
1203	1237
1204	1238		- Container: an image which has been run, whether or not it is currently running.
1205	1239
1206	1240		Once running, a container has an associated parameter list which specifies the main program together with any sockets etc. exposed to the host. Neither an image nor a container correspond to a single file on the host, but:
1207	1241
1208	1242		- A container may be stopped and committed to an image.
1209	1243
1210	1244		- An image may be saved to a single file, in which state it can be moved between hosts.
1211	1245
1212	1246		- An image may be run a set of parameters different from those of the container committed to it.
1213	1247
1214	1248		The result of this is that if something is installed in the context of a container (e.g. Apache is added from the operating system's main repository) the container should be stopped, committed to a new image and then run with an additional parameter specifying what sockets etc. should be exposed. There are ways around that, but that combination appears to be the easiest to manage.
1215	1249
1216	1250		The Docker community has a master repository, and the docker program on a host computer may search it to locate images. However in the context of those images there appears to be no "official" way of searching the tags that allow a specific version to be pulled, hence something "messy" and subject to change like
1217	1251
1218	1252		$ docker search debian
1219	1253
1220	1254		$ wget -q https://registry.hub.docker.com/v1/repositories/debian/tags -O - \
1221	1255		\| sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' \| tr '}' '\n' \| awk -F: '{print $3}' \| grep buster
1222	1256
1223	1257		$ docker pull debian:buster
1224	1258
1225	1259		or alternatively (for the really hard to reach bits)
1226	1260
1227	1261		$ docker search vicamo
1228	1262
1229	1263		$ wget -q https://registry.hub.docker.com/v1/repositories/vicamo/debian/tags -O - \
1230	1264		\| sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' \| tr '}' '\n' \| awk -F: '{print $3}'
1231	1265
1232	1266		...
1233	1267		buster-i386
1234	1268		buster-i386-sbuild
1235	1269		buster-i386-slim
1236	1270		...
1237	1271
1238	1272		$ docker pull vicamo/debian:buster-i386-slim
1239	1273
1240	1274		Generally speaking, if a developer on e.g. Github says that he has a special-purpose image, some combination of the above commands will allow the required version (e.g. in the above example tagged buster-i386-slim) to be pulled.
1241	1275
1242	1276		Neither a container nor an image is directly mountable e.g. by using losetup. It is possible to copy files to or from a container using the `docker container cp` command, subject to the same precautions that one would take on a running unix system.
1243	1277
1244	1278		### A 64-bit Docker container with basic utilities
1245	1279
1246	1280		This is a basic installation of a 64-bit Debian stable release ("Buster" at the time of writing) on the same host version. This is useful in a situation where a developer wants to experiment with libraries etc. that he does not normally have installed, it should probably not be trusted to quarantine untrusted code.
1247	1281
1248	1282		In the instructions below, commands on the host are run in the context of a normal user so are shown prefixed by a \$ prompt, while commands run in the context of the container are run by root so shown prefixed by a \# prompt.
1249	1283
1250	1284		$ docker pull debian:buster
1251	1285
1252	1286		$ docker run --interactive --tty debian:buster
1253	1287
1254	1288		# apt-get update
1255	1289
1256	1290		# apt-get install dialog tasksel python3
1257	1291
1258	1292		# tasksel --new-install
1259	1293
1260	1294		# dpkg-reconfigure locales
1261	1295
1262	1296		Using tasksel, remove desktop and print server and add SSH. The author favours installing net-tools so that the `netstat -an` command can be used to check socket accessibility.
1263	1297
1264	1298		# apt-get install net-tools elvis-tiny
1265	1299
1266	1300		So far there is no provision for starting the SSH daemon. Add or edit /etc/rc.local to contain
1267	1301
1268	1302		#!/bin/sh
1269	1303
1270	1304		rm -rf /tmp/*
1271	1305
1272	1306		# For cases where a 32-bit container is running (by implication on a 64-bit host), make
1273	1307		# sure that commands such as uname -a return consistent information to avoid breaking
1274	1308		# the traditional ./configure && make operation.
1275	1309
1276	1310		(file -L /bin/sh \| grep -q 'ELF 32-bit LSB')
1277	1311		if [ $? -eq 0 ] ; then
1278	1312		LINUX32=linux32
1279	1313		fi
1280	1314
1281	1315		cd /etc/init.d
1282	1316		$LINUX32 ./ssh start
1283	1317		# $LINUX32 ./openbsd-inetd start
1284	1318
1285	1319		cd
1286	1320		exec $LINUX32 /bin/bash
1287	1321
1288	1322		The ID of the current container is in the prompt. Exit it and commit to a new image, then start with a parameter to expose the SSH socket:
1289	1323
1290	1324		# exit
1291	1325
1292	1326		$ docker container commit 4efab4804fb6 debian_minimal
1293	1327
1294	1328		$ docker run -it -p 65022:22 \
1295	1329		--entrypoint=/etc/rc.local debian_minimal
1296	1330
1297	1331		# groupadd -g 1000 markMLl
1298	1332
1299	1333		# useradd -g markMLl -u 1000 -m -d /home/markMLl markMLl
1300	1334
1301	1335		# passwd markMLl
1302	1336
1303	1337		Add newly created user name to sudo group (/etc/group and /etc/gshadow files). Note the container ID, if it is now stopped the parameters are preserved and it should be possible to start it in the background and connect as the above user via SSH.
1304	1338
1305	1339		$ docker container stop c5be7fd96866
1306	1340
1307	1341		$ docker container start c5be7fd96866
1308	1342
1309	1343		$ ssh localhost -p 65022
1310	1344
1311	1345		The above is a good starting point for a general-purpose containerised system. The section below will also show how to get a graphical program (e.g. the Lazarus IDE) running in a container.
1312	1346
1313	1347		### A 32-bit Docker container with FPC and Lazarus
1314	1348
1315	1349		An understanding of the principles and commands described above is a prerequisite to continuing with this section.
1316	1350
1317	1351		Unlike Qemu, a container will run at the host computer's full speed. Unlike User Mode Linux (UML), a 32-bit container will run on a 64-bit host. Subject to security issues, this makes Docker the preferred choice when setting up a temporary 32-bit environment to e.g. investigate libraries which would not normally be installed on the host.
1318	1352
1319	1353		This section discusses installing a 32-bit Debian "Lenny" container, which allows a program to be checked with libraries etc. dating from roughly 2008.
1320	1354
1321	1355		Referring to <https://github.com/lpenz/docker-debian-releases/>
1322	1356
1323	1357		$ docker pull lpenz/debian-lenny-i386
1324	1358
1325	1359		$ docker image ls
1326	1360
1327	1361		$ docker run --interactive --tty lpenz/debian-lenny-i386
1328	1362
1329	1363		Lenny authentication is broken and is not going to be fixed (short of forking the entire repository). In /etc/apt/apt.conf put
1330	1364
1331	1365		APT
1332	1366		{
1333	1367		// Options for apt-get
1334	1368		Get
1335	1369		{
1336	1370		AllowUnauthenticated "true";
1337	1371		}
1338	1372		}
1339	1373
1340	1374		which should allow tasksel etc. to work. Add contrib and non-free to /etc/apt/sources.list, then
1341	1375
1342	1376		# apt-get update
1343	1377
1344	1378		# apt-get upgrade
1345	1379
1346	1380		# tasksel --new-install
1347	1381
1348	1382		# dpkg-reconfigure locales
1349	1383
1350	1384		# apt-get install openssh-server sudo
1351	1385
1352	1386		Populate /etc/rc.local as discussed above, comment out the temporary setting from /etc/apt/apt.conf
1353	1387
1354	1388		Create group and user as discussed above, add user to sudo group.
1355	1389
1356	1390		Add the build-essential, gdb, subversion and zip packages as basic prequisites. Add libncurses5-dev, libncursesw5-dev and libgpm-dev to allow FPC to be rebuilt, plus possibly libpango1.0-dev for the FP IDE. Install FPC v2.2.4 binary for i386 and corresponding sources, the compiler should run and be able to recompile itself.
1357	1391
1358	1392		Install the libgtk1.2-dev package then Lazarus 0.9.24.1, don't attempt to run it yet. In the per-user shell startup file e.g. ~/.bashrc put the line
1359	1393
1360		-	~~`export DISPLAY=:0`~~
	1394	+	```text
	1395	+	export DISPLAY=:0
	1396	+	```
1361	1397
1362	1398		then exit and commit the container as described above and restart with something like
1363	1399
1364		-	~~`$ docker run -it -p 65022:22 -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \`\~~
1365		-	~~` --entrypoint=/etc/rc.local lenny_with_lazarus`~~
	1400	+	```text
	1401	+	$ docker run -it -p 65022:22 -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
	1402	+	--entrypoint=/etc/rc.local lenny_with_lazarus
	1403	+	```
1366	1404
1367	1405		Again, details as discussed in the section above.
1368	1406
1369	1407		It should now be possible to login to the container from the host over SSH, invoke e.g. /usr/local/share/lazarus/lazarus by name, and have the IDE appear on the host computer's screen.
1370	1408
1371	1409		## Further Reading
1372	1410
1373	1411		- [Debian on an emulated ARM machine](http://www.aurel32.net/info/debian_arm_qemu.php)
1374	1412		- [Debian 11 on an emulated ARM/ARM64 machine](https://forum.lazarus.freepascal.org/index.php/topic,56098.msg420159.html#msg420159)
1375	1413		- [Debian on an emulated MIPS(EL) machine](http://www.aurel32.net/info/debian_mips_qemu.php)
1376	1414		- [QEMU/Windows XP on Wikibooks](http://en.wikibooks.org/wiki/QEMU/Windows_XP)
1377	1415		- [The User-mode Linux Kernel Home Page](http://user-mode-linux.sourceforge.net/)
1378	1416		- [Installing Debian under Hercules](http://www.josefsipek.net/docs/s390-linux/hercules-s390.html)
1379	1417
1380	1418		## See also
1381	1419
1382	1420		- [[Native ARM Systems]]
1383	1421		- [[Native MIPS Systems]]
1384	1422		- [[Small Virtual Machines]]
1385	1423		- [[Docker Containerization]]
1386	1424
1387	1425		---
1388	1426		From the Free Pascal wiki, page "Qemu and other emulators", as it stood on 2022-08-16 after a change by Skalogryz, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).
1389	1427		Category: Docker
1390	1428		Category: Emulators

Back to history