From de3f3f6cc52d1e5013e85137d09f2ac23e657858 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Mar 2014 20:10:58 +0100 Subject: IRC. --- hurd/translator/mtab/discussion.mdwn | 138 +++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) (limited to 'hurd/translator/mtab/discussion.mdwn') diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 89593436..c3c43f43 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -3046,3 +3046,141 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? teythoon: ok teythoon: i let you fix that :p braunr: sure ;) + + +## `chroot` + +### IRC, OFTC, #debian-hurd, 2014-03-05 + +In context of [[open_issues/nightly_builds_deb_packages]]. + + installer gets stuck running os-prober, seems because + /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it + gets stuck reading it + there are two proc translators: one /proc, one /target/proc + anything known that could have broken /target one? + anything else to check? + what's unusual is that cat'ing /proc takes few seconds before giving + output. does initrd slow down things? + */proc/mounts + what does "Resource lost" mean? i get it since the beginning of + install + + +### IRC, freenode, #hurd, 2014-03-05 + + debian installer mounts installation disk under /target then probably + it debootstraps on it + we have 2 procfs: one outside, one inside /target + outside it works fine, inside cat'ing /proc/mounts it gives Resource + lost the first time. the second one it gets stuck + oh there's only one /hurd/mtab though. inside one might have bought + the farm, correct? + ? + two /proc/mounts means you have to have two mtab translators afaiu + i can't reproduce on a clean chroot + gg0: two mtab instances should be fine + also, the one under /target should only list translators "under + "under" /target + teythoon: yeah i restart the dead one but at first access i get + "Resource lost" again and mtab dies + hm + wait + "Resource lost" means mtab is not running + are you sure ? + the mtab translator queries other translators + that can lead to the delay you described + and severe enough errors are handed back to the client, e.g. if + mtab itself gets resource lost on the very first translator it queries + i'd like to clean up chroot proc and mtab stuff but settrans -fg gets + stuck + or it gives + settrans: /proc/mounts: Computer bought the farm + settrans: /proc/mounts: Operation not supported + gg0: try settrans --recursive ... + then again, i never used this and it should work without, no ? + same behavior + root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts + settrans: sid-chroot/proc/mounts: Computer bought the farm + root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts + settrans: sid-chroot/proc/mounts: Operation not supported + root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts + hm + (last got stuck) + eh, i thought of settrans --recursive -fg sid-chroot + i doesn't work. it gives no output but showtrans shows translators + didn't go away + showtrans shows passive translator records + ah + better use fsysopts to query the active one + both still active, even with fsysopts + hm + i recently improved the mtab translator, but that change has not + made its way into debian yet + * gg0 adding hurd-ci + +[[open_issues/nightly_builds_deb_packages]]. + + btw Resource lost/mtab dying i can't reproduce on hurd01 seems + breaking debian installer + teythoon: dist-upgraded hurd-ci, it behaves pretty same way besides + settrans -fg sid-chroot/proc/mounts gives "Operation not supported" right + away, without "Computer..farm" first + following attempts it simply gets stuck + time to quickdraw gdb :p + teythoon: i think easy to reproduce, just need to debootstrap + anything stronger than -fg? + kill + well mtab has been already manually killed + i could kill procfs too + yes, but then it seems to me that the translator linking in + netfs is buggy + kill -KILL :p + :D + aka double kill + ok by killing chroot procfs then accessing sid-chroot/proc/mounts + makes both restarting + ok, even more likely to be a netfs issue then + which is to be expected + afaik procfs is the first netfs based translator to support + passive translator records + it is + did the same on debian installer machine: both restarted, cat + /target/proc/mounts -> Resource lost + and mtab died + Computer wanted to buy the farm but it was out of resources + + +### IRC, OFTC, #debian-hurd, 2014-03-05 + + btw problem is cat /target/proc/mounts gives Resource lost, what + package could cause that? + and mtab dies + Resource lost often means the same as Computer bought the farm: + some translator has died somehow + or dropped something + procfs+mtab outside /target work well. inside mtab crashes + http://postimg.org/image/vgz541z81/ + tbh i unmounted a couple, they are not all fs mounted by install, a + couple missing + could any of them cause mtab crash? + see ldd /hurd/mtab + it only uses hurd libraries and pthread + hurd libs and pthread _outside_ chroot, right? + in principle it's the outside /hurd/mtab which gets triggered + since the /target ext2fs doesn't know people use it chrooted + do you have two processes? + (mtab processes I mean) + yes two mtabs children of their two procfs + k + and does setting up an mtab translator by hand gets the same? + to restart mtab i have to kill its father procfs + tell that to teythoon, not me, he implemented the thing :) + then first access to /proc/mounts should make procfs and mtab restart + yeah there's already been some troubleshooting on #hurd + youpi: i suspect some bugs in netfs translator linking + procfs is the first netfs based translator to make use of + passive translators + you can see dead mtab and os-prober trying to grep /proc/mounts + http://postimg.org/image/z4fm981p7/ + well, there can't be problems on /target if there's not /target yet -- cgit v1.2.3