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