summaryrefslogtreecommitdiff
path: root/hurd/running/qemu.mdwn
blob: c5b2cf1c1d3eab5b06284f1fb04267c61e6390d5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
This page discusses things for [[Unix]] systems, there is a separate page for
[[Microsoft_Windows]] systems.


# Readily Available Images

To try out the Hurd you can use the image of the Debian GNU/Hurd: 

* [Official Debian GNU/Hurd QEMU image](http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz)

(!) Note that the following are unofficial images: they have been prepared by
volunteers and may not have been tested extensively.

<!--* [Disk image](http://www.numenor.art.pl/balrog/hurd/) with an installation of
  [[Debian_GNU/Hurd|running/debian]].-->

* [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) 
  with a short intro on translators. Just start it with 'qemu *disk_image.img*'. 
  It should work without any of the configuration below. If you want to know what you can do 
  with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when 
  you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]]

Also you can use qemu to easily try one of our [[Hurd_LiveCDs|hurd/running/live_cd/]]. 

<!--* [Announcement](http://lists.debian.org/debian-hurd/2007/09/msg00000.html) of  another image. - The link in the email doesn't work anymore, too old. //-->


# What is Needed to create a QEMU image

1. First thing is to install [[/QEMU]].
2. A [[grub]] boot disk for the floppy disk image needed for booting. The [0\.97 version](ftp://alpha.gnu.org/gnu/grub/grub-0.97-i386-pc.ext2fs) works fine. I downloaded it and renamed to `floppy.img`. Alternatively, the Debian grub-disk package (up till version 0.97-28) is fine as well.
3. You will need a [Debian/Hurd installation CD](http://www.debian.org/ports/hurd/hurd-cd). K16 works fine.

# KVM acceleration

If your machine supports hardware acceleration, you should really use the kvm variant of qemu, as it speeds things quite a lot. Note however that kvm tends to make assumptions when accelerating things in the linux kernel, you may need some -no-kvm-something option. At the moment in Debian you need to pass

    -no-kvm-irqchip

else IRQs may hang sooner or later.

# Installing Debian/Hurd with QEMU

First off you will need to create a disk image using `qemu-img`. I have set mine to 2 gigabytes, although you should be able to get away with less(Currently, the maximum disk image size one can create with QEMU is 4.5G).

    $ qemu-img create hd0.img 2G

Next you will want to start up QEMU and begin the installation process. The first time you run it you will want to use the `-boot d` option to boot off the cdrom.

    $ qemu -hda hd0.img -cdrom debian-K16-hurd-i386-CD1.iso -fda floppy.img  -boot d

Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. Once you have finished installing the base system select the reboot option as this will ensure the disk is properly un-mounted. When the Debian CD menu comes up again simply close QEMU.

Now run your image with floppy booting (`-boot a`) and finish the install (`./native-install` .. etc).
You'll want to add more memory or activate swap for `./native-install` or it will hang.
Starting qemu with `-m 512` worked for me.
Swap can be activated like this (replace hd0s2 with your swap partition):

    $ cd /dev/
    $ MAKEDEV hd0s2
    $ /hurd/mach-defpager
    $ swapon /dev/hd0s2

**Important:** Older versions on gnumach needed that the `-M isapc` was passed to qemu. This is not needed anymore.

Also see another text about how to [[gnu/create_an_image]] for the
[[GNU_system|gnu]].


# Transferring Files

## Mounting Disk Image on Host

You may wish to mount your disk image on your host system to transfer files. To do this you will first need to find the offset of the partition you wish to mount.

    # fdisk -ul hd0.img
    ...
    128 heads, 63 sectors/track, 0 cylinders, total 0 sectors
    Units = sectors of 1 * 512 = 512 bytes

       Device Boot      Start         End      Blocks   Id  System
    hd0.img1   *          63     3515903     1757920+  83  Linux
    hd0.img2         3515904     4193279      338688   82  Linux swap / Solaris

Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefor my offset is 32256.

    # mount -o loop,offset=32256 hd0.img /mnt/diskimage

## Having QEMU create *virtual FAT disk images*

[Manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25).

QEMU has a facility to create FAT file systems on-the-fly:

    qemu [...] -hdc fat:[somewhere]

The Hurd [[`fatfs`_translator|translator/fatfs]] currently is read-only, but
for testing executables (etc.) that is enough.  And it is much easier than
loop-mounting the file systems images.  (Also you don't need `root' rights.)

However, note that there is a bug in [[translator/fatfs]]: [[!GNU_Savannah_bug
25961]].


# Networking in QEMU

Some further notes about [[networking]] and home hints about
[[networking/sharing_files]].

## Internet Access

If you just want to access the internet from within QEMU, you can setup pfinet for QEMU's user-networking:

    # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
    # echo "nameserver 10.0.2.3" > /etc/resolv.conf

(See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.)

Outgoing internet connections should just work then.
Testing it can be difficult with a minimal installation,
but `apt-get update` should work after you have filled out
`/etc/apt/sources.list`.
After that you should be able to install other network packages,
but note that `ping` doesn't work with QEMU's user-networking stack.

If you want to connect from the host system to the Hurd system running in QEMU, you need to setup something more advanced, like bridged networking.


## Bridged Networking

### What is Needed

1. Your Linux kernel will need 802.1d Ethernet Bridging support and TUN/TAP device driver support.
2. You will need to install [bridge-utils](http://bridge.sourceforge.net).


### Setting Up the Host Bridge

You need to setup a bridge on the host first. This assumes `eth0` is down. I have modified my hosts network startup scripts to automatically setup a bridge, you may want to do this also.

    # brctl addbr br0
    # ifconfig eth0 0.0.0.0 promisc up
    # brctl addif br0 eth0

At this point you will need to setup `br0` as you would normally `eth0` (`dhcpcd br0` for example).

### The qemu-ifup Script

This script gets called when QEMU starts and will attach the tun device to the bridge. QEMU will look for this file at `/etc/qemu-ifup` and that is where I keep mine.

    #!/bin/sh
    sudo ifconfig $1 0.0.0.0 promisc up
    sudo brctl addif br0 $1


### Setting up the Network in the Hurd

Now it is time to start-up your QEMU Hurd system and get networking going in there.

**Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package.

    $ qemu -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap

Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network.

    # settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a xxx.xxx.xxx.xxx -g xxx.xxx.xxx.xxx -m xxx.xxx.xxx.xxx

That should do it! Do not forget to edit/update `/etc/resolv.conf` to get DNS working.


# Related Links

These are links that users may find helpful.

Debian [[debian/after_install]] -- good source of information pertaining to your
system after installation.

[[Image_for_L4]] -- a QEMU image for the Hurd/L4 project.

<http://eyeside.net/hurd/Hurd-on-QEMU.html>


# TODO

[[IRC]], #hurd, 2007-07-04.

    <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition (/dev/hda6) with qemu directly?
    <tschwinge> Don't dare to do that, please.
    <tschwinge> It will lead to inconsistencies.
    <tschwinge> Because the Linux kernel thinks that it has complete control over the disk, or something.
    <tschwinge> In theory you could run something like ``-hda /dev/hda'', having GRUB installed on there to offer you to boot your Hurd system from hda6 and that will even work, but then don't get the idea to stop qemu, mount that partition on your Linux system and restart qemu.  That's where I got lots of inconsistencies then, afterwards.
    <azeem-uni> it's probably the same problem as having that partition mounted, suspending to disk, booting into it in the Hurd, and resume Linux
    <neal> right
    <tschwinge> That's a different problem.
    <tschwinge> Then the partitoon is still mounted.
    <neal> no, I think it is basically the same problem
    <tschwinge> The file system stuff is cached in the kernel.
    <neal> you have data that has not been written to disk yet
    <tschwinge> Right.
    <neal> and neither is prepared for the resource to be shared
    <tschwinge> In the azeem-uni scenarion the data is on the file system layer and in my scenarion it's some disk block caching inside the Linux kernel, I guess.
    <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub to boot off /dev/hda6, that the rest of hda should be fine, right?
    <azeem-uni> maybe adding -snapshot makes it totally safe
    <neal> azeem: Should be fine.
    <tschwinge> Yes.

The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine.