IRC channel logs
2026-04-24.log
back to list of logs
<damo22>any translator added by debootstrap should be removed by debootstrap? <rrq>well, debootstrap only creates the filesystem; would be "pbuilder destroy" or something doing it <rrq>is it really needed in a chroot? <damo22>rrq: yea but if debootstrap adds a translator it needs to clean them up when it completes <rrq>yes maybe it's that; I'll need to check that <damo22>rrq: i just sent you a private message about something <rrq>yes, attempt is made with "umount_on_exit /servers" which doesn't work since /servers isn't a mount point <rrq>or does(/should) /hurd/firmlink work as a mount point? <rrq>.. otherwise it looks like it would fail on unmounting /dev too <damo22>have a look i think there is a hurd specific method for umount <damo22> hurd: Add umount_on_exit for {proc,dev,servers} <rrq>I tried things manually and the debootsrap setup seems it should work... perhaps something installed sets up /servers/acpi as well making it seem "stacked" <rrq>well, "shadowed" actually <damo22>if you remove a translator on /servers it probably does not remove any active translator on /servers/* <rrq>no it shadows them rather <rrq>would there be any package that creates /servers/acpi (and sets a translator) <damo22> # Use the setup-translators of the hurd package <damo22> in_target /usr/lib/hurd/setup-translators -k <damo22>maybe that should only run if TARGET == / <rrq>yes that looks right; though that all raises the question how this is intended to work with namespaces (if/when that is a thing) <rrq>no; but intuitively when I do a debootstrap I would expect it to become an isolated filesystem tree; eg. I do it on a USB na dthen move that USB elsewhere <damo22>if you are bootstrapping a chroot to be bootable, you need the translators to be created passively but not set to be active <rrq>my nmaespaces refers to linux <damo22>and the symlink to dev and servers allows the underlying hurd to provide the devices for bootstrapping to work <damo22>so it kind of looks right to create the translator entries first in the chroot and then symlink to dev and servers <rrq>yes, though in "container" thinking I wouldn't want there to be reach-out outside of the container <damo22>but maybe the "setup-translators -k" call actually sets active translators <damo22>because they would still be active after the firmlinks to dev and servers are removed <damo22>i am talking about the case where you are debootstrapping from hurd -> hurd <rrq>yes I guess it'd rather require tear-down scripting <damo22>i think the setup-translators script needs an option to only create passive entries <damo22>then nothing needs to be torn down <rrq>ACTION just learnt more about translators :) <damo22>"settrans -p" installs the xattr but doesnt launch the translator <rrq>is there a test predicate? <rrq>for showtrans to tell whether a translator is active or passive <damo22>showtrans just displays the xattr <damo22>i dont think you can query for an active-only translator and see what is installed on a node <rrq>mmm an -p installed translator activates itself automagically? <damo22>yeah, if it is installed with -p then the xattr entry is created on the target node and the translator will auto fire up when it is needed <rrq>hmm can it be "stopped" while keeping the xattr ? <damo22>then it will auto fire up again when needed <rrq>mmm do I know which process if there are several pathnames having the same type of translator? <rrq>not sure the -p setup is good ... it will still block deletion since the translator starts automagically just by traversing the pathname <rrq> a "passive" translator is one that doesn't start automagically ? <rrq>or does active/passive refer to the usage rather than an attribute of the translator? <damo22>if you set xattr entries only (passive) then overlay the /dev and /servers from underlying hurd, nothing will have a chance to access the entries <damo22>maybe rm needs to somehow not trigger a translator to start <damo22>on any nodes it is trying to remove <rrq>mmm kind of does nibble at the idea of translators as "transparent" <rrq>but maybe I know too litle about translators... I'm a linux head and kind of think of them as fuse mounts <rrq>that doesn't add much to my confusion; seems like active/passive is merely a runtime state of a translator associated with a pathname (though described in a rather akward ways as an attribute of a translator) <rrq>is there a way to query a pathname whether or not there its translator is active? <rrq>and is there a way to find out which pathname a tranlator process is active for? <rrq>ACTION is a linux head so will require lots of learning (and unlearning?) <Darelelve>I don't think there's much to unlearn, since both systems are posix-compliant. :) <kilobug>rrq: a "passive translator" is just an information in the filesystem that informs the Hurd to run a translator when the path is accessed, an "active translator" is a running process that can answer to filesystem-like calls from other processes <kilobug>and yes, you don't need to "unlearn" much from GNU/Linux to switch to GNU/Hurd, just to learn a few additional things <etno>rrq: fsysopts can be useful to query the active translator for a particular node <etno>Since usually the attach path is the first argument, you can find the "mount point". But I don't think that it is guaranteed. <etno>To me, this is part of the beauty of Hurd ; the framework has only very few constraints. <etno>(also, sometimes conventions are handy ^^') <rrq>yeah, "beauty is in the eye of the beholder" ;) <rrq>I belive damo22 pointed to the problem with debootstrap, that firstly it sets translator for the individual $TARGET/servers/*, and then it sets a "fimrlink" translator at "$TARGET/servers" which shadows those previously set up. <rrq>and also resulting in that the debotstrapped filesystem is not like a selfcontained root filesystem, but it has a firmlink out to the host filesystem <rrq>both of those are, in my eyes, aspects of badness although it doesn't reflect on degree of beauty of the principle of hurd as an OS <etno>I did not follow the conversation, so I might be missing some important info, but it sounds as if the de bootstrap was doing something like a chroot, while a subhurd would be more appropriate ? <rrq>I'm using pbuilder, and wouldn't want to change that software <etno>To be honest, I am not sure how the servers are handled in subhurds (except the network devices, which are the easy one I guess) <etno>I don't know what pbuilder is, sorry ^^' <rrq>it's used for building packages without residual pollution of the host filesystem <rrq>and a build chroot doesn't need many host resources <jrtc27>it would be nice though if hurd could abstract this somehow, rather than having to maintain a magic list of things to clean up <jrtc27>(whilst there is a long list of things to unmount for linux/freebsd/hurd, that's all things that pbuilder itself mounted, so there are at least no surprises in terms of new things popping up after the chroot is created) <jrtc27>(though you do still need a magic list of the things the chroot needs to exist to run) <rrq>yes; debootstrap has the hurd magic that makes the 328-330 cleanup necessary, which I think it shouldn't have <rrq>with out that hurd magic, that cleanup wouldn't be needed <rrq>I'm not clear there is a use case where that hurd magic is of use... it looks to me like residue from successive patching od debootstrap <rrq>perhaps that hurd magic is need if deboostrap targeting hurd is used on a non-hurd OS