Qemu and other emulators: what changed

Revision 1 to 2. 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	50		` `[`http://ftp.de.debian.org/debian/dists/squeeze/main/`](http://ftp.de.debian.org/debian/dists/squeeze/main/)`...`
51	51
52	52		Fetch a kernel and initrd image for Debian Squeeze, as below.
53	53
54		-	~~<u>For ARM (little-endian):</u>~~
	54	+	For ARM (little-endian):
55	55
56	56		` .../main/installer-armel/current/images/versatile/netboot/vmlinux-2.6.32-5-versatile`\
57	57		` .../main/installer-armel/current/images/versatile/netboot/initrd.gz`
58	58
59	59		In addition for this architecture you also need:
60	60
61	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)
62	62
63		-	~~<u>For MIPS (little-endian):</u>~~
	63	+	For MIPS (little-endian):
64	64
65	65		`.../main/installer-mipsel/current/images/malta/netboot/vmlinux-2.6.32-5-4kc-malta`\
66	66		`.../main/installer-mipsel/current/images/malta/netboot/initrd.gz`
67	67
68	68		Copy these to the disc reserved for the guest, e.g. /export/mipsel.
69	69
70	70		Create a filesystem for Qemu, e.g.:
71	71
72	72		``` bash
73	73		# qemu-img create -f qcow mipsel_hda.img 16G
74	74		```
75	75
76	76		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	77
78		-	~~<u>For ARM (little-endian):</u>~~
	78	+	For ARM (little-endian):
79	79
80	80		``` bash
81	81		# qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.gz \
82	82		-hda armel_hda.img -append root=/dev/ram
83	83		```
84	84
85	85		Note that the above command requires X access, e.g. ssh with the -X option.
86	86
87		-	~~<u>For MIPS (little-endian):</u>~~
	87	+	For MIPS (little-endian):
88	88
89	89		``` bash
90	90		# qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta -initrd initrd.gz \
91	91		-hda mipsel_hda.img -append "root=/dev/ram console=ttyS0" -nographic
92	92		```
93	93
94	94		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	95
96	96		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	97
98	98		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	99
100		-	~~<u>For ARM (little-endian):</u>~~
	100	+	For ARM (little-endian):
101	101
102	102		``` bash
103	103		# qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile \
104	104		-initrd initrd.img-2.6.32-5-versatile -hda armel_hda.img -append "root=/dev/sda1"
105	105		```
106	106
107		-	~~<u>For MIPS (little-endian):</u>~~
	107	+	For MIPS (little-endian):
108	108
109	109		``` bash
110	110		# qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta \
111	111		-hda mipsel_hda.img -append "root=/dev/sda1 console=ttyS0" -nographic
112	112		```
113	113
114	114		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	115
116		-	~~<u>For ARM (little-endian):</u>~~
	116	+	For ARM (little-endian):
117	117
118	118		``` bash
119	119		# qemu-system-arm -M versatilepb -m 256 -hda armel_hda.img \
120	120		-kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile \
121	121		-append 'root=/dev/sda1 text' \
122	122		-net nic,macaddr=00:16:3e:00:00:01 -net tap,ifname=tun1
123	123		```
124	124
125		-	~~<u>For MIPS (little-endian):</u>~~
	125	+	For MIPS (little-endian):
126	126
127	127		``` bash
128	128		# qemu-system-mipsel -M malta -m 256 -hda mipsel_hda.img \
129	129		-kernel vmlinux-2.6.32-5-4kc-malta -no-reboot \
130	130		-append 'root=/dev/sda1 console=ttyS0' -nographic \
131	131		-net nic,macaddr=00:16:3e:00:00:02 -net tap,ifname=tun2
132	132		```
133	133
134	134		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	135
136	136		## Windows 2K Guest using Qemu
137	137
138	138		Use dd to save a .iso image of the installation CD. Create a filesystem image:
139	139
140	140		``` bash
141	141		# qemu-img create -f qcow2 win2k.img 32G
142	142		```
143	143
144	144		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	145
146	146		TODO: run with kernel support module.
147	147
148	148		## KVM on a Linux host
149	149
150	150		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	151
152	152		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	153
154	154		## Common Qemu startup, ifup and ifdown scripts
155	155
156	156		There is much commonality irrespective of whether the guest is running Linux or Windows.
157	157
158		-	~~<u>First startup script (e.g. /export/C):</u>~~
	158	+	First startup script (e.g. /export/C):
159	159
160	160		``` bash
161	161		#!/bin/sh
162	162
163	163		mount -L mipsel
164	164		cd /export/mipsel
165	165		. ./C-2
166	166		```
167	167
168		-	~~<u>Second startup script for ARM (little-endian):</u>~~
	168	+	Second startup script for ARM (little-endian):
169	169
170	170		``` bash
171	171		#!/bin/sh
172	172
173	173		# Routine startup of a Qemu guest relies on (the host) running /etc/qemu-ifup
174	174		# to condition ARP, forwarding etc.
175	175
176	176		QEMU_ID=1
177	177		QEMU='qemu-system-arm -M versatilepb'
178	178		QEMU_RAM='-m 256'
179	179		QEMU_HD='-hda armel_hda.img'
180	180		QEMU_CD=''
181	181		QEMU_BOOT="-kernel vmlinuz-2.6.32-5-versatile -append 'root=/dev/sda1 text' -initrd initrd.img-2.6.32-5-versatile"
182	182		# QEMU_MONITOR='-monitor stdio -nographic'
183	183		# QEMU_MONITOR='-nographic'
184	184		QEMU_VGA=''
185	185		VNC_ID=$(($QEMU_ID+1))
186	186		# QEMU_VNC="-vnc :$VNC_ID -k en-gb"
187	187		QEMU_VNC=''
188	188		QEMU_NET="-net nic,macaddr=00:16:3e:00:00:0$QEMU_ID -net tap,ifname=tun$QEMU_ID"
189	189		QEMU_GUEST_IP_ADDRESS=192.168.22.17
190	190		QEMU_GUEST_IP_GATEWAY=192.168.22.1
191	191		QEMU_HOST_GATEWAY_IF=eth1
192	192		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY_IF
193	193
194	194		echo * $QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
195	195		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
196	196
197	197		screen -S QEMU_$QEMU_ID \
198	198		sh -c "$QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
199	199		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC"
200	200
201	201		cd ..
202	202		```
203	203
204		-	~~<u>Second startup script for MIPS (little-endian):</u>~~
	204	+	Second startup script for MIPS (little-endian):
