void-docs
void-docs copied to clipboard
void-linux
[WIP] chroot-rootfs: Add section.
We do have xtool's xvoidstrap + xchroot, which do basically those steps. How do you feel about recommending them?
I'd mention you should create and populate the directory as root, otherwise permissions tend to get weird. And I'm not entirely sure how we could fit xbps-uunshare as a non-privileged tool, or even if we need to.
In order to run graphical applications (imagine a steam chroot on a host musl system) one must also mount /tmp (for X11 and Xwayland) and/or /run (for Wayland). EDIT: Whoops sorry run is already there, but not tmp
how about extending it to be more generic regarding target architecture?
building a bootable image (either same arch or foreign arch, like rpi ) involves some of the same steps but you install base-system (or rpi-base) instead of base-voidstrap
but you install base-system (or rpi-base) instead of base-voidstrap
I don't think this is true if you're not building a bootable system. rpi-base includes a kernel, which you definitely don't need in this situation. There might be something else in there that you need to get it working though?
Just to be clear, @Duncaen's comment that led me to create this section was:
I was thinking more about a "How to setup Void Linux container/chroot rootfs", which I think is useful and quite different from installing void linux on bare metal using a chroot.
There's a good chance i've misinterpreted @Duncaen's comment, but i assumed what was meant was a page about setting up a chroot on an existing Void installation (e.g. a glibc chroot on a musl system, currently in the Handbook here). Installations via a chroot will be covered by #177 (which is almost complete, and which i feel will be a crucial addition to the Handbook), and then by further work leveraging #177 to address #85.
@ericonr: i wasn't aware of xchroot as part of xtools, as even though man xchroot takes me to the xtools man page, there seems to be no mention of it? (And the layout of the xtools man page on man.voidlinux.org is impressively broken.) Given what i've written above, is it a tool that can be used in this context? If so, the xtools man page will need to be updated, and of course, the xmandump stuff will need to be resolved so that we can point to the updated man page.
To what extent should the handbook document what to do with a chroot? glibc compatibility on musl definitely makes sense (apart from already being in the handbook) because very few distributions support musl. Other uses might include running x86 binaries on x86_64 distribution (maybe this should go in the multilib page?) and creating jails for non-trusted users (if this is still good advice with docker and lxc around?)
eta: Maybe also include a warning that you need to run xbps inside the chroot to keep those packages updated, independently of the host?
@flexibeast master of xtools has a reference to xchroot. It should be usable in that context, but perhaps we can mention it as a "tool that automates this process", and still document the process. I have updated xmandump, and maldrige is working on getting it up and running c:
@st3r4g you'd need to bind-mount /tmp for X11 to work, right? In that case, xchroot is definitely not the tool.
the wiki said to install xhost and run xhost +local:, it worked, but I don't know all the implications of that. Bind-mounting /tmp (or maybe just the X socket inside tmp) seems a better suggestion, do you agree?
@st3r4g if xhost "just works", it might be a better solution. Did you test how well bind-mounting /tmp worked? It is a more complicated step and can be easy to get wrong, I think.
Yes, I'm currently using a script that binds mount /tmp too, that way I also get /tmp to be a tmpfs inside the chroot. I don't think is more complicated really
I'm not sure what I'd prefer to see here, and also don't know what's safest/more correct. Thanks for testing :p
Referring to xvoidstrap and xchroot does seem to be the way to go, although there seem to be a few blockers involved:
-
xchrootdoesmount --rbind /proc "$CHROOT/proc"; mount --rbind /sys "$CHROOT/sys"rather than themountcommands described by @q66 in this comment. i don't know if the source forxchrootneeds to be changed, or whether instead it's fine for the contexts in which it's intended to be used. (What are those contexts?) -
At any rate, there needs to be a release of
xtoolswhere the man page referencesxchroot(which it does onxtoolsmaster). -
The layout of the xtools.1 man page on man.voidlinux.org needs to be fixed.
- latest version with
xchrootin the man page was released a few days ago - I opened an issue about the layout here https://github.com/leahneukirchen/xtools/issues/184, but we don't know what's causing it
To help keep track of what needs to be done in relation to this section, a list:
- [ ] Mention need to mount
/tmp, unless it should be done viaxchroot(cf. this comment) - [ ] Ensure section is applicable to multiple architectures (cf. this comment and this comment)
- [ ] Confirm whether the source
xchrootneeds to be modified re.mountcommands (cf. this comment) - [ ] Confirm appropriate use of
xhost(cf. this comment) - [x] Fix layout of
xtoolsman page on man.voidlinux.org (cf. this issue) https://github.com/leahneukirchen/xtools/pull/187 - applied in https://github.com/leahneukirchen/xtools/commit/4c90f10f80141e5fd5a1a61034b9971a7c6b3014
I think we should leave /tmp as a manual mount. xchroot doesn't need to always do it, and a user can choose to either have it as a separate tmpfs or as a bind mount. For this use case, it should be a bind mount.
I believe installing base-system is enough. I have a glibc chroot on my musl RPi. If you need graphics support or something, then you can install rpi-base - even then, I don't believe it's needed.