[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
I'd be quite helpful to have nightly builds in form of Debian `.deb`
packages.
* (german)
* Need to have an automation to get from Hurd upstream Git branches to
a branch usable in Debian.
IRC, freenode, #hurd, 2013-12-18:
http://darnassus.sceen.net/~teythoon/hurd-ci/ has hurd and
mig and gnumach packages built directly from the upstream git
repository
---
There is infrastructure available to test whole OS installations.
*
---
[[Debian_Cross_Toolchain]] for cross-building?
---
See also [[nightly_builds]].
# Debian Jenkins Instance
## IRC, OFTC, #debian-hurd, 2014-02-24
hi. can hurd be installed using d-i? If so, what about scripting
the installation on ?
pere: d-i works for Hurd, yes, with full graphical interface I
dunno. Maybe you can ask about scripting in #hurd, more people are
present there?
gnu_srs: the scripts in questions are for jenkins. quite easy to
write (d-i preseed scripts and qemu boot rules).
## IRC, OFTC, #debian-hurd, 2014-02-25
getting a automated test in jenkins running could show the status.
what is needed to boot the hurd d-i image with a preseed file using qemu?
git://git.debian.org/git/users/holger/jenkins.debian.net.git is the
repo with the jenkins build rules.
youpi: is it possible to start the hurd d-i installer with a preseed
file from the qemu command line? --append need --kernel, which I suspect
do not make sense with hurd?
can the d-i hurd installer take a preseed file at all? my initial
try failed. :(
i don't know
there has been talk here the other day about using qemus
multiboot capabilities to directly boot the hurd
[[debugging_gnumach_startup_qemu_gdb]], *Multiboot*
i always wanted to try that out
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.
i believe that it is possible to use those options to boot a
hurd
i'll report back to you
I tried adding an url= option to grub when booting the installer,
but it seem to be ignored.
perhaps the preseed udeb is missing, or the network support was
enabled after preseed looked for the file?
uh, i don't know about that stuff, youpi creates the d-i images
ok. seem to me that the d-i images do not support preseeding at the
moment.
pere: when i try to use qemus multiboot support to boot the
hurd, qemu crashes :/
youpi: ^ did you succeed? if so, can you share how?
teythoon: nope, I concluded it didn't work, and left it to other to
fix. :)
pere, teythoon: IIRC preseeding can be put on the gnumach kernel
command line
but I'm wondering why you can't simply modify the disk image into
doing what you want
or you mean reinstalling the image each time?
youpi: the point is testing the installer, and that can only be done
by using the installer. :)
ok
I would like to see something like for hurd.
## IRC, OFTC, #debian-hurd, 2014-02-26
* gg0 setting up jenkins, almost time to give up
gg0: why do you set up jenkins?
because i want to fail at doing all things, not just something ;)
oops seems my setup just sent emails to jenkins+debian-qa
holger@layer-acht.org :/
#debian-qa will understand. :)
## IRC, OFTC, #debian-hurd, 2014-02-27
almost managed to multiboot
it gets stuck at "start ext2fs.static"
any idea?
multiboot what ?
gg0: that sound like the race blocking boot some times.
no
that'd print more
teythoon: booting hurd with qemu without grub
oh cool
can you paste your qemu arguments somewhere ?
probably ext2fs.static got passed a wrong commandline?
they are the grub ones but gnumach needs to be uncompressed
otherwise qemu complains saying linux kernel is too old
yes, i got past that one
but my qemu keeps crashing
can you please paste the command you used ?
"qemu: linux kernel too old to load a ram disk"
well, my fun level would really decrease :)
if you pasted the commands you used?
gg0: if it talks about "linux", it's not actually using multiboot
azeem: yep :)
youpi: i think it just can't distinguish, btw bt uncompressing it, it
boots
gg0: well, "any idea?" means you are requesting help
but without pasting the line, we can't divine what can be going
wrong
gg0: well, if it can't see that gnumach *can* handle multiboot
modules, qemu is very broken
modules are all loaded, multiboot options seems working well
ie. -initrd "file1 arg=foo,file2"
arg=foo?
fwiw, i tried http://paste.debian.net/84408/
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/ld.so.1 exec /hurd/exec '\$(exec-task=task-create)'" \
-drive 'file=/media/pool/hurd-tests/image.qcow2,cache=writeback' -snapshot
http://postimg.org/image/esywbywh9/
azeem: pasted from man qemu
here screenshot ^
is this the stock debian ext2fs.static ?
gg0: are the ext2fs.static arguments cutoff at
"-exec-server-[...]"?
teythoon: yes, everything from last CD image
which you copied to the host ?
azeem: as you can see just below --exec-server-task=3
teythoon: loop mounted, like jenkins does
ok
the early hurd bootstrap code is very delicate
and often, the bootstrap just hangs with no indication why
we won't even notice the rootfs or the exec server crashing for
example
replace gnumach, initrd.gz, ext2fs.static, ld.so.1 paths with yours:
--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),ld.so.1 exec /hurd/exec
\$(exec-task=task-create)"
you are missing the kernel command line, no?
teythoon: afaiu it takes it at runtime from itself if any
if anyone passes --append
in pasted screenshot i pass desktop=lxde
need to pass something like gunzip:device:rd0? on cd image it doesn't
pass anything
no, it's already passed to ext2fs in the multiboot command line
ok
-T typed
i do not see any significant difference between your arguments
and mine
for me, kvm/qemu still crashes
% kvm --version
QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6, Debian),
Copyright (c) 2003-2008 Fabrice Bellard
teythoon: i don't have any "'" :) and too many gnumach, one in append
too
yes
but that shouldn't cause kvm to crash
oh
here QEMU emulator version 1.7.0 (Debian 1.7.0+dfsg-3)
jessie on amd64
seems quite older
indeed
wheezy vs current jessie
yes
teythoon: qemu 1.7.0 is on wheezy-backports
anyone tried to reproduce it?
## IRC, freenode, #hurd, 2014-02-27
options to boot hurd with qemu multiboot:
17:54 < gg0> replace gnumach, initrd.gz, ext2fs.static, ld.so.1 paths
with yours:
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),ld.so.1 exec /hurd/exec
\$(exec-task=task-create)"
gnumach needs to be uncompressed
this gets stuck at "start ext2fs.static:"
indeed, same for me
i strongly suspect qemu multiboot support to be incomplete
i couldn't make it work well enough with x15 either
if gnumach is compressed, "qemu: linux kernel too old to load a ram
disk"
i think that's a grub specific feature
## IRC, freenode, #hurd, 2014-02-28
start ext2fs.static2: ext2fs: device:rd0: panic: get_hypermetadata:
bad magic number 0xd7f0 (should be 0xef53)
\o/ it boots
gg0: what was wrong ?
--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/ld.so.1 /hurd/exec
\$(exec-task=task-create)"
gg0: uh, using absolute paths fixes this ?
teythoon: not necessary, just to be clearer
solved by removing initrd between initrd.gz and ramdisk-create, and
ext2fs between ext2fs.static and multiboot-command-line
also exec between ld.so.1 and /hurd/exec
gg0: oh, i see
## IRC, OFTC, #debian-hurd, 2014-02-28
--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/ld.so.1 /hurd/exec
\$(exec-task=task-create)"
multiboot works
cool.
gg0: are you able to feed the installer one of the preseed files at
?
though jenking translates double quotes, need to escape the world
debian_sid_daily_lxde_preseed.cfg seem like a good candiate. :)
pere: i'm working on that, stuck at working around that mandatory
double quote
*initrd double quote
gg0: could you paste your command line on the hurd wiki?
ok got a g-i-installation_debian_sid_daily_hurd_lxde able to boot
let's provide a preseed
shouldn't there be some info/debug consoles from tty 2 to 4?
there should be
maybe i can't send alt+NUM from vlc
ah, yes
you need to use the menu for that
press f8
great
(found out C+A+{1,2,3} give interesting monitor,serial,parallel
consoles btw)
not much options on menu
just clipboard management, quit, full screen, send ctrl-alt-del, send
F8
* gg0 takes "great" back
i guess it depends on vnc implementation
don't ask me how i found out one can switch console with
... left/right arrow keys
without alt pressed?
without alt pressed
I've already seen that with qemu, when focusing into/out from the
qemu window by using alt
somehow the alt state gets stuck
so you mean if i close viewer then reattach it, it doesn't happen
anymore? let's see
you're right
though yes alt+left/right switches consoles
the last is expected :)
it says kbd-udeb doesn't exist so it falls back to
hurd-debian-ports-udeb
that's not a problem
no partman-auto?
it should be working
i meant if it was installed but yes it gets it along with others
## IRC, OFTC, #debian-hurd, 2014-03-01
partman-auto would need to be patched to be able to discover
available disks
worked around by forcing /dev/hd1, jenkins creates disk with index=1
stuck at installation-report installed. seems it can't manage to
umount(then remount) /cdrom gracefully
or better it gets stuck at apt-cdrom ident
something like https://bugs.debian.org/598457
## IRC, OFTC, #debian-hurd, 2014-03-02
teythoon: curiosity, correct qemu multiboot options still make old
qemu crashing?
gg0: no idea, i'll try it later
youpi: any chance to have monthly/weekly (daily would be too much i
guess) isos/images? can i help somehow?
I am wondering why having that
since we have up-to-date mirrors
i'd say to install with latest installer/gnumach/hurd/eglibc
so that means also rebuilding the d-i image
and in general to not have to manually produce them
youpi: the point is to automatically test the current images using
jenkins.debian.net, I believe. for that to work, current images need to
exist. :)
not only. i think saving youpi's time is also important
gg0: it doesn't really take me much time to generate images
it's about a few command lines to start, and then work on something
else :)
well though it still requires manual intervention which is not
scheduled and also error prone btw
gg0: I guess the most important help you could provide would be to
actually track when the autobuild breaks :)
what pros keeping it manual? i don't think disk space saving
it's not really a question of manual, but the frequency
I prefer to test manually before uploading something on my
somehow-official directory on people, anyway
but that doesn't mean we can't have weekly builds somewhere else
indeed
it's just that for tests it's good to have several images backlog,
but then it takes disk
well we could keeping "official" ones + say 6 monthly and say 4
weekly
* gg0 randomizes retention
-ing
gg0: check out my hurdtest program
it updates qemu images automatically, and runs a test suite,
creates snapshots
youpi: you'd just take actually care of official ones
and it can zero-fill the disk images to compact them for
publication
gg0: and have a cron for the others
on mirror.ftp-master
nice, we already have a disk image generator then
i shall clean it up and merge stuff that i have changed locally
i covered it in my early blog posts
i use it extensively to test the packages from hurd-ci
great. so usually at this point /me can't do anything so good work!
lol
crontabs are in place, scheduled on monday mornings
I have already completed a run, can be seen in weekly-0
great!
assuming it will work forever without maintenance, how many minutes
you'll save per month? :)
I don't think that'll save me time per month
since it's just an additional thing
youpi: so weekly-0 will always be the latest weekly (same about
monthly) ?
yes
how about adding -YYYYMMDD after -1 CD/DVD/NETINST number?
that'd mean more scripting
just to distinguish them
we already have timestamps from the server
unfortunately i can't script myself, i can suggest though :)
or scripts are available somewhere?
so current/ should be a link to weekly-0?
on mirror.ftp-master.debian.org, but I guess you don't have access
to it
no
definitely no
the point of current/ is to have something tested
ok
while weekly/monthly are most probably to get broken
so let's not point people at that
same story about diskimage? how do you generate them?
how about teythoon's way?
I do it by hand at the moment, but scripts would be welcome indeed
http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.txt
ok now stuck at grub install
## IRC, OFTC, #debian-hurd, 2014-03-03
i probably should force /dev/hd0 as i did for /dev/hd0s1 as root
device
if it's possible
what do you mean by forcing /dev/hd0s1 as root device ?
you shouldn't have to do that
my fear is that these additional images will mostly just bring
additionnal reports
i had to specify it in preseed
which won't really decrease the amount of work
as partman-auto/disk
it can recognize available disks
that's also because it can't list root partitions on rescue mode
well, all I can say without having (again) to spend time on it, is
that you're not supposed to have to do that
why are you using rescue mode?
if it can't list root partitions, then of course partman can't work
well, rescue mode should work
if you delve into non-tested parts of d-i, you'll surely encounter
bugs
well, less "should" than plain "d-i"
in that I've never really tested it
so don't be surprised that some bugs remain
no problem
but again, we don't really need more bug reports
but rather bug fixing
we already have enough to fix, no need to delve into advanced
things
sure, i'm just trying to make it work with all its limitations
it autopartition the disk well, it can't just make one choose among
disks because it can't probe and list them
then fix the probe & list
i'd like doing it, i'm better at working around for now though :)
one blocker is mount/umount stuff
[[glibc#mount]].
well, you'll have to get into fixing bugs for real someday
otherwise this is just adding to TODO lists
what mount/umount stuff?
(took a quick look at partconf)
non-existent mount.h for instance
do we have replacements?