205	205
206	206		``` bash
207	207		#!/bin/sh
208	208
209	209		# Routine startup of a Qemu guest relies on (the host) running /etc/qemu-ifup
210	210		# to condition ARP, forwarding etc.
211	211
212	212		QEMU_ID=2
213	213		QEMU='qemu-system-mipsel -M malta'
214	214		QEMU_RAM='-m 256'
215	215		QEMU_HD='-hda mipsel_hda.img'
216	216		QEMU_CD=''
217	217		QEMU_BOOT="-kernel vmlinux-2.6.32-5-4kc-malta -append 'root=/dev/sda1 console=ttyS0' -no-reboot"
218	218		# QEMU_MONITOR='-monitor stdio -nographic'
219	219		QEMU_MONITOR='-nographic'
220	220		QEMU_VGA=''
221	221		VNC_ID=$(($QEMU_ID+1))
222	222		# QEMU_VNC="-vnc :$VNC_ID -k en-gb"
223	223		QEMU_VNC=''
224	224		QEMU_NET="-net nic,macaddr=00:16:3e:00:00:0$QEMU_ID -net tap,ifname=tun$QEMU_ID"
225	225		QEMU_GUEST_IP_ADDRESS=192.168.22.18
226	226		QEMU_GUEST_IP_GATEWAY=192.168.22.1
227	227		QEMU_HOST_GATEWAY_IF=eth1
228	228		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY_IF
229	229
230	230		echo * $QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
231	231		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
232	232
233	233		screen -S QEMU_$QEMU_ID \
234	234		sh -c "$QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
235	235		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC"
236	236
237	237		cd ..
238	238		```
239	239
240		-	~~<u>Second startup script for Windows:</u>~~
	240	+	Second startup script for Windows:
241	241
242	242		``` bash
243	243		#!/bin/sh
244	244
245	245		# Routine startup of a Qemu guest relies on (the host) running /etc/qemu-ifup
246	246		# to condition ARP, forwarding etc.
247	247
248	248		QEMU_ID=4
249	249		QEMU=qemu
250	250		QEMU_RAM='-m 256'
251	251		QEMU_HD='-hda win2k.img'
252	252		QEMU_CD='-cdrom Windows2k-SP4.iso'
253	253		QEMU_BOOT='-boot c'
254	254		QEMU_MONITOR='-monitor stdio'
255	255		QEMU_VGA='-vga cirrus'
256	256		VNC_ID=$(($QEMU_ID+1))
257	257		QEMU_VNC="-vnc :$VNC_ID -k en-gb"
258	258		QEMU_NET="-net nic,macaddr=00:16:3e:00:00:0$QEMU_ID,model=rtl8139 -net tap,ifname=tun$QEMU_ID"
259	259		QEMU_GUEST_IP_ADDRESS=192.168.22.20
260	260		QEMU_GUEST_IP_GATEWAY=192.168.22.1
261	261		QEMU_HOST_GATEWAY_IF=eth1
262	262		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY_IF
263	263
264	264		echo * $QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
265	265		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
266	266
267	267		screen -S QEMU_$QEMU_ID \
268	268		$QEMU $QEMU_RAM $QEMU_HD $QEMU_CD $QEMU_BOOT \
269	269		$QEMU_MONITOR $QEMU_VGA $QEMU_NET $QEMU_VNC
270	270
271	271		cd ..
272	272		```
273	273
274		-	~~<u>/etc/qemu-ifup (for both Linux and Windows):</u>~~
	274	+	/etc/qemu-ifup (for both Linux and Windows):
