From de3f3f6cc52d1e5013e85137d09f2ac23e657858 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Mar 2014 20:10:58 +0100 Subject: IRC. --- open_issues/anatomy_of_a_hurd_system.mdwn | 19 + open_issues/clock_gettime.mdwn | 8 + open_issues/dde.mdwn | 10 + open_issues/glibc.mdwn | 39 + open_issues/glibc/debian/experimental.mdwn | 9 + open_issues/multithreading.mdwn | 17 + open_issues/nightly_builds_deb_packages.mdwn | 850 ++++++++++++++++++++++ open_issues/performance.mdwn | 19 + open_issues/performance/io_system/read-ahead.mdwn | 10 + open_issues/ti-rpc_then_nfs.mdwn | 27 + open_issues/versioning.mdwn | 5 +- open_issues/virtualization/fakeroot.mdwn | 31 + 12 files changed, 1040 insertions(+), 4 deletions(-) (limited to 'open_issues') diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 33635b80..932e11a6 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1327,3 +1327,22 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l load it from grub instead of /hurd/ext2fs.static look at the grub config for how this is done let me know if it worked ;) + + +# IRC, freenode, #hurd, 2014-03-04 + + Can I run a single instance of hurd on multiple computers + With them acting as different servers? + no + Like the fs server on one pc etc. + Which os could I do this with? + I assumed Mach RPC would support that. + it can + but we don't use it that way + plan9 is probably better suited to what you want + inferno too + maybe dragonflybsd + Yep. + irAwesome. + Plan9 is exactly it. + enjoy diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index baa21bbb..407a104c 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -338,3 +338,11 @@ In context of [[select]]. anyway :) (although it will soon...) nice + + +## IRC, freenode, #hurd, 2014-03-05 + + braunr: bit of a warning: i released the glib that depends on + working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it + will be landing in debian within the next days + desrt: ok diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index 9d8bf509..e7083557 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -614,6 +614,16 @@ In context of [[libpthread]]. primitives* +## IRC, freenode, #hurd, 2014-03-08 + + what to do if network freezes? + gg0: depends on what caused the freeze + gg0: you could try to kill the netdde process + it's just apt-get'ing, download phase + yess kill netdde + there are known deadlocks in netdde + + # IRC, freenode, #hurd, 2012-08-18 hm looks like if netdde crashes, the kernel doesn't handle it diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 4dad229f..ad7b3c72 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -1855,6 +1855,45 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 teythoon: i think it should be in glibc maybe in mach/ + * POSIX record locking + + IRC, freenode, #hurd, 2014-02-27: + + tschwinge: schould POSIX record locking be on + http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing + as well. or is that strictly a Hurd thing? (I don't remember) + azeem_: Neither do I :-), but I'll have a look later + on. + + * `execve` with relative paths + + [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id + "4BFA500A.7030502@gmail.com"]]. + + IRC, freenode, #hurd, 2014-03-05: + + youpi: what about the exec_filename patch series? [...] + Roland was disagreeing with it + + * `mount`/`umount` + + IRC, freenode, #hurd, 2014-03-01: + + Hi, how to handle packages depending on mount.h, et al? + On Hurd mount/umount is supplied by hurd is not in libc? + gnu_srs1: mount or mount.h? + mount.h et al + man 2 mount + what is the question then? + some packages expect the mount 2 functionality + available, not by the external command mount/umonut + umount* + azeem: one example is fuse + gnu_srs1: that is correct + gnu_srs1: i put a small hacks entry in the list about + moving the mount/umount functionality from our utilities to the + libc + For specific packages: * [[octave]] diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn index 273f02fd..4ae9807b 100644 --- a/open_issues/glibc/debian/experimental.mdwn +++ b/open_issues/glibc/debian/experimental.mdwn @@ -225,6 +225,15 @@ Now in unstable. ok that mmap fix looks fine, i'll add comments and commit it soon +## IRC, freenode, #hurd, 2014-03-03 + + braunr: did you test whether + https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 + does indeed fix locale generation? + youpi: it doesn't, which is why i applied + http://git.sceen.net/hurd/glibc.git/commitdiff/da2d6e677ade278bf34afaa35c6ed4ff2489e7d8?hp=9a079e270a9bec7e1fe28aeda63e07c1bb808d44 + + # IRC, OFTC, #debian-hurd, 2013-06-20 damn diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index d5c0272c..a66202c8 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -561,6 +561,23 @@ Tom Van Cutsem, 2009. ^^ +### IRC, freenode, #hurd, 2014-03-02 + + braunr: what is the status of the thread storm issue? do you have + pending code changes for this? + I was wondering whether to make ext2fs use adaptative locks, + i.e. spin a bit and then block + I don't remember whether anybody already did something like that + youpi: no i don't + youpi: i attempted switch from spin locks to mutexes once but it + doesn't solve the problem + switching* + found another storm maker: + $ dpkg-reconfigure gnome-accessibility-themes + aka update-icon-caches /usr/share/icons/HighContrast + braunr: ok + + ## Alternative approaches: * diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index da7bdc7d..fc9c2f18 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -108,3 +108,853 @@ See also [[nightly_builds]]. 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? + not that I know of + 21:53 < teythoon> gnu_srs1: i put a small hacks entry in the list + about moving the mount/umount functionality from our utilities to the + libc + ok + another thing i'd really like to see would be a physical shutdown, + halt-hurd which actually poweroffs the system + how to switch to sysvinit by default? next sysvinit upload? + physical shutdown means implementing APM or ACPI + have to teach jenkins it can shut it down :/ + I'm extremely far from having the will for this + switching to sysvinit by default is a matter of saying that we want + to do it + I already asked for this on the list without answer IIRC + i can't find anything + anyway, just propose on the list + d-i grub-installer/bootdev string /dev/hd0 - here it is + next run should not need any interaction, though it needs 20 mins to + understand it has to destroy it and run won't be successful :/ + due to missing acpi/apm + first graphical automated install http://postimg.org/image/vgagj06q7/ + it seems 720x400 + though jenkins passes video=vesa:ywrap,mtrr vga=788 + by reconnecting it switched to 800x600 + http://postimg.org/image/h32qjykrx/ + but seems stuck now and i can't even switch from graphical to + consoles + unusually stuck at scanning cdrom + i'll check text install to see if it gets stuck there too + text install switches from 720x400 to 640x400 + i confirm it gets stuck on scanning cdrom, i guess because of this + one https://bugs.debian.org/728153 which already broke load-install-cd i + already had to workaround + gg0: are you in contact with h01ger to update jenkins.debian.net + with your cool installation code? + pere: still trying to have something working + plus with new weekly cd, apt-cdrom bug makes install getting stuck at + first Scanning cdrom: + 03:44 < gg0> i confirm it gets stuck on scanning cdrom, i guess + because of this one https://bugs.debian.org/728153 which already broke + load-install-cd i already had to workaround + do we really need the CD-1 image in weekly builds? + just netinst? + yes + well, i don't know debian installer well. what's the difference + between CD and NETINST besides that CD has more packages user doesn't + need to download? + has CD anything not in NETINST which is worth to continously test? + (talking about jenkins) + that's only it, yes + btw new ACPI on hurd consists of serial console to file + looping + grep "In tight loop: hit ctl-alt-del to reboot" && kill qemu + anything better? + filed http://bugs.debian.org/740673 + without a patch just to express my great laziness :p + well, I'm afraid nobody in the debian-boot team will attempt + anything at this + is it reproducible on linux? + nope + my guess is that's due to udev, need a deeper check btw + i mean non-udev cases like hurd maybe are not handled well + maybe try on kfreebsd then? + just guessing + * gg0 trying on kfreebsd + + +## IRC, OFTC, #debian-hurd, 2014-03-04 + + hurd install started getting stuck running os-prober, final grub + install phase + youpi: yes i confirm it affects kfreebsd too + then please say so in the bug + otherwise most probably but me in the debian-boot team will care + +nobody + that might get more attention from d-boot team? + ok + also Cc debian-bsd@ + they will care + and tell about the hint as being the non-udev case + too much information or ideas is never a bad thing :) + done + (now i know notfound does remove found versions instead of adding + notfound versions) + crazy things. to unblock os-prober i had to settrans -fg + /target/media/./cdrom0 + it was mounting /dev/hd0s1 ... + i suspect apt-cdrom is to blame again + ok now jenkins just managed to start the installed system + and it's configured to make vncdo testing it + i'd need a graphical-working cd with old-apt to continue + let's try to install old apt on weekly-0 + "cdrom drive contains a cd which cannot be used for installation" + i think a sort of non-authenticated anymore + ehm.. http://paste.debian.net/plain/85224/ + gg0: nice. :) + with apt 0.9.15.1 which should be good + pere: it did mount /dev/hd0s1 under /media/cdrom0 + 0.9.15.5, correctly i think, asks to insert it cdrom. but finally + both mount /dev/hd0s1 instead of /dev/hd2 + -it + cause they both can't detect where cdrom is i guess + + +## IRC, freenode, #hurd, 2014-03-04 + + we could talk about apt-cdrom https://bugs.debian.org/740673 + how should system recognize cdrom device? + there's no /dev/cdrom link to actual cdrom device + /dev/cd[01] are scsi devices if i'm not wrong + + +## IRC, OFTC, #debian-hurd, 2014-03-05 + + installer gets stuck running os-prober, seems because + /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it + gets stuck reading it + +[[hurd/translator/mtab/discussion#chroot]]. + + youpi: could you publish script to rebuild CDs you scheduled? with + last official CD (20140212) mtab on /target dies and that seems getting + os-prober stuck. last (and only) weekly has recent apt-cdrom so it gets + stuck wrongly asking to change cdrom + see the readme file + err, you say it's the 0212 build which fails? + I had tested that before uploading + so the issue comes form the installed packages, not from the CD + udebs + did you test with no network mirror? + no i didn't. should it find all packages it needs from cd? + sure, that's what netinst and dvd-1 are, as opposed to netboot + lxde desktop probably not + indeed + though with the dvd in principle it should + (if all deps were avaijlable at image build time) + gg0: btw if you haven't noticed, there's a daily too + youpi: till apt-cdrom is not fixed, they all will be broken, stuck at + "Scanning cdrom" + gg0: did you try to bisect which git change produces the apt-cdrom + bug? + youpi: all in bug in question + youpi: https://bugs.debian.org/740673 + is there the precise git commit id in the bug log? + + http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=commitdiff;h=62dcbf84c4aee8cb01e40c594d4c7f3a23b64836 + well, don't tell that to just me, but the bug report... + bug report says "See " where bug is + https://bugs.debian.org/728153 + gg0: bug report doesn't say it was *tested* that it is that changes + which broke things + i don't think we could get it reverted just because it breaks hurd + (+kfreebsd to check) debian installer + of course, but that's at least where developers can have a look at + well ok i could have been more clear + it's *WAY* better than having no idea where to have a look at + gg0: btw, that's why the README file advises not to use a network + mirror, to avoid such kind of issues + you can't expect sid not to be not-broken :) + one gets Resource lost even when install is just started, no packages + from any mirror + https://bugs.debian.org/740673#19 + + * gg0 installing without mirrors, without desktop, without lxde + same problem + so problem has nothing to do with installing from mirrors + what's odd is that I don't get this issue at all with the 20140212 + upload at least + kvm -cdrom debian-7.0-hurd-i386-NETINST-1.iso -drive + file=blip,cache=unsafe -m 1G + no more, no less + it must depend on preseed and/or kernel append options + possibly + oh wait here qemu multiboot + that shouldn't have any impact + did you leave the command line somewhere on the wiki so I can try + with it, just to be sure? + + http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot + 5€ on qemu multiboot as the culprit + you should also see it sometimes double-mounts /dev/hd0s1 under + /target and /target/./media/cdrom(!) + but that's due to new apt it in-targets (= installs under /target) + gg0: rather use the gnumach, ld.so and ext2fs.static from the ISO + image you are booting + especially for ld.so, which has to be the same as the libc + installed in the initrd + ah, you're getting the initrd there too + well, really use the same as the ISO + i already do + ah, ok, so the wiki example is just with current + but the wiki example doesn't use -cdrom to provide the ISO ? + no it doesn't even mention you could also use a cdrom + it just shows how to use qemu multiboot options + it seems one have to avoid any blanks in the multiboot option + notably before file names + well, actually it works but it's rather incomplete + well, it shows how to boot the installer + not how to boot an installed system + removed spaces, added option + here qemu binary is qemu-system-x86_64 instead of qemu-kvm and it + crashes without --enable-kvm + qemu: fatal: Trying to execute code outside RAM or ROM at + 0x000000010010001e + rather use qemu-system-i386 + i was just complaining i wrote qemu-kvm on wiki but i did never + actually run that command as is + ouch right, -i386 doesn't require enable-kvm + (i'll never know why) + -x86_64 is buggued + 0x000000010010001e should have been truncated to 0x0010001e since + it's 32bit mode + i see + any luck reproducing mtab issue? + still not + +[[hurd/translator/mtab/discussion#chroot]]. + + +## IRC, OFTC, #debian-hurd, 2014-03-06 + + http://paste.debian.net/85535/ + no issue + (no network mirror) + full install till grub-installer? + yes + and reboot + -append 'auto=true mirror/suite=sid console=com0 priority=critical + locale=en_US keymap=us + url=http://10.0.2.1//d-i-preseed-cfgs/debian_sid_daily_hurd_lxde_preseed.cfg + video=vesa:ywrap,mtrr vga=788 -- quiet' + i should provide preseed too + well, of course + always provide as much information as possible + so there's also your preseed file + not much different from + http://jenkins.debian.net/d-i-preseed-cfgs/debian_sid_daily_lxde_preseed.cfg + but you need to force a couple of things + ugly workaround for broken + apt-cdrom ident + well, I didn't even know that jenkins had that pressed file + well, here apt-cdrom is not needed + +hacks + since that's the old image we're checking + well ok, given you take everything from cd only, yes + here no mirror, no desktop, no lxde + http://paste.debian.net/plain/85538/ + i'm trying this one too + main difference seems to be i usually use CD-1, not NETINST + had to add -net nic,vlan=0 -net + user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 + here target mtab is already crashed + because some package already tried to read /target/proc/mounts + youpi: reproduced there? + .o(well, maybe he's been sleeping for ~50 mins) + nope, I'm working on upgrading servers + I'm sorry, but your testcase is not really easy to reproduce :) + do you have apache on your host? just put preseed in the root, vm + will take it + full command line is what you pasted + -net nic,vlan=0 -net + user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 + what else? when it starts debstrapping, open a console and check + procfs and mtab processes + err, what you paster + -append i pasted + -net nic,vlan=0 -net + user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 + *pasted + which is http://paste.debian.net/plain/85554/ + surely keyboard layout doesn't help, here at least + * gg0 tries to reproduce without preseed + i can't reproduce it + it doesn't crash + * gg0 enabling all options but preseed + need to wait 31% of Installing base system to have the second procfs + ok got Resource lost even without preseed + youpi: you can reproduce it by adding -append console=com0 to what + you pasted. that breaks grub-installer, it gets stuck at 66%, while runs + os-prober + ah + how can that affect /target/proc/mounts? + no idea + couldn't daily be here? http://d-i.debian.org/daily-images/ + if I knew how to push files there, sure + asking on #debian-boot would be a starting point i guess + probably + me asking on behalf of youpi would not a good one i think, given + whatever will the answer i can't do anything + +be + you can still trasmit me + never understimate the little time you can save other people by + doing some bits of work + well, i would not even have to repaste lines here given you joined + there too + never understimate what "help with laziness" means :) + not necessarily repasting, but at least highlighting me + so I know where to read in the #d-b logs + there are no isos there, i'm missing something + there are no daily isos + only weekly isos + so seems i have to reask initial question with this url + http://cdimage.debian.org/cdimage/weekly-builds/ + oh wait they are from testing, that's why no hurd ones + i guess they could be here though + http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/ + * gg0 asking on #debian-cd + * gg0 would ignore non-DD gg0 asking whatever + people don't really ask themselves who is a DD and who is not + as long as you provide information in your question, it'll get + answered + teythoon: interested in reproducing mtab-dying-under-chroot? + oh just realized it's not only under a chroot, chroot is on another + disk. might that make the difference? + i didn't try to reproduce it by creating a chroot on a different + disk, which is what installer does + * gg0 wonders if it would have been better filing a bug against + cdimage.debian.org + if no one fixes console=com0 thing, i have to think about a new acpi + ok managed to workaround apt bug in installer, i can graphically + install last weekly + no console=com0 means no vm shutdown though + gg0: wow. impressed! + patching CI to make CI workaround bugs CI spots is not so good + any idea about another shutdown trick without console=com0 till + teythoon or youpi fix it? + nope + current one: vm writes serial console to file and host loops grepping + "In tight loop: hit ctl-alt-del to reboot" + -watchdog might be an alternative + if there are watchdog agents that can run on hurd + "watchdog" for instance doesn't build on hurd + it need kernel support + * gg0 testing -add-fd + + +## IRC, freenode, #hurd, 2014-03-07 + + teythoon: just mounted an additional fs, it's mounted but not present + in proc/mounts + gg0: how did you mount it ? + i was under /root, sid-chroot is the mountpoint. i did mount /dev/hd3 + sid-chroot (relative path) + does fsysopts confirm a new translator is running on sid-chroot ? + i shut down vm, working on another one by mounting the same disk + which hosts a debchroot + i'm trying to reproduce the mtab-dying-on-chroot issue i get with + debian installer + at the end, os-prober gets stuck by reading /target/proc/mounts + (target is the installed system) + to be precise it gets stuck at second access. at first it gives + Resource lost + didn't manage to reproduce so far + environment is pretty the same: booting with qemu multiboot + http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot + so root on initrd + chroot on real disk + what's weird is that issue vanishes by removing console=com0 from + -append options + + +### IRC, freenode, #hurd, 2014-03-08 + + os-prober doesn't get stuck anymore and grub can install + my guess is that without console=com0 /target/proc/mounts is just + accessed once + + +## IRC, OFTC, #debian-hurd, 2014-03-08 + + youpi: from #debian-cd http://paste.debian.net/plainh/559f669b + any quick way to recreate initrd? + gg0: i'm working on that + teythoon: that what? + gg0: there is genext2fs, i have some patches that allows one to + create nodes with passive translator records + recreating initrd? + yes + in the meantime, you can mount the existing initrd and modify it + well i'm following this one to rebuild whole cd then take an updated + initrd to test with your repo + http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i + probably too much work to get that + copying current /hurd to new initrd would be enough? + just copy the precise translator you need + also, no need to rebuild the whole cd just to replace the initrd + simply copy the content of an existing is + iso + replace the initrd.gz there + and then use grub-mkrescue to rebuild the ios + development would be horrible if you had to rebuild everything from + zero everytime + first thing to do when developping is first take the time to find + ways to work efficiently + i'd want to try multiboot with teythoon's gnumach/hurd but boot gets + stuck with old initrd + unfortunately I had to apply some patches + first in d-i because isc-dhcp doens't work -> use the debian-ports + version + so i could simply copying whole /hurd dir to new initrd + -ing + then in d-i to automatically enable the debian-ports mirror + and last in the debian-cd to include debian-ports-archive-keyring + you'd also need to copy the libs + anything missing here? + http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i + libc0.3 on initrd is still 2.17 + mini.iso doesn't like any mirror + "mirror does not support the specified release" + something wrong/missing in my rebuilt + youpi: anything wrong in http://paste.debian.net/plain/86258 ? + i have/had problems with name resolution + gg0: the patch makes sense for -bsd too, Cc them too + i was wondering how many hunks in your patches are upstreamable + normally it's zero + + http://people.debian.org/~sthibault/hurd-i386/installer/patch-debootstrap + why "release" instead on "main" by default? sid is never released + only because my mirror directory is hacked one + that merges debian.org, debian-ports.org, and my repo + and I don't rebuild Release files, just Packages files + i keep getting gpgv: BAD signature from "Debian Archive Automatic + Signing Key (7.0/Wheezy) + just before creating debootstrap chroot + i applied hunk #2 only, installed modified debootstrap and put debs + under localdebs/ + trying a different mirror + I don't know what issue you are encountering + but again, it's way simpler and faster to just patch existing + images, rather than rebuilding them from zero + ok just read i'd need a local mirror to build isos + better using netinst and proxy cache + + +## IRC, freenode, #hurd, 2014-03-09 + + http://postimg.org/image/oca8ormaj/ + with teythoon's repo too ^ + + +## IRC, OFTC, #debian-hurd, 2014-03-09 + + ok i'm out of tests, i get Resource lost with teythoon's gnumach/hurd + packages in initrd too + http://postimg.org/image/oca8ormaj/ + thread storms, dead locks, resource lost + i find assonance + + +## IRC, freenode, #hurd, 2014-03-09 + + gg0: strange + teythoon: shouldn't there be a patch which shows pid instead of task? + 20:43 < teythoon> task /hurd/procfs(19) O + deallocating an invalid port 1049744, most probably a bug. + there is + i placed the functionality in proc first, but the wiki suggested + to put it in the exec server instead + i did that, it has the advantage, that the argv vector is easily + accessible + so i can also include the program name + but there are two programs, that are not started using the exec + server + the root filesystem and the exec server itself + so for these two processes, the approach does not work + i see. so here we got two which could come from + ext2fs.static(initrd), exec(initrd) and ext2fs(chroot) + http://postimg.org/image/e3qyafd0b/ right? + i also noticed that once mtab dies, by killing its procfs parent, + they both restart, but /target/proc is not in /proc/mounts anymore + teythoon: for those we could use the first word of the module + command line + restart doesn't means that by accessing /target/proc/mounts again it + works btw, it'll give Resource lost again + youpi: indeed + gg0: no, the ext2fs for /target will be started by the exec + server + ok two invalid ports one from ext2fs.static and one exec then + gg0: what makes you attribute one to the exec server ? + i'm pretty sure that there is a bug in libfshelp, it's easily + triggered by killing an translator like procfs + i must have introduced it with the translator list work i've + done for the mtab translator + teythoon: a totally wrong task-is-a-process reasoning probably + just mounted another procfs which seems to work + http://postimg.org/image/q6w9xzo2j/ + http://postimg.org/image/cr998jfkr/ + gg0: the mtab translators in your screenshots are oldish, what's + the point exactly ? + gg0: also, all tasks are processes. task is a mach concept, + whereas process is a posix concept implemented by hurds proc server. it + creates a process object for every mach task. + my guess was that given we got two messages with different taskid: + 16:01 < gg0> ok two invalid ports one from ext2fs.static and one exec + then + screenshot is this one http://postimg.org/image/e3qyafd0b/ + btw what do you mean by oldish. except first one 01:18 < gg0> + http://postimg.org/image/oca8ormaj/ the only with current debian + packages, remaining are done with your latest packages + in all cases i boot using qemu multiboot + root@hurd01:~# cat /proc/version + Linux version 2.6.1 (GNU 0.5 GNU-Mach 1.4-486-dbg/Hurd-0.5 + i686-AT386) + it wouldn't be bad customizing version somehow, last commit id for + instance + or build date + user01@jessie01 ~$ cat /proc/version + Linux version 3.11-2-686-pae (debian-kernel@lists.debian.org) (gcc + version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) + user01@jessie01 ~$ uname -v + #1 SMP Debian 3.11.10-1 (2013-12-04) diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index 3dab6d4c..64b245f2 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -239,3 +239,22 @@ call|/glibc/fork]]'s case. teythoon: pahole is a very handy tool :) yes i especially like how general it is + + +# Measurement + +## coulomb + +### [[!message-id "87wqghouoc.fsf@schwinge.name"]] + +## IRC, freenode, #hurd, 2014-02-27 + + tschwinge: about your concern with regard to performance + measurements, you could run kvm with hugetlbfs and cpuset + on a machine that provides nested page tables, this makes the + virtualization overhead as small as it could be considering the + implementatoin + hugetlbs reduces the overhead of page faults, and also implies + locked memory while cpuset isolates the vm from global scheduling + hugetlbfs* + Thanks, will look into that. diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index 711f7691..59f22187 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -3064,3 +3064,13 @@ License|/fdl]]."]]"""]] mach-defpager) rebase it, send it as a patch on bug-hurd, it should be straightforward and short + + +## IRC, freenode, #hurd, 2014-03-04 + + btw, has mcsim worked on vectorized i/o ? there was someting you + wanted to integrate + not sure what + clustered pageins + but he seems busy + oh, pageins diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn index c3dd4e26..46cc1c1c 100644 --- a/open_issues/ti-rpc_then_nfs.mdwn +++ b/open_issues/ti-rpc_then_nfs.mdwn @@ -103,3 +103,30 @@ re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]]. failing rpcinfo -p on hurd reported as . Anyone got a clue how to debug it? + + +## IRC, OFTC, #debian-hurd, 2014-03-03 + + I was just tipped by sesse that the hurd fix for libtirpc probably + caused RC bug in nfs-common, . + Have not had time to check it out more closely. + + +## IRC, OFTC, #debian-hurd, 2014-03-04 + + pere: I don't really see how debian/patches/05-hurd-port.diff could + break Linux' libtirpc + AIUI, the patch has zero effect on non-hurd builds + oh wait + it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined + in config.h.in + youpi: I am quite sure I did add the required dh_autoreconf call. + did you see a build log where it was missing? + pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped + and I don't have any further idea + pere: maybe it's the autoreconf itself which broke something? + could be. not quite sure how to find out. + pere: what about running autoreconf on the previous (working + version)? + gnu_srs: sound like a good idea. perhaps a good idea to just + disable the two patches as a start. diff --git a/open_issues/versioning.mdwn b/open_issues/versioning.mdwn index 1987b6ca..18fb588e 100644 --- a/open_issues/versioning.mdwn +++ b/open_issues/versioning.mdwn @@ -66,11 +66,8 @@ In context of [[packaging_libpthread]]/[[libpthread]]. could be the perfect moment to fix the /dev/fd/N problem without adding new RPCs, though we'd probably have to break backwards-compatibility in the exec server IIRC... - pochu: Oh, I have to re-read that discussion, but thanks for - reminding! -[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id -"4BFA500A.7030502@gmail.com"]]. +[[glibc#execve_relative_paths]]. ### `time_t` -- Unix Epoch vs. 2038 diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn index 8901e1c3..88a18a93 100644 --- a/open_issues/virtualization/fakeroot.mdwn +++ b/open_issues/virtualization/fakeroot.mdwn @@ -24,6 +24,8 @@ License|/fdl]]."]]"""]] it's just a argv[0] issue supposed to be fixed by exec_file_name but apparently not fixed in that case, for some reason +[[glibc#execve_relative_paths]]. + ## IRC, freenode, #hurd, 2013-08-26 @@ -36,6 +38,9 @@ License|/fdl]]."]]"""]] < youpi> yes < youpi> pinotree's exec_file_name is supposed to fix that, but for some reason it doesn't work here + +[[glibc#execve_relative_paths]]. + < pinotree> it was pochu's, not mine < youpi> ah, right < teythoon> ah I see, I was wondering about that @@ -73,6 +78,9 @@ License|/fdl]]."]]"""]] I believe I figured out the argv[0] issue with fakeroot-hurd but I'm not sure how to fix this first of all, Emilios file_exec_file_name patch set works fine + +[[glibc#execve_relative_paths]]. + but not with fakeroot http://git.sceen.net/hurd/hurd.git/blob/HEAD:/exec/hashexec.c#l300 @@ -1293,3 +1301,26 @@ License|/fdl]]."]]"""]] teythoon: was it a big package ? half of the hurd package that's not a port right overflow then + + +## IRC, freenode, #hurd, 2014-03-05 + + youpi: what about the exec_filename patch series? even though + fakeroot still has some issues (has it?), i consider it worthy for + inclusion + +[[glibc#execve_relative_paths]]. + + Roland was disagreeing with it + iirc the fakeroot issue was solved + braunr: ^ + fakeroot goot a lot more robust than it used to be + but i haven't checked that it actually behaves exactly like the + library for corner cases + there are minor differences + also, it seems to trigger concurrency bugs in ext2fs + e.g. git reporting that files either "already exist" or "can't be + found" + it happens (rarely) when directly using ext2 + and more often through fakeroot + i didn't take the time to investigate -- cgit v1.2.3 From e888d3564f581f640c8df8d4f7dca1645be27593 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Mar 2014 23:52:35 +0100 Subject: open_issues/glibc: POSIX Timers. --- open_issues/glibc.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'open_issues') diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index ad7b3c72..a16d2b8a 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -217,7 +217,6 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 youpi et al.: Is it a useful GSoC task to have the student implement interfaces in glibc that we are currently missing? tschwinge: definitely - posix_timers would be great tschwinge: probably Many more are missing, some of which have been announced in `NEWS`, others @@ -1894,6 +1893,11 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 moving the mount/umount functionality from our utilities to the libc + * POSIX Timers + + `timer_create`, `timer_delete`, [[`clock_gettime`|clock_gettime]], and + so on. + For specific packages: * [[octave]] -- cgit v1.2.3 From 8d5e38666c0c14a2cace5d532e3e1226b82e7c69 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Mar 2014 23:53:10 +0100 Subject: community/gsoc/project_ideas/testsuites: Implement Missing Interfaces for GNU Hurd. --- community/gsoc/project_ideas/testsuites.mdwn | 59 ++++++++++++++++++++++++---- open_issues/glibc.mdwn | 13 +++--- 2 files changed, 57 insertions(+), 15 deletions(-) (limited to 'open_issues') diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn index 9ca6fe3e..0d92a0a7 100644 --- a/community/gsoc/project_ideas/testsuites.mdwn +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 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 @@ -8,7 +9,13 @@ 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]]."]]"""]] -[[!meta title="Fix Compatibility Problems Exposed by Testsuites"]] +[[!meta title="Fix Compatibility Problems Exposed by Testsuites, Implement +Missing Interfaces"]] + +[[!toc]] + + +# Fix Compatibility Problems Exposed by Testsuites A number of software packages come with extensive testsuites. Some notable ones are [[open_issues/glibc]], gnulib, Perl, @@ -36,25 +43,61 @@ The goal is to analyze all failures in one or more of the listed testsuites, to find out what shortcomings in the Hurd implementation cause them (if any), and to fix at least some of these shortcomings. -Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above. +Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]]. Here the focus however is not on improving the support for any particular program, but on fixing general problems in the Hurd. -This is a very flexible task: +A complementary task is adding a proper [[open_issues/unit_testing]] framework +to the GNU Hurd's code base, and related packages. + + +# Implement Missing Interfaces for GNU Hurd + +A related project is to [implement missing interfaces for GNU +Hurd](http://www.gnu.org/software/soc-projects/ideas-2014.html#glibc_hurd_missing_interfaces) +([glibc +wiki](https://sourceware.org/glibc/wiki/GSoC#Implement_Missing_Interfaces_for_GNU_Hurd)), +primatily in [[open_issues/glibc#missing]]. + +In glibc's Linux kernel port, most simple POSIX interfaces are in fact just +forwarded to (implemented by) Linux kernel system calls. In contrast, in the +[[GNU Hurd port|/glibc]], the POSIX (and other) interfaces are actually +implemented in glibc on top of the [[Hurd RPC protocols|hurd/rpc]]. A few +examples: +[getuid](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/getuid.c), +[open](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c), +[rmdir](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/rmdir.c), +[setresuid](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/setresuid.c), +[socketpair](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/socketpair.c). + +When new interfaces are added to glibc (new editions of POSIX and similar +standards, support for new editions of C/C++ standards, new GNU-specific +extensions), generally [ENOSYS +stubs](https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/execve.c) are +added, which are then used as long as there is no real implementation, and +often these real implementations are only done for the Linux kernel port, but +not GNU Hurd. (This is because most of the contributors are primarily +interested in using glibc on Linux-based systems.) Also, there is quite a +backlog of [[missing implementations|open_issues/glibc#missing]] for GNU Hurd. + +In coordination with the [[GNU Hurd developers|mailing_lists/bug-hurd]], you'd +work on implementing such missing interfaces. + +--- + +These are very flexible tasks: while less experienced students should be able to tackle at least a few of the easier problems, other issues will be challenging even for experienced hackers. -No specific previous knowledge is required for this task; +No specific previous knowledge is required; only fairly decent C programming skills. While tracking down the various issues, the student will be digging into the inner workings of the Hurd, and thus gradually gaining the knowledge required for Hurd development in general. -A complementary task is adding a proper [[open_issues/unit_testing]] framework -to the GNU Hurd's code base, and related packages. - Possible mentors: Samuel Thibault (youpi) Exercise: Take a stab at one of the testsuite failures, +or missing implementation, and write a minimal testcase exposing the underlying problem. Actually fixing it would be a bonus of course -- but as it's hard to predict which issues will be easy and which will be tricky, diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index a16d2b8a..923ca99d 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -210,16 +210,15 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' make: *** [all] Error 2 - * Missing interfaces, amongst many more. + * Missing Interfaces - IRC, freenode, #hurd, 2014-02-25: + We have posted a [[Google Summer of Code project proposal|community/gsoc]]: - youpi et al.: Is it a useful GSoC task to have the student - implement interfaces in glibc that we are currently missing? - tschwinge: definitely - tschwinge: probably + [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no + actions=yes]] - Many more are missing, some of which have been announced in `NEWS`, others + Many are missing for GNU Hurd, some of which have been announced in + [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others typically haven't (like new flags to existing functions). Typically, porters will notice missing functionaly. But in case you're looking for something to work on, here's a bit of a commented list, otherwise go -- cgit v1.2.3 From 08fa84c9662c3ac2b0b0bb6284efc97b87bfc815 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 11 Mar 2014 11:10:40 +0100 Subject: Interlink file locking issues. --- community/gsoc/project_ideas/file_locking.mdwn | 3 ++- open_issues/file_locking.mdwn | 28 ++++++++++++++++++++++++-- open_issues/glibc.mdwn | 10 +-------- open_issues/visudo.mdwn | 4 ++-- 4 files changed, 31 insertions(+), 14 deletions(-) (limited to 'open_issues') diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn index 206d4d7d..ebb322f1 100644 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2012 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2012, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -29,6 +29,7 @@ A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]]. Possible mentors: Samuel Thibault (youpi) Exercise: Find one of the existing issues, either by looking at the task/bug +filed on [[open_issues/file_locking]], on trackers on savannah, or by trying things out yourself; and take a go at it. Note though that most of these issues are probably not trivial -- it's quite likely that you won't be able to actually fix any of them in the time available diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn index 563307a4..7dfbdb94 100644 --- a/open_issues/file_locking.mdwn +++ b/open_issues/file_locking.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 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 @@ -10,7 +11,25 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd open_issue_glibc]] -IRC, #hurd, 2010-12-31. +[[!toc]] + + +# Google Summer of Code Project Idea + +[[community/gsoc/project_ideas/File_Locking]]. + + +# visudo + +[[visudo]]. + + +# Existing Work + +[[!GNU_Savannah_patch 332]]. + + +# IRC, freenode, #hurd, 2010-12-31 youpi: i found the issue with python-apt s/with/of/ @@ -72,3 +91,8 @@ IRC, #hurd, 2010-12-31. ah, no, on Linux flock is its own system call (which is independant from lockf from the locking point of view, iirc) + + +# 2014-03-11 + +[[!message-id "1394523876.28244.11.camel@workhorse-peter-baumgarten-com"]]. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 923ca99d..33041e71 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -1853,15 +1853,7 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 teythoon: i think it should be in glibc maybe in mach/ - * POSIX record locking - - IRC, freenode, #hurd, 2014-02-27: - - tschwinge: schould POSIX record locking be on - http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing - as well. or is that strictly a Hurd thing? (I don't remember) - azeem_: Neither do I :-), but I'll have a look later - on. + * [[POSIX file record locking|file_locking]] * `execve` with relative paths diff --git a/open_issues/visudo.mdwn b/open_issues/visudo.mdwn index e9892e33..4e87fd8d 100644 --- a/open_issues/visudo.mdwn +++ b/open_issues/visudo.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 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 @@ -16,7 +16,7 @@ visudo does not work: /etc/sudoers is busy, try again later -Apparently there is some locking that sudo does which does not +Apparently there is some [[file_locking]] that sudo does which does not work. Uninvestigated for now. One can just edit the /etc/sudoers file and take care of correctness by hand. -- cgit v1.2.3 From 902ccccf1de52204846948410cbd1a8849b691c2 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 11 Mar 2014 21:48:24 +0100 Subject: IRC. --- hurd/running/debian/qemu_image.mdwn | 32 +++++++++++ hurd/running/nix.mdwn | 10 ++++ hurd/translator/ext2fs.mdwn | 35 ++++++++++++ open_issues/anatomy_of_a_hurd_system.mdwn | 82 ++++++++++++++++++++++++++++ open_issues/nightly_builds_deb_packages.mdwn | 23 ++++++++ 5 files changed, 182 insertions(+) (limited to 'open_issues') diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 95c23920..168823bf 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -29,3 +29,35 @@ Just in case you were wondering: the *root* password is empty. [[!if test="destpage(hurd/running/qemu)" then="" else="For more detailed instructions, please see the [[hurd/running/QEMU]] page."]] + + +# IRC, freenode, #hurd, 2014-03-10 + + scp doesn't work either + what ? + why wouldn't it ? + scp -P5555 -r ./hurd/ root@localhost:/root/src/ + root@localhost's password: + The Hurd is not Linux. Make sure to read + that shouldn't happen ... + use tar maybe ? + the same with tar archive + :/ + i don't know what to tell you + i don't have that problem + + +## IRC, freenode, #hurd, 2014-03-11 + + braunr: mcsims scp problem is b/c youpis images echo stuff from + the .bashrc or something + i wish he'd change that, as it is a reoccuring problem + youpi: ^ + (didn't realize you are around >,<) + now that /etc/issue is displayed, you can put the welcome text + there + teythoon: i see + mcsim: your ssh trouble are rooted in the .bashrc printing some + stuff to stdout + teythoon: thank you. It works now + :) diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn index c6212da8..68052948 100644 --- a/hurd/running/nix.mdwn +++ b/hurd/running/nix.mdwn @@ -500,3 +500,13 @@ Nix, and because of that, it uses per-package installation directories under phant0mas: you could look at what the debian package does ok phant0mas: check debian glibc for all the patches + + +## IRC, freenode, #hurd, 2014-03-10 + + tschwinge: While crosscompiling glibc I get the error "Error: + incorrect register `%rax' used with `l' suffix" + http://pastebin.com/raw.php?i=ZJKHrm4s + Any idea why is this happening? + ph4n70m4s: something is trying to compile as an x86-64 object, + while the hurd is i386 only diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index ba849cca..81e54dff 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -431,6 +431,41 @@ That would be a nice improvement, but only after writeback throttling is impleme k, the file created with mke2fs has 128 +### IRC, freenode, #hurd, 2014-03-10 + + hi. I'm having problems with copying directory from host machine to + hurd image. I mount hurd image at host and than use "cp -r" to copy + directory. Then I unmount image and start qemu. When I try to see + contents of the directory I get error "Computer bought the farm". + mcsim: are you using the ext4 driver from linux ? + I use image debian-hurd-20140211.img from + if so, avoid it + ok + i'll try + braunr: do I have to compile module on my own? because modprobe + ext2 && lsmod | grep ext2 give no output? + maybe + mcsim: what kernel are you using ? + 3.12 + oh + braunr: what is wrong with it? + grep 'EXT[234]' /boot/config* + it probably uses ext4 for ext2 and ext3 + and i don't think it's possible to simply load the ext2fs module + because the options are mutually exclusive iirc + # CONFIG_EXT2_FS is not set + is there another way to copy data? + probably not + (check for CONFIG_EXT4_USE_FOR_EXT23) + mcsim: install 3.10 + http://snapshot.debian.org/package/linux/3.10.11-1/#linux-image-3.10-3-686-pae_3.10.11-1 + https://bugs.debian.org/738758 + assuming host is debian + gg0: thank you + * gg0 redirects thanks to AliciaC who caught it + gg0: thanks :) + + ## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.` ### IRC, freenode, #hurd, 2014-02-19 diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 932e11a6..496d2a06 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1346,3 +1346,85 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l irAwesome. Plan9 is exactly it. enjoy + + +# IRC, freenode, #hurd, 2014-03-11 + + Does anyone have a distributed OS over GNU/hurd project running? + (GNU/hurd has many of the utilities to make this easy, but it still + requires some more utilities for transparent computation) + not at the moment, no + and i consider our ipc inappropriate if you want system able to + run over heterogeneous hardware + or rather, our RPCs + I haven't spent the time, this is speculative (in the worse "let's do + everything magically!" way.) + Just wondering if this exists outside of plan9 (which is limited in + some ways.) + dragonflybsd had plans for a SSI + there are ancient research systems that actually did the job + such as amoeba + here at the hurd, we just don't have the manpower, and the people + spending time on the project have other interests + Yeah, that seems like a large problem. + GNU/hurd is self hosting (in the "I like working on it" way), yes? + I've done some work on it, but don't really know how nice it is. + yes it is + Working from a microkernel to add pseudo-SSI features to a bunch of + servers seems like a much more trivial task than, say, modifying TLK. + posix conformance and stability are good enough that more than 70% + of debian packages build and most of them work fine + tlk the linux kernel ? + Yes. + first time i see this acronym :) + and yes i agree, a microkernel is much much more suited for that + but then, i consider a microkernel better suited for practically + everything ... :) + :) + I'm wondering how to mix SSI with network-awareness. + mach used to have a network server + which would merely act as a proxy for capabilities + network drivers were in kernel though + That's the simple way of sharing the sources. + I'm wondering how we can make a software stack that's network aware; + completely transparent SSI can lead to inefficiencies in userspace, as it + may do things the kernels won't expect. Having to deal with the network + through a network server is a headache. + what kind of problems do you have in mind ? + Still working on defining the problem. I think that's half the + problem. + (For any problem.) + Beyond that, it's just some coding ;) + ok + sounds interesting :) + i'd love to see a modern SSI in action + but that's really a secondary goal for me so glad to see someone + making this his primary goal + doctoral thesis ? + ... Undergrad who's been hacking away since grade school. + heh :) + 18 y/o sophomore at a respected technical college, dealing with + boredom :) + well throroughly thinking about "defining the problem" is an + excellent reflex + :) stick around, the hurd is fun + it does help fight boredom a lot indeed ...... ) + :) + maybe it'd be possible to port the relevant features from plan9 now + that there is a gpl'ed version + either way, we'd need network-transparent mach messaging + which mach messaging could do, but gnumach does not implement + this currently + teythoon: afaiui if there was a proper 9fs2000 hurd server the rest + could be hidden behind the curtains + ah, well, that sounds like a 9p network filesystem translator + teythoon: also iirc plan9 uses libmach for some things so i suppose + a port wouldn't be completely impossible + given that in plan9 everything is a file, that might be enough + to use plan9 services + teythoon: yes, it'd be the easiest route (at least initially) i + believe + careful, lots of stuff is named mach-something + bloody ernest mach and his damned famous-ness-ish + =) + :D diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index fc9c2f18..1cf33091 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -958,3 +958,26 @@ See also [[nightly_builds]]. version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) user01@jessie01 ~$ uname -v #1 SMP Debian 3.11.10-1 (2013-12-04) + + +## IRC, freenode, #hurd, 2014-03-10 + + teythoon: err, i had unpacked your packages to initrd but + gnumach/ext2fs.static i was using for multiboot were debian ones + now with yours by reading system /proc/mounts (not chroot one) i get + read error: (ipc/mig) bad request message ID + mixing up things + gg0: yes, that is to be expected. the message ids for the + relevant rpcs changed "recently". i'm really sorry about that. + but in general, you should use the hurd components from one + source together + gg0: yes, that is to be expected. the message ids for the + relevant rpcs changed "recently". i'm really sorry about that. + but in general, you should use the hurd components from one + source together + + +## IRC, OFTC, #debian-hurd, 2014-03-10 + + tschwinge: i just meant Debian Jenkins provides (hopefully for hurd + too) continuos testing of debian installer, it doesn't produce .debs -- cgit v1.2.3 From b01d915cb21f7a26b444ded668c9bbeb0384fe73 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 11 Mar 2014 22:48:01 +0100 Subject: open_issues/nightly_builds_deb_packages: /proc/cmdline does work fine. --- open_issues/nightly_builds_deb_packages.mdwn | 8 -------- 1 file changed, 8 deletions(-) (limited to 'open_issues') diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index 1cf33091..cd3710ad 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -79,14 +79,6 @@ See also [[nightly_builds]]. i'll report back to you I tried adding an url= option to grub when booting the installer, but it seem to be ignored. - I suspect it did not make it to /proc/cmdline, but am not sure. - um - it should - could be. I am unable to get a shell in the installer, so I do not - know. - root@pluto ~ # cat /proc/cmdline - root=device:hd0s1 - oh ? select expert install, then spawn a shell or something 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 -- cgit v1.2.3 From e74a8ccb8c2cf082e82f3acc797dce3c77649488 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 11 Mar 2014 23:28:29 +0100 Subject: qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000010010001e --- hurd/running/qemu.mdwn | 8 ++++++++ open_issues/nightly_builds_deb_packages.mdwn | 13 ------------- 2 files changed, 8 insertions(+), 13 deletions(-) (limited to 'open_issues') diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index c22ab0ac..8c3209de 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -388,6 +388,14 @@ gnumach needs to be uncompressed ld.so.1 /hurd/exec \$(exec-task=task-create)" \ +# `qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000010010001e` + +This is due to a bug in QEMU, where the x86_64 QEMU binary fails to properly +truncate addresses in 32-bit mode. Waiting for [[!message-id +"1386334344-24620-1-git-send-email-agraf@suse.de"]] to be applied and become +generally available, just use the `qemu-system-i386` binary instead. + + # Related Links These are links that users may find helpful. diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index cd3710ad..0992b0f3 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -644,19 +644,6 @@ See also [[nightly_builds]]. well, it shows how to boot the installer not how to boot an installed system removed spaces, added option - here qemu binary is qemu-system-x86_64 instead of qemu-kvm and it - crashes without --enable-kvm - qemu: fatal: Trying to execute code outside RAM or ROM at - 0x000000010010001e - rather use qemu-system-i386 - i was just complaining i wrote qemu-kvm on wiki but i did never - actually run that command as is - ouch right, -i386 doesn't require enable-kvm - (i'll never know why) - -x86_64 is buggued - 0x000000010010001e should have been truncated to 0x0010001e since - it's 32bit mode - i see any luck reproducing mtab issue? still not -- cgit v1.2.3 From efdbd8e0de4d781d53ffb7a5833220c37739a568 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 12 Mar 2014 00:05:16 +0100 Subject: QEMU multiboot. --- hurd/running/qemu.mdwn | 34 +-- open_issues/arm_port.mdwn | 73 +------ .../debugging_gnumach_startup_qemu_gdb.mdwn | 41 +--- open_issues/nightly_builds_deb_packages.mdwn | 241 ++------------------- 4 files changed, 41 insertions(+), 348 deletions(-) (limited to 'open_issues') 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 +# Multiboot -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, +download: - $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/{gnumach.gz,initrd.gz,ext2fs.static,ld.so.1} + $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/{gnumach.gz,ext2fs.static,ld.so.1} -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)',\ + > 'ld.so.1 /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),\ - ld.so.1 /hurd/exec \$(exec-task=task-create)" \ - # `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, +Inc."]] [[!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. matty3269: I think that's better than starting on real hardware. tschwinge: you can use -kernel with a multiboot binary now + +[[hurd/running/qemu#multiboot]]. + tschwinge: and even creating iso images is so fast it's not any slower - braunr: Yeah, I thought so, but never checked this out -- - recently I saw in qemu --help's output some »multiboot« thing flashing - by. :-) - i think it only supports 32-bits executables though - braunr: Yeah, I just tried passing gnumach as the -kernel - parameter to qemu, but it segged qemu :S - otherwise i'd be using it for x15 - qemu: fatal: Trying to execute code outside RAM or ROM at - 0xc0100000 - how much ram did you give qemu ? - I used '-m 512' - hum, so the -kernel option doesn't correctly implement elf loading - or something like that - anyway, i'm not sure how well building gnumach on a non-hurd - system is supported - so you may want to simply develop inside your VM for the time - being, and reboot - doing an objdump of it seems fine... - ? + ah, the gnumach executable is a correct elf image - that's not the point Is there particular reason that mach is linked at 0xc0100000? or is that where it is expected to be in VM> That's my understanding. @@ -192,21 +177,6 @@ architecture. 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) - Surely the GRUB multiboot loader is not that much used/tested? - unfortunately, no - matty3269: FYI, my kernel starts at 0xfff00000 :p - braunr: hmm, you could be right, I know it's arround there - someone - somewhere* - braunr: that's an interesting address :S - braunr: is that the PA address of the kernel or the VA inside a - process? - the VA - hmm - it can't be a PA - such high addresses are normally device memory - but don't worry, i have good reasons to have chosen this address - :) so with gnumach, does the boot-up sequence use PIC until VM is active and the kernel mapped to the linking address? no @@ -217,37 +187,6 @@ architecture. and uses offsets when accessing data (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB) hmm, - gah, I need to learn x86 - that would certainly help - 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...? - mode* - have a look at the multiboot specification - it sets protected mode - but not paging - (i mean, the boot loader does, before passing control to the - kernel) - Ah, I see - matty3269: Multiboot should be documented in the GRUB package. - tschwinge: yep, got that, thanks - hmm, I can't find any reference to CR0 in gnumach so paging - must be enabled elsewhere - oh wait, found it - $ git grep -i '\' - i386/i386/proc_reg.h, linux/dev/include/asm-i386/system.h - although i suspect only the first one is relevant to us :) - Yeah, that seems to have the setup code for paging :) - I'm still confused how it could run that without paging or PIC - though - I think I need to watch the boot sequence with qemu - it's a bit tricky - but actually simple - 00:44 < braunr> either special sections are linked at physical - addresses - 00:44 < braunr> or it relies on the fact that all executable code - uses near jumps - that's really all there is 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 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]]."]]"""]] # Multiboot -See also discussion about *multiboot* on [[arm_port]]. - - -## IRC, freenode, #hurd, 2013-10-09 - - 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"? - matlea01: you need something with multiboot support (like grub) - to provide the various bootstrap modules to the kernel - 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]]. you may use gdb for that for bochs, you don't have to use external debugger thanks for explain - does anyone succeed boot hurd with qemu multiboot boot - function? - with -kernel and -initrd command line parameter - I boot it with grub, in qemu, it's fine. Then I moved to - physical machine - boot with grub work for me too - I want to know whether it is possible to boot from qemu - directly - qemu can directly load kernel and hurd module for linux - nalaginrut: can you help to test whether hurd-console service - start will cause hurd black death? - I know qemu can boot Linux without MBR, but I don't know if - it's true for Hurd too - congzhang: I'm busy for other works now ;-) - ok, thks:) - qemu's multiboot options don't seem to allow providing - ext2fs.static and ld.so, so I don't think it's possible - I try to do this, because hurd hurd-console cause system to - death very high frequency - (because qemu doesn't implement all of multiboot) - qemu help show that's possible, -initrd support multi module - and parameter - en, I will check with them later - how do you pass parameters to modules? - ah, right, it's after the file name - well, then simply try to pass the kernel, and the two modules - with the same option as in the grub config templates - 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]]. 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 +[[hurd/running/qemu#multiboot]]. + +For d-i purposes, you'll additionally need: + + $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/initrd.gz + +..., 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`. + 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 @@ -84,8 +84,6 @@ See also [[nightly_builds]]. 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. :) @@ -112,158 +110,8 @@ See also [[nightly_builds]]. #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 @@ -271,7 +119,6 @@ See also [[nightly_builds]]. 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? @@ -321,10 +168,6 @@ See also [[nightly_builds]]. ## 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 @@ -619,31 +462,11 @@ See also [[nightly_builds]]. possibly oh wait here qemu multiboot that shouldn't have any impact - did you leave the command line somewhere on the wiki so I can try - with it, just to be sure? - - http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot 5€ on qemu multiboot as the culprit you should also see it sometimes double-mounts /dev/hd0s1 under /target and /target/./media/cdrom(!) but that's due to new apt it in-targets (= installs under /target) - gg0: rather use the gnumach, ld.so and ext2fs.static from the ISO - image you are booting - especially for ld.so, which has to be the same as the libc - installed in the initrd - ah, you're getting the initrd there too - well, really use the same as the ISO - i already do - ah, ok, so the wiki example is just with current - but the wiki example doesn't use -cdrom to provide the ISO ? - no it doesn't even mention you could also use a cdrom - it just shows how to use qemu multiboot options - it seems one have to avoid any blanks in the multiboot option - notably before file names - well, actually it works but it's rather incomplete - well, it shows how to boot the installer - not how to boot an installed system - removed spaces, added option + any luck reproducing mtab issue? still not @@ -781,7 +604,7 @@ See also [[nightly_builds]]. Resource lost didn't manage to reproduce so far environment is pretty the same: booting with qemu multiboot - http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot + http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#multiboot so root on initrd + chroot on real disk what's weird is that issue vanishes by removing console=com0 from -append options @@ -820,19 +643,14 @@ See also [[nightly_builds]]. zero everytime first thing to do when developping is first take the time to find ways to work efficiently - i'd want to try multiboot with teythoon's gnumach/hurd but boot gets - stuck with old initrd unfortunately I had to apply some patches first in d-i because isc-dhcp doens't work -> use the debian-ports version - so i could simply copying whole /hurd dir to new initrd - -ing then in d-i to automatically enable the debian-ports mirror and last in the debian-cd to include debian-ports-archive-keyring - you'd also need to copy the libs + anything missing here? http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i - libc0.3 on initrd is still 2.17 mini.iso doesn't like any mirror "mirror does not support the specified release" something wrong/missing in my rebuilt @@ -862,22 +680,6 @@ See also [[nightly_builds]]. ## IRC, freenode, #hurd, 2014-03-09 - http://postimg.org/image/oca8ormaj/ - with teythoon's repo too ^ - - -## IRC, OFTC, #debian-hurd, 2014-03-09 - - ok i'm out of tests, i get Resource lost with teythoon's gnumach/hurd - packages in initrd too - http://postimg.org/image/oca8ormaj/ - thread storms, dead locks, resource lost - i find assonance - - -## IRC, freenode, #hurd, 2014-03-09 - - gg0: strange teythoon: shouldn't there be a patch which shows pid instead of task? 20:43 < teythoon> task /hurd/procfs(19) O deallocating an invalid port 1049744, most probably a bug. @@ -939,23 +741,6 @@ See also [[nightly_builds]]. #1 SMP Debian 3.11.10-1 (2013-12-04) -## IRC, freenode, #hurd, 2014-03-10 - - teythoon: err, i had unpacked your packages to initrd but - gnumach/ext2fs.static i was using for multiboot were debian ones - now with yours by reading system /proc/mounts (not chroot one) i get - read error: (ipc/mig) bad request message ID - mixing up things - gg0: yes, that is to be expected. the message ids for the - relevant rpcs changed "recently". i'm really sorry about that. - but in general, you should use the hurd components from one - source together - gg0: yes, that is to be expected. the message ids for the - relevant rpcs changed "recently". i'm really sorry about that. - but in general, you should use the hurd components from one - source together - - ## IRC, OFTC, #debian-hurd, 2014-03-10 tschwinge: i just meant Debian Jenkins provides (hopefully for hurd -- cgit v1.2.3