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