275	275
276	276		``` bash
277	277		#!/bin/bash
278	278
279	279		# if-up file for qemu, heavily cribbed from the command sequence embedded in
280	280		# User Mode Linux. MarkMLl.
281	281
282	282		echo Running /etc/qemu-ifup $1 $2...
283	283
284	284		# For compatibility with UML the only parameter here is $1 which is the
285	285		# interface name. I've put in a reference to $2 so we can see it if anything
286	286		# changes.
287	287
288	288		# I'm going to assume that qemu is always run by root. This is fairly
289	289		# reasonable since it allows guest OSes to be fired up which themselves might
290	290		# give access to confidential data etc. if compromised.
291	291
292	292		# Here's my equivalent to the host-side UML setup for Qemu. We're hamstrung
293	293		# here by the fact that the emulator is not telling us what IP address it's
294	294		# trying to enable, there isn't a 1:1 correspondence between IP addresses and
295	295		# interfaces since the latter depends on the order the sessions are started.
296	296		#
297	297		# As a hack, assume that the caller exports QEMU_GUEST_IP_ADDRESS (e.g.
298	298		# 192.168.17.16), QEMU_GUEST_IP_GATEWAY (e.g. 192.168.17.1) and
299	299		# QEMU_HOST_GATEWAY_IF (e.g. eth0).
300	300
301	301		echo * modprobe tun
302	302		modprobe tun
303	303
304	304		echo * ifconfig $1 $QEMU_GUEST_IP_GATEWAY netmask 255.255.255.255 up
305	305		ifconfig $1 $QEMU_GUEST_IP_GATEWAY netmask 255.255.255.255 up
306	306
307	307		X=`cat /proc/sys/net/ipv4/ip_forward`
308	308		if [ "$X" == "0" ]; then
309	309
310	310		# Use either this...
311	311
312	312		# echo Global forwarding is not enabled. Please refer to the administrator
313	313		# echo responsible for this machine, enabling it might be a security hazard.
314	314
315	315		# ...or this.
316	316
317	317		echo Forcibly enabling global forwarding, note that this might be a security hazard.
318	318		echo * echo 1 \> /proc/sys/net/ipv4/ip_forward
319	319		echo 1 > /proc/sys/net/ipv4/ip_forward
320	320		X=`cat /proc/sys/net/ipv4/ip_forward`
321	321		if [ "$X" == "0" ]; then
322	322		echo Unable to enable global forwarding. Please refer to the administrator
323	323		echo responsible for this machine.
324	324		fi
325	325		fi
326	326
327	327		echo * route add -host $QEMU_GUEST_IP_ADDRESS dev $1
328	328		route add -host $QEMU_GUEST_IP_ADDRESS dev $1
329	329
330	330		echo * echo 1 \> /proc/sys/net/ipv4/conf/$1/proxy_arp
331	331		echo 1 > /proc/sys/net/ipv4/conf/$1/proxy_arp
332	332		X=`cat /proc/sys/net/ipv4/conf/$1/proxy_arp`
333	333		if [ "$X" == "0" ]; then
334	334		echo -n Retrying
335	335		while [ "$X" == "0" ]; do
336	336		sleep 1
337	337		echo -n .
338	338		echo 1 > /proc/sys/net/ipv4/conf/$1/proxy_arp
339	339		X=`cat /proc/sys/net/ipv4/conf/$1/proxy_arp`
340	340		done
341	341		echo OK
342	342		fi
343	343
344	344		echo * arp -Ds $QEMU_GUEST_IP_ADDRESS $1 pub
345	345		arp -Ds $QEMU_GUEST_IP_ADDRESS $1 pub
346	346
347	347		echo * arp -Ds $QEMU_GUEST_IP_ADDRESS $QEMU_HOST_GATEWAY_IF pub
348	348		arp -Ds $QEMU_GUEST_IP_ADDRESS $QEMU_HOST_GATEWAY_IF pub
349	349
350	350		# Set up experimental UDP proxies. Depending on the protocol of interest
351	351		# messages in one or both directions might need to be relayed.
352	352		#
353	353		# UDP port 79 is used for Dialarm signals, a unidirectional proxy is
354	354		# adequate for this but detection of hosts changing state (i.e. being
355	355		# added to or removed from the population of cooperating systems) is far
356	356		# more responsive if a bidirectional proxy is available.
357	357
358	358		PROXY_ID=1
359	359		case "$1" in
360	360		tun1)
361	361		PROXY_ID=2
362	362		;;
363	363		tun2)
364	364		PROXY_ID=3
365	365		;;
366	366		tun3)
367	367		PROXY_ID=4
368	368		;;
369	369		tun4)
370	370		PROXY_ID=5
371	371		;;
372	372		tun5)
373	373		PROXY_ID=6
374	374		;;
375	375		tun6)
376	376		PROXY_ID=7
377	377		;;
378	378		tun7)
379	379		PROXY_ID=8
380	380		;;
381	381		esac
382	382
383	383		# echo * udp-broadcast-relay -f $PROXY_ID 79 $QEMU_HOST_GATEWAY_IF $1
384	384		# /usr/local/src/udp-broadcast-relay/udp-broadcast-relay-0.3/udp-broadcast-relay \
385	385		# -f $PROXY_ID 79 $QEMU_HOST_GATEWAY_IF $1
386	386
387	387		# Alternatively use this one which is oriented towards IP addresses
388	388		# rather than interfaces.
389	389
390	390		# Note attempt to counteract any niceness applied to Qemu itself.
391	391
392	392		ps ax \| grep 'udp-proxy[ ]-z 79 ' >/dev/null 2>&1
393	393		if [ $? != 0 ]; then
394	394		echo * udp-proxy -z 79 $QEMU_GUEST_IP_ADDRESS
395	395		/usr/bin/nice --adjustment=20 /usr/local/src/udp-proxy/udp-proxy -z 79 $QEMU_GUEST_IP_ADDRESS
396	396		else
397	397		echo * Already running udp-proxy -z 79 $QEMU_GUEST_IP_ADDRESS
398	398		fi
399	399
400	400		# echo * udp-proxy -z 13264 $QEMU_GUEST_IP_ADDRESS
401	401		# /usr/local/src/udp-proxy/udp-proxy -z 13264 $QEMU_GUEST_IP_ADDRESS
402	402
403	403		echo .../qemu/qemu-ifup completed.
404	404		```
405	405
406		-	~~<u>/etc/qemu-ifdown (for both Linux and Windows):</u>~~
	406	+	/etc/qemu-ifdown (for both Linux and Windows):
407	407
408	408		``` bash
409	409		#!/bin/sh
410	410
411	411		echo * route del -host $QEMU_GUEST_IP_ADDRESS dev $1
412	412		route del -host $QEMU_GUEST_IP_ADDRESS dev $1
413	413
414	414		echo * ifconfig $1 down
415	415		ifconfig $1 down
416	416		```
417	417
418	418		In actual fact, these operations were cribbed from User Mode Linux (below) where they are embedded inside a host library.
419	419
420	420		## Slackware x86 Guest using User Mode Linux
421	421
422	422		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	423
424	424		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	425
426	426		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	427
428	428		Boot the UML kernel, telling it to use the initrd image and DVD iso:
429	429
430	430		``` bash
431	431		# ./linux ubd0=initrd_unpacked ubd1=root_fs_slackware fake_ide ubd2r=slackware-13.37-install-dvd.iso rw
432	432		```
433	433
434	434		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	435
436	436		When complete start up like this:
437	437
438	438		``` bash
439	439		# Routine startup of a UML guest relies on (the host) running /usr/lib/uml/uml_net
440	440		# to condition ARP, forwarding etc.
441	441
442	442		echo * ./linux ubd0=initrd_unpacked ubd1=root_fs_slackware fake_ide ubd2r=slackware-13.37-install-dvd.iso \
443	443		root=/dev/ubdb1 eth0=tuntap,,,192.168.1.22
444	444
445	445		screen -S UML_3 \
446	446		./linux ubd0=initrd_unpacked ubd1=root_fs_slackware fake_ide ubd2r=slackware-13.37-install-dvd.iso \
447	447		root=/dev/ubdb1 eth0=tuntap,,,192.168.1.22
448	448
449	449		cd ..
450	450		```
451	451
452	452		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	453
454	454		## Debian 68k Guest using Aranym
455	455
456	456		``` bash
457	457		# apt-get install aranym
458	458		```
459	459
460	460		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	461
462	462		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	463
464	464		In aranym.config, change the ETH0 section to read:
465	465
466	466		`Type = ptp`\
467	467		`HostIP = 192.168.22.1`\
468	468		`AtariIP = 192.168.22.22`\
469	469		`Netmask = 255.255.255.0`
470	470
471	471		Change the startup script runaranym to read:
472	472
473	473		``` bash
474	474		#!/bin/sh
475	475
476	476		QEMU_GUEST_IP_ADDRESS=192.168.22.22
477	477		QEMU_GUEST_IP_GATEWAY=192.168.22.1
478	478		QEMU_HOST_GATEWAY=eth0
479	479		export QEMU_GUEST_IP_ADDRESS QEMU_GUEST_IP_GATEWAY QEMU_HOST_GATEWAY
480	480
481	481		/etc/qemu-ifup tap7
482	482
483	483		cd "$(dirname "$0")"
484	484		SDL_AUDIODRIVER=dummy; export SDL_AUDIODRIVER
485	485		aranym-mmu -l -c aranym.config
486	486
487	487		/etc/qemu-ifdown tap7
488	488		```
489	489
490	490		Uncompress the image file:
491	491
492	492		``` bash
493	493		# unxz dc11.img.xz
494	494		```
495	495
496	496		Using xterm on a graphical login, run the startup script:
497	497
498	498		``` bash
499	499		# runaranym
500	500		```
501	501
502	502		The result of that should be a console for the guest Debian system.
503	503
504	504		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	505
506	506		Then as described on <https://wiki.debian.org/Aranym/Quick> run the three commands:
507	507
508	508		``` bash
509	509		# dpkg-reconfigure openssh-server
510	510		# apt-get update
511	511		# apt-get install popularity-contest
512	512		```
513	513
514	514		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	515
516	516		## Debian zSeries Guest using Hercules, without VM
517	517
518	518		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	519
520	520		`ipl 120`
521	521
522	522		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	523
524	524		Refer to the URL in the script below for more details.
525	525
526	526		Startup:
527	527
528	528		``` bash
529	529		#!/bin/sh
530	530
531	531		# PREREQUISITE: Boot with ipl 120
532	532
533	533		# Note that this makes no attempt to support IPv6.
534	534
535	535		iptables -t nat -A POSTROUTING -o eth1 -s 192.168.22.0/24 -j MASQUERADE
536	536		iptables -A FORWARD -s 192.168.22.0/24 -j ACCEPT
537	537		iptables -A FORWARD -d 192.168.22.0/24 -j ACCEPT
538	538		echo 1 > /proc/sys/net/ipv4/ip_forward
539	539		echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
540	540
541	541		# http://www.josefsipek.net/docs/s390-linux/hercules-s390.html
542	542
543	543		screen -S HERC_5 \
544	544		hercules
545	545
546	546		cd ..
547	547		```
548	548
549	549		Configuration:
550	550
551	551		`CPUSERIAL 000069 # CPU serial number`\
552	552		`CPUMODEL 9672 # CPU model number`\
553	553		`MAINSIZE 256 # Main storage size in megabytes`\
554	554		`XPNDSIZE 0 # Expanded storage size in megabytes`\
555	555		`CNSLPORT 3270 # TCP port number to which consoles connect`\
556	556		`NUMCPU 2 # Number of CPUs`\
557	557		`LOADPARM 0120.... # IPL parameter`\
558	558		`OSTAILOR LINUX # OS tailoring`\
559	559		`PANRATE SLOW # Panel refresh rate (SLOW, FAST)`\
560	560		`ARCHMODE ESAME # Architecture mode ESA/390 or ESAME`\
561		-	\
	561	+
562	562		`# .-----------------------Device number`\
563	563		`# \| .-----------------Device type`\
564	564		`# \| \| .---------File name and parameters`\
565	565		`# \| \| \|`\
566	566		`# V V V`\
567	567		`#--- ---- --------------------`\
568		-	\
	568	+
569	569		`# console`\
570	570		`001F 3270`\
571		-	\
	571	+
572	572		`# terminal`\
573	573		`0009 3215`\
574		-	\
	574	+
575	575		`# reader`\
576	576		`000C 3505 /export/zlinux/rdr/kernel.debian /export/zlinux/rdr/parmfile.debian /export/zlinux/rdr/initrd.debian autopad eof`\
577		-	\
	577	+
578	578		`# printer`\
579	579		`000E 1403 /export/zlinux/prt/print00e.txt crlf`\
580		-	\
	580	+
581	581		`# dasd`\
582	582		`0120 3390 /export/zlinux/dasd/3390.LINUX.0120`\
583	583		`0121 3390 /export/zlinux/dasd/3390.LINUX.0121`\
584		-	\
	584	+
585	585		`# tape`\
586	586		`0581 3420`\
587		-	\
	587	+
588	588		`# network s390 realbox`\
589	589		`# 0A00,0A01 CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1`\
590	590		`0A00,0A01 CTCI -n /dev/net/tun -t 1500 192.168.22.21 192.168.1.22`
591	591
592	592		Note that the guest network is configured as SLIP via a simulated CTC (Channel To Channel) device. Best not fooled with.
593	593
594	594		## Debian zSeries Guest using Hercules, with VM
595	595
596	596		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	597
598	598		This means that it is not, for example, possible to run a VM host with simultaneous Linux and MUSIC/SP guests.
599	599
600	600		## MUSIC/SP using Sim/390 or Hercules
601	601
602	602		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	603
604	604		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	605
606	606		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	607
608	608		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	609
610	610		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	611
612	612		## VM/370 using Hercules
613	613
614	614		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	615
616	616		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	617
618	618		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	619
620	620		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	621
622	622		## IBM S/370, S/390, and the S/380 "hack"
623	623
624	624		This section is an even sketchier outline.
625	625
626	626		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	627
628	628		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	629
630	630		## IA-64 (Itanium, Merced, McKinley etc.)
631	631
632	632		Terminally sketchy.
633	633
634	634		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	635
636	636		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	637
638	638		(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	639
640	640		Assuming the disc image is a file named /export/ia-64/sda (e.g. renamed from the downloaded sda-debian) then
641	641
642	642		`bski bootloader vmlinux simscsi=/export/ia-64/sd`
643	643
644	644		Note the dropped final letter, that parameter is used as a prefix rather than being the name of a file or directory.
645	645
646	646		As with a number of other emulators described on this page, this requires an X session for the console.
647	647
648	648		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	649
650	650		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	651
652	652		------------------------------------------------------------------------
653	653
654	654		## Relative Performance
655	655
656	656		Performance is, in general, disappointing. Using an informal "torture test" which exercises the CPU and disc access:
657	657
658	658		`Compaq ProLiant ML530 G2, 2.8GHz, 3Gb, 8 jobs, 390W 0m12.170 79`\
659		-	\
	659	+
660	660		`Linksys NSLU2, 266MHz 32Mb, 1 job, 7W 6m35.014s 46`\
661		-	\
	661	+
662	662		`Qemu ARM, 1 job, 390W 42m58.925s 16,757`\
663		-	\
	663	+
664	664		`Qemu MIPS, 1 job, 390W 17m49.103s 6,949`\
665		-	\
	665	+
666	666		`Qemu x86, 1 job, 390W 47m0.441s 18,330`\
667		-	\
	667	+
668	668		`UML, 1 job, 390W 8m26.529s 3,289`\
669		-	\
	669	+
670	670		`Hercules zSeries, 4 jobs, 390W 9m43.330s 3,790`
671	671
672	672		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	673
674	674		Compiling FPC 2.4.2 using time make NOGDB=1 OPT='-O- -gl' all :
675	675
676	676		`Host (x86, Linux, Debian):`\
677		-	\
	677	+
678	678		` real 4m47.842s`\
679	679		` user 3m42.126s`\
680	680		` sys 0m33.506s`\
681		-	\
	681	+
682	682		`Slug (32Mb, ARM, Linux, Debian):`\
683		-	\
	683	+
684	684		` real 284m58.543s`\
685	685		` user 86m45.570s`\
686	686		` sys 20m46.500s`\
687		-	\
	687	+
688	688		`Qemu (ARM, Linux, Debian):`\
689		-	\
	689	+
690	690		` real 406m31.931s`\
691	691		` user 236m49.030s`\
692	692		` sys 148m58.110s`\
693		-	\
	693	+
694	694		`Qemu (x86, Linux, Slackware):`\
695		-	\
	695	+
696	696		` real 141m45.700s`\
697	697		` user 122m40.724s`\
698	698		` sys 17m15.670s`\
699		-	\
	699	+
700	700		`Qemu (x86, Windows 2000):`\
701		-	\
	701	+
702	702		` Elapsed 108m`\
703		-	\
	703	+
704	704		`UML (x86, Linux, Slackware):`\
705		-	\
	705	+
706	706		` real 238m41.257s`\
707	707		` user 45m54.460s`\
708	708		` sys 3m44.140s`
709	709
710	710		Compiling Lazarus 0.9.30 using time make LCL_PLATFORM=gtk2 bigide :
711	711
712	712		`Host (x86, Linux, Debian):`\
713		-	\
	713	+
714	714		` real 2m21.072s`\
715	715		` user 2m6.452s`\
716	716		` sys 0m12.285s`\
717		-	\
	717	+
718	718		`Slug (32Mb, ARM, Linux, Debian):`\
719		-	\
	719	+
720	720		` real 9385m49.319s`\
721	721		` user 67m23.460s`\
722	722		` sys 430m9.870s`\
723		-	\
	723	+
724	724		`Qemu (ARM, Linux, Debian):`\
725		-	\
	725	+
726	726		` real 281m55.536s`\
727	727		` user 153m3.150s`\
728	728		` sys 53m27.470s`\
729		-	\
	729	+
730	730		`Qemu (x86, Linux, Slackware):`\
731		-	\
	731	+
732	732		` real 70m53.957s`\
733	733		` user 60m3.474s`\
734	734		` sys 8m8.801s`\
735		-	\
	735	+
736	736		`Qemu (x86, Windows 2000, default platform):`\
737		-	\
	737	+
738	738		` Elapsed 53m`\
739		-	\
	739	+
740	740		`UML (x86, Linux, Slackware):`\
741		-	\
	741	+
742	742		` real 489m40.233s`\
743	743		` user 81m43.740s`\
744	744		` sys 7m51.280s`
745	745
746	746		## Graphical Access using VNC etc.
747	747
748	748		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	749
750	750		There are several ways of running a program using a GUI without forwarding the X protocol over SSH:
751	751
752	752		- Running Qemu or UML in an xterm.
753	753
754	754		- Using Qemu's host VNC support.
755	755
756	756		- Connecting to a Qemu (or UML etc.) guest using X.
757	757
758	758		- Connecting to a Qemu (or UML etc.) guest using VNC.
759	759
760	760		In all cases it is worth using a low-resource window manager such as FluxBox or xfwm rather than KDE or Gnome.
761	761
762	762		### Running Qemu or UML in an xterm or with host VNC support
763	763
764	764		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	765
766	766		### Connecting to a Qemu (or UML etc.) guest using X
767	767
768	768		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	769
770	770		### Connecting to a Qemu (or UML etc.) guest using VNC
771	771
772	772		This method also works well for arbitrary systems, even if Qemu etc. is not being used.
773	773
774	774		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	775
776	776		In /etc/inittab, insert something like this:
777	777
778	778		`6:23:respawn:/sbin/getty 38400 tty6`\
779		-	\
	779	+
780	780		`# Added in lieu of trying to get it working in inetd.conf. MarkMLl.`\
781		-	\
	781	+
782	782		`8:23:respawn:/usr/local/vnc/vncshim-0-20`\
783	783		`# 9:23:respawn:/usr/local/vnc/vncshim-4-24`\
784		-	\
	784	+
785	785		`# Example how to put a getty on a serial line (for a terminal)`\
786	786		`#`\
787	787		`#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100`
788	788
789	789		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	790
791	791		`[xdmcp]`\
792	792		`Enable=true`\
793	793		`DisplaysPerHost=6`
794	794
795	795		Create /usr/local/vnc/vncshim-0-20 to read:
796	796
797	797		``` bash
798	798		#!/bin/bash
799	799
800	800		# This forms a shim between /etc/inittab and the VNC server, necessitated by
801	801		# the facts that (a) I can't get this command working reliably in inetd.conf
802	802		# and (b) lines in initab have restricted length.
803	803		#
804	804		# Note that the name of the file reflects the fact that it might request non-
805	805		# standard combinations of VNC port and X display number. MarkMLl.
806	806
807	807		# My preference is to select default linear dimensions that appear somewhere
808	808		# in the list of conventional graphics modes. 1200x960 fits inside a 1280x1024
809	809		# screen, even allowing that the title bar etc. will take additional space.
810	810
811	811		SIZE=1200x960
812	812
813	813		# The DPI setting can usefully be set to match the user's normal screen, leave
814	814		# undefined (commented out) if in doubt.
815	815
816	816		DPI='-dpi 96'
817	817
818	818		# Each VNC server running on a host must have a distinct suffix to prevent port
819	819		# and display number clashes.
820	820
821	821		SUFFIX=0
822	822
823	823		# Some option formats vary between RealVNC (top) and TightVNC (bottom).
824	824
825	825		OPTIONS='DisconnectClients=0 -NeverShared'
826	826		# OPTIONS='-dontdisconnect -nevershared'
827	827
828	828		####################### CHANGE NOTHING BELOW HERE ###########################
829	829
830	830		VNCPORT=570$SUFFIX
831	831		XDISPLAY=:2$SUFFIX
832	832
833	833		# Try to work out what this system is. Note particular care to allow spaces
834	834		# in the desktop name.
835	835
836	836		WHATAMI=`dirname $0`/whatami
837	837		if [ -x $WHATAMI ]; then
838	838		WHATAMI2=`$WHATAMI`
839	839		else
840	840		if [ -r $WHATAMI ]; then
841	841		WHATAMI2=`cat $WHATAMI`
842	842		else
843	843		WHATAMI2=$$
844	844		fi
845	845		fi
846	846		DESKTOP='-desktop '\'$WHATAMI2\'
847	847
848	848		# Optional Java viewer.
849	849
850	850		if [ -r `dirname $0`/classes/index.vnc ]; then
851	851		JAVA="-httpd `dirname $0`/classes -httpPort 580$SUFFIX"
852	852		fi
853	853
854	854		# This is the only way I can get it working the way I want, i.e. with reliable
855	855		# handling of spaces in the desktop name. I'm hardly proud of it.
856	856
857	857		rm -f `dirname $0`/.vncshim-$SUFFIX-1$SUFFIX
858	858
859	859		cat >`dirname $0`/.vncshim-$SUFFIX-1$SUFFIX <<EOT
860	860		#!/bin/sh
861	861		exec /usr/bin/Xvnc -geometry $SIZE $DPI -depth 16 $DESKTOP \
862	862		-rfbport $VNCPORT -rfbauth /root/.vnc/passwd-$SUFFIX $JAVA \
863	863		$OPTIONS -query localhost -once $XDISPLAY
864	864		EOT
865	865
866	866		chmod +x `dirname $0`/.vncshim-$SUFFIX-1$SUFFIX
867	867		exec `dirname $0`/.vncshim-$SUFFIX-1$SUFFIX
868	868		```
869	869
870	870		Create /usr/local/vnc/whatami to read:
871	871
872	872		``` bash
873	873		#!/bin/bash
874	874
875	875		echo -n "`hostname`, "
876	876		_WHATAMI=`uname -m`
877	877		if [[ $_WHATAMI == i?86 ]]; then
878	878		_WHATAMI='i586'
879	879		fi
880	880		if [[ $_WHATAMI == arm* ]]; then
881	881		_WHATAMI='arm'
882	882		fi
883	883
884	884		if [ -x `dirname $0`/whatami-$_WHATAMI ]; then
885	885		`dirname $0`/whatami-$_WHATAMI
886	886		else
887	887		uname -m
888	888		fi
889	889		```
890	890
891	891		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	892
893	893		Use vncpasswd to set up password files /root/.vnc/passwd-0 etc.
894	894
895	895		So far, I find that RealVNC works fine when invoked as above, but TightVNC doesn't correctly invoke the display manager.
896	896
897	897		## Accessing "Unusual" Devices
898	898
899	899		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	900
901	901		### Sound/MIDI for Qemu
902	902
903	903		Don't expect this to be hi-fi quality, but it should be adequate for operator alerts etc.
904	904
905	905		#### Identifying the Host's Hardware
906	906
907	907		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	908
909	909		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	910
911	911		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	912
913	913		`$ qemu -audio-help \|grep ^Name:`\
914	914		`Name: alsa`\
915	915		`Name: oss`\
916	916		`Name: sdl`\
917	917		`Name: esd`\
918	918		`Name: pa`\
919	919		`Name: none`\
920	920		`Name: wav`
921	921
922	922		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	923
924	924		``` bash
925	925		export QEMU_AUDIO_DRV=oss
926	926		export QEMU_OSS_DAC_DEV=/dev/dsp1
927	927		export QEMU_OSS_ADC_DEV=/dev/dsp1
928	928		```
929	929
930	930		#### Selecting the Guest's Soundcard
931	931
932	932		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	933
934	934		``` bash
935	935		make clean distclean
936	936		./configure --audio-card-list=ac97,es1370,sb16,adlib
937	937		make
938	938		```
939	939
940	940		Irrespective of whether a custom Qemu is built or not, it's useful to check what devices it emulates:
941	941
942	942		``` bash
943	943		$ qemu -soundhw ?
944	944		Valid sound card names (comma separated):
945	945		pcspk PC speaker
946	946		sb16 Creative Sound Blaster 16
947	947		ac97 Intel 82801AA AC97 Audio
948	948		es1370 ENSONIQ AudioPCI ES1370
949	949		```
950	950
951	951		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	952
953	953		``` bash
954	954		$ qemu ... -soundhw sb16,adlib ...
955	955		```
956	956
957	957		In this case the guest uses only the standard Sound Blaster driver, possibly ignoring MPU-401 support.
958	958
959	959		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	960
961	961		``` bash
962	962		$ qemu ... -soundhw es1370 ...
963	963		```
964	964
965	965		Having started Qemu, it's possible to query the emulated devices:
966	966
967	967		`(qemu) info pci`\
968	968		`...`\
969	969		` Bus 0, device 4, function 0:`\
970	970		` Audio controller: PCI device 1274:5000`\
971	971		` IRQ 11.`\
972	972		` BAR0: I/O at 0xc200 [0xc2ff].`\
973	973		` id ""`
974	974
975	975		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	976
977	977		Anybody: need help here generalising this to other guest operating systems.
978	978
979	979		### USB for Qemu
980	980
981	981		As an example, a Velleman K8055 board is plugged into the host. First use lsusb to gets its vid:pid identifiers:
982	982
983	983		``` bash
984	984		$ lsusb
985	985		Bus 001 Device 005: ID 10cf:5500 Velleman Components, Inc. 8055 Experiment Interface Board (address=0)
986	986		```
987	987
988	988		Now add these parameters to the Qemu command line:
989	989
990	990		``` bash
991	991		qemu ... -usb -usbdevice host:10cf:5500 ...
992	992		```
993	993
994	994		On the guest, lsusb should show the device available for use.
995	995
996	996		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	997
998	998		``` bash
999	999		qemu ... -usb -usbdevice host:1.5 ...
1000	1000		```
1001	1001
1002	1002		Obviously, there's a risk here that devices will move around between invocations.
1003	1003
1004	1004		### USB for UML
1005	1005
1006	1006		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	1007
1008	1008		## QEMU User Emulation Mode in Chrooted Environment
1009	1009
1010	1010		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	1011
1012	1012		`$ qemu-arm program`
1013	1013
1014	1014		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	1015
1016	1016		- the chroot isolates the guest from the host
1017	1017		- no need for vnc, ssh or any other solution to export screens.
1018	1018		- no booting of a guest OS system.
1019	1019		- guest "immersion" for user programs is almost complete. Only very low level and hardware related programming will notice the difference.
1020	1020		- a spectacular speed improvement for graphics (X) related tasks (running lazarus f.e.)
1021	1021		- hard disk resources are common to host and guest. Host can read and modify "guest" files but not the other way around.
1022	1022
1023		-	~~<u>Setting up the system.</u>~~
	1023	+	Setting up the system.
1024	1024
1025	1025		For a better comprehension of what follows, here is the directory structure used in this how-to:
1026	1026
1027	1027		`home`\
1028	1028		` qemu`\
1029	1029		` arm-linux-user`\
1030	1030		` sparc-linux-user`\
1031	1031		` scripts `\
1032	1032		` disks // here are qemu images for the different systems emulated`\
1033	1033		` chroot`\
1034	1034		` mount `\
1035	1035		` arm // here we'll chroot the arm environment`\
1036	1036		` sparc `
1037	1037
1038	1038		Get and build the latest qemu
1039	1039
1040	1040		``` bash
1041	1041		$ cd
1042	1042		$ git clone git://git.savannah.nongnu.org/qemu.git qemu
1043	1043		$ cd qemu
1044	1044		```
1045	1045
1046	1046		Build all emulations (full system and user emulation mode, all processors)
1047	1047
1048	1048		``` bash
1049	1049		$ ./configure --static to build
1050	1050		```
1051	1051
1052	1052		or only the user emulations needed
1053	1053
1054	1054		``` bash
1055	1055		$ ./configure --static --target-list=sparc-linux-user,arm-linux-user
1056	1056
1057	1057		$ make clean all
1058	1058		```
1059	1059
1060	1060		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	1061
1062	1062		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	1063
1064	1064		Mount the QEMU image.
1065	1065
1066	1066		WARNING: do not mount a qemu image when the associated guest is running!
1067	1067
1068	1068		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	1069
1070	1070		``` bash
1071	1071		$ qemu-img convert disks/armel_hda.img -O raw disks/armel_hda.raw
1072	1072
1073	1073		$ cd chroot
1074	1074		$ su
1075	1075		# mount ../disks/armel_hda.raw mount -o loop,offset=32256
1076	1076		```
1077	1077
1078	1078		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	1079
1080	1080		``` bash
1081	1081		# fdisk -lu ../disks/armel_hda.raw
1082	1082		```
1083	1083
1084	1084		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	1085
1086	1086		Check if the correct partition is mounted:
1087	1087
1088	1088		``` bash
1089	1089		# ls mount
1090	1090		```
1091	1091
1092	1092		Copy the complete system
1093	1093
1094	1094		``` bash
1095	1095		# cp -r mount/* arm/
1096	1096		# umount mount
1097	1097		```
1098	1098
1099	1099		Copy the QEMU arm emulator to the arm directory
1100	1100
1101	1101		``` bash
1102	1102		# cd arm
1103	1103		# cp ../../arm-linux-user/qemu-arm usr/local/bin
1104	1104		```
1105	1105
1106	1106		Our "guest" system is complete. Since we are sharing our "host" devices and system, we need to mount a few special directories:
1107	1107
1108	1108		``` bash
1109	1109		# mount --bind /proc proc
1110	1110		# mount --bind /dev dev
1111	1111		# mount --bind /sys sys
1112	1112		# mount --bind /tmp tmp
1113	1113		```
1114	1114
1115	1115		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	1116
1117	1117		We are going to use the host network:
1118	1118
1119	1119		``` bash
1120	1120		# sudo cp /etc/resolv.conf etc
1121	1121		```
1122	1122
1123	1123		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	1124
1125	1125		``` bash
1126	1126		# ../../scripts/qemu-binfmt-conf.sh
1127	1127		```
1128	1128
1129	1129		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	1130
1131	1131		Launch the system:
1132	1132
1133	1133		``` bash
1134	1134		# chroot .
1135	1135		```
1136	1136
1137	1137		If all goes well:
1138	1138
1139	1139		``` bash
1140	1140		# uname -m
1141	1141		armv7l
1142	1142		```
1143	1143
1144	1144		Everything you do from here is in your "guest" system. To exit the "guest" system.
1145	1145
1146	1146		``` bash
1147	1147		# exit
1148	1148		```
1149	1149
1150	1150		And unmount the special directories.
1151	1151
1152	1152		``` bash
1153	1153		# umount proc
1154	1154		# umount dev
1155	1155		# umount sys
1156	1156		# umount tmp
1157	1157		```
1158	1158
1159		-	~~<u>Conclusion.</u>~~
	1159	+	Conclusion.
1160	1160
1161	1161		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	1162
1163	1163		``` bash
1164	1164		$ sudo chroot . /your/lazarus/dir/lazarus
1165	1165		```
1166	1166
1167	1167		To run the program compiled in lazarus, you can launch it from another "host" terminal:
1168	1168
1169	1169		``` bash
1170	1170		$ cd qemu/chroot/arm
1171	1171		$ sudo chroot . /your/program/dir/project
1172	1172		```
1173	1173
1174	1174		Here also gdb is not working.
1175	1175
1176	1176		## Docker images
1177	1177
1178	1178		Docker uses various APIs provided by the underlying operating system to isolate programs in separate namespaces.
1179	1179
1180	1180		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	1181
1182	1182		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	1183
1184	1184		*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	1185
1186	1186		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	1187
1188	1188		### Docker fundamentals
1189	1189
1190	1190		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	1191
1192	1192		- Host: the physical computer running e.g. Qemu (with or without KVM) or Docker.
1193	1193
1194	1194		- Guest: on a virtualised system (Qemu etc.), a completely separate memory space with its own kernel.
1195	1195
1196	1196		- 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	1197
1198	1198		Looking specifically at Docker:
1199	1199
1200	1200		- Dockerfile: a succinct description of what is to go into a Docker image.
1201	1201
1202	1202		- Image: the Docker analogue of a bootable filesystem, initially built with reference to a Dockerfile.
1203	1203
1204	1204		- Container: an image which has been run, whether or not it is currently running.
1205	1205
1206	1206		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	1207
1208	1208		- A container may be stopped and committed to an image.
1209	1209
1210	1210		- An image may be saved to a single file, in which state it can be moved between hosts.
1211	1211
1212	1212		- An image may be run a set of parameters different from those of the container committed to it.
1213	1213
1214	1214		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	1215
1216	1216		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	1217
1218	1218		$ docker search debian
1219	1219
1220	1220		$ wget -q https://registry.hub.docker.com/v1/repositories/debian/tags -O - \
1221	1221		\| sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' \| tr '}' '\n' \| awk -F: '{print $3}' \| grep buster
1222	1222
1223	1223		$ docker pull debian:buster
1224	1224
1225	1225		or alternatively (for the really hard to reach bits)
1226	1226
1227	1227		$ docker search vicamo
1228	1228
1229	1229		$ wget -q https://registry.hub.docker.com/v1/repositories/vicamo/debian/tags -O - \
1230	1230		\| sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' \| tr '}' '\n' \| awk -F: '{print $3}'
1231	1231
1232	1232		...
1233	1233		buster-i386
1234	1234		buster-i386-sbuild
1235	1235		buster-i386-slim
1236	1236		...
1237	1237
1238	1238		$ docker pull vicamo/debian:buster-i386-slim
1239	1239
1240	1240		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	1241
1242	1242		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	1243
1244	1244		### A 64-bit Docker container with basic utilities
1245	1245
1246	1246		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	1247
1248	1248		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	1249
1250	1250		$ docker pull debian:buster
1251	1251
1252	1252		$ docker run --interactive --tty debian:buster
1253	1253
1254	1254		# apt-get update
1255	1255
1256	1256		# apt-get install dialog tasksel python3
1257	1257
1258	1258		# tasksel --new-install
1259	1259
1260	1260		# dpkg-reconfigure locales
1261	1261
1262	1262		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	1263
1264	1264		# apt-get install net-tools elvis-tiny
1265	1265
1266	1266		So far there is no provision for starting the SSH daemon. Add or edit /etc/rc.local to contain
1267	1267
1268	1268		#!/bin/sh
1269	1269
1270	1270		rm -rf /tmp/*
1271	1271
1272	1272		# For cases where a 32-bit container is running (by implication on a 64-bit host), make
1273	1273		# sure that commands such as uname -a return consistent information to avoid breaking
1274	1274		# the traditional ./configure && make operation.
1275	1275
1276	1276		(file -L /bin/sh \| grep -q 'ELF 32-bit LSB')
1277	1277		if [ $? -eq 0 ] ; then
1278	1278		LINUX32=linux32
1279	1279		fi
1280	1280
1281	1281		cd /etc/init.d
1282	1282		$LINUX32 ./ssh start
1283	1283		# $LINUX32 ./openbsd-inetd start
1284	1284
1285	1285		cd
1286	1286		exec $LINUX32 /bin/bash
1287	1287
1288	1288		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	1289
1290	1290		# exit
1291	1291
1292	1292		$ docker container commit 4efab4804fb6 debian_minimal
1293	1293
1294	1294		$ docker run -it -p 65022:22 \
1295	1295		--entrypoint=/etc/rc.local debian_minimal
1296	1296
1297	1297		# groupadd -g 1000 markMLl
1298	1298
1299	1299		# useradd -g markMLl -u 1000 -m -d /home/markMLl markMLl
1300	1300
1301	1301		# passwd markMLl
1302	1302
1303	1303		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	1304
1305	1305		$ docker container stop c5be7fd96866
1306	1306
1307	1307		$ docker container start c5be7fd96866
1308	1308
1309	1309		$ ssh localhost -p 65022
1310	1310
1311	1311		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	1312
1313	1313		### A 32-bit Docker container with FPC and Lazarus
1314	1314
1315	1315		An understanding of the principles and commands described above is a prerequisite to continuing with this section.
1316	1316
1317	1317		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	1318
1319	1319		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	1320
1321	1321		Referring to <https://github.com/lpenz/docker-debian-releases/>
1322	1322
1323	1323		$ docker pull lpenz/debian-lenny-i386
1324	1324
1325	1325		$ docker image ls
1326	1326
1327	1327		$ docker run --interactive --tty lpenz/debian-lenny-i386
1328	1328
1329	1329		Lenny authentication is broken and is not going to be fixed (short of forking the entire repository). In /etc/apt/apt.conf put
1330	1330
1331	1331		APT
1332	1332		{
1333	1333		// Options for apt-get
1334	1334		Get
1335	1335		{
1336	1336		AllowUnauthenticated "true";
1337	1337		}
1338	1338		}
1339	1339
1340	1340		which should allow tasksel etc. to work. Add contrib and non-free to /etc/apt/sources.list, then
1341	1341
1342	1342		# apt-get update
1343	1343
1344	1344		# apt-get upgrade
1345	1345
1346	1346		# tasksel --new-install
1347	1347
1348	1348		# dpkg-reconfigure locales
1349	1349
1350	1350		# apt-get install openssh-server sudo
1351	1351
1352	1352		Populate /etc/rc.local as discussed above, comment out the temporary setting from /etc/apt/apt.conf
1353	1353
1354	1354		Create group and user as discussed above, add user to sudo group.
1355	1355
1356	1356		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	1357
1358	1358		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	1359
1360	1360		`export DISPLAY=:0`
1361	1361
1362	1362		then exit and commit the container as described above and restart with something like
1363	1363
1364	1364		`$ docker run -it -p 65022:22 -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \`\
1365	1365		` --entrypoint=/etc/rc.local lenny_with_lazarus`
1366	1366
1367	1367		Again, details as discussed in the section above.
1368	1368
1369	1369		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	1370
1371	1371		## Further Reading
1372	1372
1373	1373		- [Debian on an emulated ARM machine](http://www.aurel32.net/info/debian_arm_qemu.php)
1374	1374		- [Debian 11 on an emulated ARM/ARM64 machine](https://forum.lazarus.freepascal.org/index.php/topic,56098.msg420159.html#msg420159)
1375	1375		- [Debian on an emulated MIPS(EL) machine](http://www.aurel32.net/info/debian_mips_qemu.php)
1376	1376		- [QEMU/Windows XP on Wikibooks](http://en.wikibooks.org/wiki/QEMU/Windows_XP)
1377	1377		- [The User-mode Linux Kernel Home Page](http://user-mode-linux.sourceforge.net/)
1378	1378		- [Installing Debian under Hercules](http://www.josefsipek.net/docs/s390-linux/hercules-s390.html)
1379	1379
1380	1380		## See also
1381	1381
1382	1382		- [[Native ARM Systems]]
1383	1383		- [[Native MIPS Systems]]
1384	1384		- [[Small Virtual Machines]]
1385	1385		- [[Docker Containerization]]
1386	1386
1387	1387		---
1388	1388		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	1389		Category: Docker
1390	1390		Category: Emulators

Back to history