diff options
authorThomas Schwinge <>2014-03-12 00:05:16 +0100
committerThomas Schwinge <>2014-03-12 00:05:16 +0100
commitefdbd8e0de4d781d53ffb7a5833220c37739a568 (patch)
parente74a8ccb8c2cf082e82f3acc797dce3c77649488 (diff)
QEMU multiboot.
4 files changed, 41 insertions, 348 deletions
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index 8c3209de..5a13a655 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -368,25 +368,33 @@ Once you have logged in as `root` run the `pfinet` translator with values that a
That should do it! Do not forget to edit/update `/etc/resolv.conf` to get DNS working.
-# QEMU Multiboot
+# <a name="multiboot">Multiboot</a>
-See [[open_issues/debugging_gnumach_startup_qemu_gdb#multiboot]].
See "Linux/Multiboot boot specific" section on QEMU manpage.
-Get for instance cdimage boot components
+Get the multiboot modules. Either extract them from the disk image, or,
- $ wget{gnumach.gz,initrd.gz,ext2fs.static,}
+ $ wget{gnumach.gz,ext2fs.static,}
-gnumach needs to be uncompressed
+Generally, these files need to correspond to the ones in the disk image, so
+don't forget to keep them up to date.
+The kernel image needs to be uncompressed (`gunzip gnumach.gz`), as otherwise
+you'll get told: *qemu: linux kernel too old to load a ram disk*.
+ $ qemu [...] \
+ > --kernel gnumach \
+ > --initrd \
+ > 'ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed device:hd0s1 $(task-create) $(task-resume)',\
+ > ' /hurd/exec $(exec-task=task-create)'
+Note that, contrary to [[GRUB]]'s configuration file, you don't specify
+"`argv[0]`" here, and it's fortunate that neither ext2fs nor exec need a comma
+on their command line...
+You can also use `--append [...]`, which will show up in `/proc/cmdline`.
- $ gunzip gnumach.gz
- $ sudo qemu-system-i386 -m 512 \
- --kernel gnumach \
- --initrd "\
- initrd.gz \$(ramdisk-create),\
- ext2fs.static --multiboot-command-line=\${kernel-command-line} --host-priv-port=\${host-port} --device-master-port=\${device-port} --exec-server-task=\${exec-task} -T typed gunzip:device:rd0 \$(task-create) \$(task-resume),\
- /hurd/exec \$(exec-task=task-create)" \
- <other_qemu_options>
# `qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000010010001e`
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
index ebbad1a4..26e0b770 100644
--- a/open_issues/arm_port.mdwn
+++ b/open_issues/arm_port.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -152,29 +153,13 @@ architecture.
<tschwinge> matty3269: I think that's better than starting on real
<braunr> tschwinge: you can use -kernel with a multiboot binary now
<braunr> tschwinge: and even creating iso images is so fast it's not any
- <tschwinge> braunr: Yeah, I thought so, but never checked this out --
- recently I saw in qemu --help's output some »multiboot« thing flashing
- by. :-)
- <braunr> i think it only supports 32-bits executables though
- <matty3269> braunr: Yeah, I just tried passing gnumach as the -kernel
- parameter to qemu, but it segged qemu :S
- <braunr> otherwise i'd be using it for x15
- <matty3269> qemu: fatal: Trying to execute code outside RAM or ROM at
- 0xc0100000
- <braunr> how much ram did you give qemu ?
- <matty3269> I used '-m 512'
- <braunr> hum, so the -kernel option doesn't correctly implement elf loading
- or something like that
- <braunr> anyway, i'm not sure how well building gnumach on a non-hurd
- system is supported
- <braunr> so you may want to simply develop inside your VM for the time
- being, and reboot
- <matty3269> doing an objdump of it seems fine...
- <braunr> ?
<braunr> ah, the gnumach executable is a correct elf image
- <braunr> that's not the point
<matty3269> Is there particular reason that mach is linked at 0xc0100000?
<matty3269> or is that where it is expected to be in VM>
<tschwinge> That's my understanding.
@@ -192,21 +177,6 @@ architecture.
<braunr> the .text section of linux on x86 actually starts at c1000000
(above 16 MiB, certainly to preserve as much dma-able memory since modern
machines now have a lot more)
- <tschwinge> Surely the GRUB multiboot loader is not that much used/tested?
- <braunr> unfortunately, no
- <braunr> matty3269: FYI, my kernel starts at 0xfff00000 :p
- <matty3269> braunr: hmm, you could be right, I know it's arround there
- someone
- <matty3269> somewhere*
- <matty3269> braunr: that's an interesting address :S
- <matty3269> braunr: is that the PA address of the kernel or the VA inside a
- process?
- <braunr> the VA
- <matty3269> hmm
- <braunr> it can't be a PA
- <braunr> such high addresses are normally device memory
- <braunr> but don't worry, i have good reasons to have chosen this address
- :)
<matty3269> so with gnumach, does the boot-up sequence use PIC until VM is
active and the kernel mapped to the linking address?
<braunr> no
@@ -217,37 +187,6 @@ architecture.
<braunr> and uses offsets when accessing data
<braunr> (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB)
<matty3269> hmm,
- <matty3269> gah, I need to learn x86
- <braunr> that would certainly help
- <matty3269> I've just had a look at boothdr.S; I presume that there must be
- something else that is executed before this to setup VM, switch to 32-bit
- more etc...?
- <matty3269> mode*
- <braunr> have a look at the multiboot specification
- <braunr> it sets protected mode
- <braunr> but not paging
- <braunr> (i mean, the boot loader does, before passing control to the
- kernel)
- <matty3269> Ah, I see
- <tschwinge> matty3269: Multiboot should be documented in the GRUB package.
- <matty3269> tschwinge: yep, got that, thanks
- <matty3269> hmm, I can't find any reference to CR0 in gnumach so paging
- must be enabled elsewhere
- <matty3269> oh wait, found it
- <braunr> $ git grep -i '\<cr0\>'
- <braunr> i386/i386/proc_reg.h, linux/dev/include/asm-i386/system.h
- <braunr> although i suspect only the first one is relevant to us :)
- <matty3269> Yeah, that seems to have the setup code for paging :)
- <matty3269> I'm still confused how it could run that without paging or PIC
- though
- <matty3269> I think I need to watch the boot sequence with qemu
- <braunr> it's a bit tricky
- <braunr> but actually simple
- <braunr> 00:44 < braunr> either special sections are linked at physical
- addresses
- <braunr> 00:44 < braunr> or it relies on the fact that all executable code
- uses near jumps
- <braunr> that's really all there is
<braunr> but you shouldn't worry about that i suppose, as the protocol
between the boot loader and an arm kernel will certainly not be the saem
<braunr> same*
diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
index a9743608..68a04bfb 100644
--- a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
+++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
@@ -133,17 +133,7 @@ License|/fdl]]."]]"""]]
# <a name="multiboot">Multiboot</a>
-See also discussion about *multiboot* on [[arm_port]].
-## IRC, freenode, #hurd, 2013-10-09
- <matlea01> I was just wondering - once gnumach is compiled and I have the
- gnumach elf, is that bootable? I.e. can I use something like
- "qemu-system-i386 -kernel gnumach"?
- <kilobug> matlea01: you need something with multiboot support (like grub)
- to provide the various bootstrap modules to the kernel
- <matlea01> Ah, I see
+See also [[hurd/running/qemu#multiboot]].
## IRC, freenode, #hurd, 2014-02-24
@@ -173,32 +163,3 @@ See also discussion about *multiboot* on [[arm_port]].
<nalaginrut> you may use gdb for that
<nalaginrut> for bochs, you don't have to use external debugger
<congzhang> thanks for explain
- <congzhang> does anyone succeed boot hurd with qemu multiboot boot
- function?
- <congzhang> with -kernel and -initrd command line parameter
- <nalaginrut> I boot it with grub, in qemu, it's fine. Then I moved to
- physical machine
- <congzhang> boot with grub work for me too
- <congzhang> I want to know whether it is possible to boot from qemu
- directly
- <congzhang> qemu can directly load kernel and hurd module for linux
- <congzhang> nalaginrut: can you help to test whether hurd-console service
- start will cause hurd black death?
- <nalaginrut> I know qemu can boot Linux without MBR, but I don't know if
- it's true for Hurd too
- <nalaginrut> congzhang: I'm busy for other works now ;-)
- <congzhang> ok, thks:)
- <youpi> qemu's multiboot options don't seem to allow providing
- ext2fs.static and, so I don't think it's possible
- <congzhang> I try to do this, because hurd hurd-console cause system to
- death very high frequency
- <youpi> (because qemu doesn't implement all of multiboot)
- <congzhang> qemu help show that's possible, -initrd support multi module
- and parameter
- <congzhang> en, I will check with them later
- <youpi> how do you pass parameters to modules?
- <youpi> ah, right, it's after the file name
- <youpi> well, then simply try to pass the kernel, and the two modules
- <youpi> with the same option as in the grub config templates
- <youpi> it's fortunate that neither ext2fs nor exec need a comma on their
- command line...
diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn
index 0992b0f3..cef16734 100644
--- a/open_issues/nightly_builds_deb_packages.mdwn
+++ b/open_issues/nightly_builds_deb_packages.mdwn
@@ -67,16 +67,16 @@ See also [[nightly_builds]].
<teythoon> there has been talk here the other day about using qemus
multiboot capabilities to directly boot the hurd
-[[debugging_gnumach_startup_qemu_gdb]], *Multiboot*
- <teythoon> i always wanted to try that out
- <pere> the jenkins rules to test the install uses --kernel, --initrd and
- --append in qemu to specify the preseed file. without a similar method
- to boot hurd, it will be hard to automate the test. rewriting the iso
- might be an option, but not a very nice one.
- <teythoon> i believe that it is possible to use those options to boot a
- hurd
- <teythoon> i'll report back to you
+For d-i purposes, you'll additionally need:
+ $ wget
+..., and to the `--initrd` option prepend `'initrd.gz $(ramdisk-create)',`
+before the `ext2fs.static`, and refer the latter to `gunzip:device:rd0` instead
+of `device:hd0s1`.
<pere> I tried adding an url= option to grub when booting the installer,
but it seem to be ignored.
<pere> perhaps the preseed udeb is missing, or the network support was
@@ -84,8 +84,6 @@ See also [[nightly_builds]].
<teythoon> uh, i don't know about that stuff, youpi creates the d-i images
<pere> ok. seem to me that the d-i images do not support preseeding at the
- <teythoon> pere: when i try to use qemus multiboot support to boot the
- hurd, qemu crashes :/
<teythoon> youpi: ^ did you succeed? if so, can you share how?
<pere> teythoon: nope, I concluded it didn't work, and left it to other to
fix. :)
@@ -112,158 +110,8 @@ See also [[nightly_builds]].
<pere> #debian-qa will understand. :)
-## IRC, OFTC, #debian-hurd, 2014-02-27
- <gg0> almost managed to multiboot
- <gg0> it gets stuck at "start ext2fs.static"
- <gg0> any idea?
- <teythoon_> multiboot what ?
- <pere> gg0: that sound like the race blocking boot some times.
- <teythoon_> no
- <teythoon_> that'd print more
- <gg0> teythoon: booting hurd with qemu without grub
- <teythoon> oh cool
- <teythoon> can you paste your qemu arguments somewhere ?
- <azeem> probably ext2fs.static got passed a wrong commandline?
- <gg0> they are the grub ones but gnumach needs to be uncompressed
- <gg0> otherwise qemu complains saying linux kernel is too old
- <teythoon> yes, i got past that one
- <teythoon> but my qemu keeps crashing
- <teythoon> can you please paste the command you used ?
- <gg0> "qemu: linux kernel too old to load a ram disk"
- <gg0> well, my fun level would really decrease :)
- <azeem> if you pasted the commands you used?
- <youpi> gg0: if it talks about "linux", it's not actually using multiboot
- <gg0> azeem: yep :)
- <gg0> youpi: i think it just can't distinguish, btw bt uncompressing it, it
- boots
- <youpi> gg0: well, "any idea?" means you are requesting help
- <youpi> but without pasting the line, we can't divine what can be going
- wrong
- <youpi> gg0: well, if it can't see that gnumach *can* handle multiboot
- modules, qemu is very broken
- <gg0> modules are all loaded, multiboot options seems working well
- <gg0> ie. -initrd "file1 arg=foo,file2"
- <azeem> arg=foo?
- <teythoon> fwiw, i tried
- kvm -m 256 \
- -kernel gnumach \
- -append 'gnumach root=device:hd0s1' \
- -initrd "0.master/hurd/ext2fs.static ext2fs \
- --multiboot-command-line='\${kernel-command-line}' \
- --host-priv-port='\${host-port}' \
- --device-master-port='\${device-port}' \
- --exec-server-task='\${exec-task}' -T typed device:hd0s1 \
- '\$(task-create)' '\$(task-resume)',\
- 0.master/lib/ exec /hurd/exec '\$(exec-task=task-create)'" \
- -drive 'file=/media/pool/hurd-tests/image.qcow2,cache=writeback' -snapshot
- <gg0>
- <gg0> azeem: pasted from man qemu
- <gg0> here screenshot ^
- <teythoon> is this the stock debian ext2fs.static ?
- <azeem> gg0: are the ext2fs.static arguments cutoff at
- "-exec-server-[...]"?
- <gg0> teythoon: yes, everything from last CD image
- <teythoon> which you copied to the host ?
- <gg0> azeem: as you can see just below --exec-server-task=3
- <gg0> teythoon: loop mounted, like jenkins does
- <teythoon> ok
- <teythoon> the early hurd bootstrap code is very delicate
- <teythoon> and often, the bootstrap just hangs with no indication why
- <teythoon> we won't even notice the rootfs or the exec server crashing for
- example
- <gg0> replace gnumach, initrd.gz, ext2fs.static, paths with yours:
- <gg0> --kernel gnumach --initrd "initrd.gz initrd
- \$(ramdisk-create),ext2fs.static ext2fs
- --multiboot-command-line=\${kernel-command-line}
- --host-priv-port=\${host-port} --device-master-port=\${device-port}
- --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
- \$(task-create) \$(task-resume), exec /hurd/exec
- \$(exec-task=task-create)"
- <teythoon> you are missing the kernel command line, no?
- <gg0> teythoon: afaiu it takes it at runtime from itself if any
- <gg0> if anyone passes --append
- <gg0> in pasted screenshot i pass desktop=lxde
- <gg0> need to pass something like gunzip:device:rd0? on cd image it doesn't
- pass anything
- <youpi> no, it's already passed to ext2fs in the multiboot command line
- <gg0> ok
- <gg0> -T typed
- <teythoon> i do not see any significant difference between your arguments
- and mine
- <teythoon> for me, kvm/qemu still crashes
- <teythoon> % kvm --version
- <teythoon> QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6, Debian),
- Copyright (c) 2003-2008 Fabrice Bellard
- <gg0> teythoon: i don't have any "'" :) and too many gnumach, one in append
- too
- <teythoon> yes
- <teythoon> but that shouldn't cause kvm to crash
- <gg0> oh
- <gg0> here QEMU emulator version 1.7.0 (Debian 1.7.0+dfsg-3)
- <gg0> jessie on amd64
- <gg0> seems quite older
- <teythoon> indeed
- <gg0> wheezy vs current jessie
- <teythoon> yes
- <gg0> teythoon: qemu 1.7.0 is on wheezy-backports
- <gg0> anyone tried to reproduce it?
-## IRC, freenode, #hurd, 2014-02-27
- <gg0> options to boot hurd with qemu multiboot:
- <gg0> 17:54 < gg0> replace gnumach, initrd.gz, ext2fs.static, paths
- with yours:
- <gg0> 17:54 < gg0> --kernel gnumach --initrd "initrd.gz initrd
- \$(ramdisk-create),ext2fs.static ext2fs
- --multiboot-command-line=\${kernel-command-line}
- --host-priv-port=\${host-port} --device-master-port=\${device-port}
- --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
- \$(task-create) \$(task-resume), exec /hurd/exec
- \$(exec-task=task-create)"
- <gg0> gnumach needs to be uncompressed
- <gg0> this gets stuck at "start ext2fs.static:"
- <teythoon> indeed, same for me
- <braunr> i strongly suspect qemu multiboot support to be incomplete
- <braunr> i couldn't make it work well enough with x15 either
- <gg0> if gnumach is compressed, "qemu: linux kernel too old to load a ram
- disk"
- <braunr> i think that's a grub specific feature
-## IRC, freenode, #hurd, 2014-02-28
- <gg0> start ext2fs.static2: ext2fs: device:rd0: panic: get_hypermetadata:
- bad magic number 0xd7f0 (should be 0xef53)
- <gg0> \o/ it boots
- <teythoon> gg0: what was wrong ?
- <gg0> --kernel /path/to/uncompressed-gnumach --initrd "/path/to/initrd.gz
- \$(ramdisk-create),/path/to/ext2fs.static
- --multiboot-command-line=\${kernel-command-line}
- --host-priv-port=\${host-port} --device-master-port=\${device-port}
- --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
- \$(task-create) \$(task-resume),/path/to/ /hurd/exec
- \$(exec-task=task-create)"
- <teythoon> gg0: uh, using absolute paths fixes this ?
- <gg0> teythoon: not necessary, just to be clearer
- <gg0> solved by removing initrd between initrd.gz and ramdisk-create, and
- ext2fs between ext2fs.static and multiboot-command-line
- <gg0> also exec between and /hurd/exec
- <teythoon> gg0: oh, i see
## IRC, OFTC, #debian-hurd, 2014-02-28
- <gg0> --kernel /path/to/uncompressed-gnumach --initrd "/path/to/initrd.gz
- \$(ramdisk-create),/path/to/ext2fs.static
- --multiboot-command-line=\${kernel-command-line}
- --host-priv-port=\${host-port} --device-master-port=\${device-port}
- --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
- \$(task-create) \$(task-resume),/path/to/ /hurd/exec
- \$(exec-task=task-create)"
- <gg0> multiboot works
- <pere> cool.
<pere> gg0: are you able to feed the installer one of the preseed files at
<URL: >?
<gg0> though jenking translates double quotes, need to escape the world
@@ -271,7 +119,6 @@ See also [[nightly_builds]].
<gg0> pere: i'm working on that, stuck at working around that mandatory
double quote
<gg0> *initrd double quote
- <youpi> gg0: could you paste your command line on the hurd wiki?
<gg0> ok got a g-i-installation_debian_sid_daily_hurd_lxde able to boot
<gg0> let's provide a preseed
<gg0> shouldn't there be some info/debug consoles from tty 2 to 4?
@@ -321,10 +168,6 @@ See also [[nightly_builds]].
## IRC, OFTC, #debian-hurd, 2014-03-02
- <gg0> teythoon: curiosity, correct qemu multiboot options still make old
- qemu crashing?
- <teythoon> gg0: no idea, i'll try it later
<gg0> youpi: any chance to have monthly/weekly (daily would be too much i
guess) isos/images? can i help somehow?
<youpi> I am wondering why having that
@@ -619,31 +462,11 @@ See also [[nightly_builds]].
<youpi> possibly
<gg0> oh wait here qemu multiboot
<youpi> that shouldn't have any impact
- <youpi> did you leave the command line somewhere on the wiki so I can try
- with it, just to be sure?
- <gg0>
<gg0> 5€ on qemu multiboot as the culprit
<gg0> you should also see it sometimes double-mounts /dev/hd0s1 under
/target and /target/./media/cdrom(!)
<gg0> but that's due to new apt it in-targets (= installs under /target)
- <youpi> gg0: rather use the gnumach, and ext2fs.static from the ISO
- image you are booting
- <youpi> especially for, which has to be the same as the libc
- installed in the initrd
- <youpi> ah, you're getting the initrd there too
- <youpi> well, really use the same as the ISO
- <gg0> i already do
- <youpi> ah, ok, so the wiki example is just with current
- <youpi> but the wiki example doesn't use -cdrom to provide the ISO ?
- <gg0> no it doesn't even mention you could also use a cdrom
- <gg0> it just shows how to use qemu multiboot options
- <youpi> it seems one have to avoid any blanks in the multiboot option
- <youpi> notably before file names
- <gg0> well, actually it works but it's rather incomplete
- <youpi> well, it shows how to boot the installer
- <youpi> not how to boot an installed system
- <gg0> removed spaces, added <other_qemu_options> option
<gg0> any luck reproducing mtab issue?
<youpi> still not
@@ -781,7 +604,7 @@ See also [[nightly_builds]].
Resource lost
<gg0> didn't manage to reproduce so far
<gg0> environment is pretty the same: booting with qemu multiboot
<gg0> so root on initrd + chroot on real disk
<gg0> what's weird is that issue vanishes by removing console=com0 from
-append options
@@ -820,19 +643,14 @@ See also [[nightly_builds]].
zero everytime
<youpi> first thing to do when developping is first take the time to find
ways to work efficiently
- <gg0> i'd want to try multiboot with teythoon's gnumach/hurd but boot gets
- stuck with old initrd
<youpi> unfortunately I had to apply some patches
<youpi> first in d-i because isc-dhcp doens't work -> use the debian-ports
- <gg0> so i could simply copying whole /hurd dir to new initrd
- <gg0> -ing
<youpi> then in d-i to automatically enable the debian-ports mirror
<youpi> and last in the debian-cd to include debian-ports-archive-keyring
- <youpi> you'd also need to copy the libs
<gg0> anything missing here?
- <gg0> libc0.3 on initrd is still 2.17
<gg0> mini.iso doesn't like any mirror
<gg0> "mirror does not support the specified release"
<gg0> something wrong/missing in my rebuilt
@@ -862,22 +680,6 @@ See also [[nightly_builds]].
## IRC, freenode, #hurd, 2014-03-09
- <gg0>
- <gg0> with teythoon's repo too ^
-## IRC, OFTC, #debian-hurd, 2014-03-09
- <gg0> ok i'm out of tests, i get Resource lost with teythoon's gnumach/hurd
- packages in initrd too
- <gg0>
- <gg0> thread storms, dead locks, resource lost
- <gg0> i find assonance
-## IRC, freenode, #hurd, 2014-03-09
- <teythoon> gg0: strange
<gg0> teythoon: shouldn't there be a patch which shows pid instead of task?
<gg0> 20:43 < teythoon> task /hurd/procfs(19) <EF><BF><BD>O<EF><BF><BD>
deallocating an invalid port 1049744, most probably a bug.
@@ -939,23 +741,6 @@ See also [[nightly_builds]].
<gg0> #1 SMP Debian 3.11.10-1 (2013-12-04)
-## IRC, freenode, #hurd, 2014-03-10
- <gg0> teythoon: err, i had unpacked your packages to initrd but
- gnumach/ext2fs.static i was using for multiboot were debian ones
- <gg0> now with yours by reading system /proc/mounts (not chroot one) i get
- read error: (ipc/mig) bad request message ID
- <gg0> mixing up things
- <teythoon> gg0: yes, that is to be expected. the message ids for the
- relevant rpcs changed "recently". i'm really sorry about that.
- <teythoon> but in general, you should use the hurd components from one
- source together
- <teythoon> gg0: yes, that is to be expected. the message ids for the
- relevant rpcs changed "recently". i'm really sorry about that.
- <teythoon> but in general, you should use the hurd components from one
- source together
## IRC, OFTC, #debian-hurd, 2014-03-10
<gg0> tschwinge: i just meant Debian Jenkins provides (hopefully for hurd