You might find sbuild useful (bash only). It creates an overlay-fs of the current running system in a chroot, but it could be adapted for an ISO situation.

1 members found this post helpful.

Creating a chroot has far too many extra steps when compared to lxc, which is installed in a full installation of Slackware. It can get tricky with unprivileged lxc containers, but those aren't necessary for testing slackbuilds.

From my notes:

To add networking, not always necessary though, can edit /etc/lxc/default.conf and then /etc/default/lxc-net like so:
Invoke the lxc-net script as root AFTER your firewall script has already been applied to iptables
(You can put that into /etc/rc.d/rc.local)
With a full installation of Slackware, the rest is of the networking configuration is handled for you by software shipped with Slackware. You can then begin making as many containers as your hard disk will support.

Create as root a very basic slackware64-current container, very basic.
This is what I use:
You can point lxc to a specific mirror you wish to use to download the base system.
lxc is extremely flexible and can be customized at the command line by setting the internal Slackware template variables to whatever you want with varied results.

There is awesome documentation about lxc on Slackware on SlackDocs and also on Chris Willing's web site.

-https://docs.slackware.com/howtos:misc:lxc
-https://www.chriswilling.com/lxc/

Once you have it all configured you can forget about the effort it took. Creating a container is quite easy.

1 members found this post helpful.

Until after Slackware 14.1, I didn't always have to rant about why I only wanted to use chroot and am not going to use emus/VMs (except for other things,) nor docker, nor lxc, nor 'containers,' nor overlayfs... don't know much about most of those; don't care.

To read more my reasons you can see the newer thread someone started (years aftxer this one still isn't 100% resolved) because they want to chroot for SlackBuilds. That is not my only reason; I have many reasons, one including that I just want to understand chroot as a common tool on many OSes, just as sh is a common tool.

I don't plan to use lxc because I don't have cgroups running (but might months/years in future if there are no tools like cpulimit/cputool but as gpulimit/gputool... because heard people are setting up cgroups for similar usage.) I don't know about overlayfs or why it would benefit me, but that and the rest (most/all which are overkill) are off-topic; for other threads. That's great if other people found newer things to work better: they should write an article/thread on those.

I know enough about chroots that if I know a little more I'll know enough to use for all these situations (and others... but still want to know more about how it works in an abstract/code sense, and how it might work on other strictly Unix-like OSes and such OSes that can be configured for different basic setups that change chroot usage.) All these other off-topic things are newer things that would take a lot more learning/memorization to begin to be an expert to that extent, but I have more urgent things to learn (other mathematics/computer-science topics.)

Of course, if full details of how one might have to mount cgroups and what might happen, aren't explained before the next stable release of Slackware, I'll be starting a new chroot thread for that version, or if there are any new default mountpoints. If not, I guess I might have to just stay away from this topic except maybe on Usenet or IRC where many people in some places don't want to use newer things... not even the official slackpkg manager!

Back to my original topic, I think I might've copied this line--from somewhere else, incorrectly--into my script after looking at orbea's commands.

That's incorrect for Slackware, right?

update:
Though, now I am also a bit intrigued by lxc and anything one could also boot an OS in... Xen, unsure about overlayfs or other containers/etc. (forget docker.) It'd be interesting to see if I could do something similar on FreeBSD and boot Slackware within (might have to be Xen, not something like lxc or jails)... or vice-versa, or boot Qubes in one or the other also, then other OS in that you couldn't put in a container or jail... of course this sort of thing is for another thread entirely, so please don't change topic by replying here; I won't get to those anytime soon.

Also, nevertheless, I still want to learn more about chroot... drumz' and dive's ideas looked particularly helpful, but I do most of that my own way... what I'm wondering most about is what needs to be mounted in different situations, how it's mounted, how your shell gets isolated, and why newer OSes do it (like my line above, maybe from a systemd OS(?) I temporarily used for amdgpu-pro, now erased that OS after Slackware's amdgpu-opencl thread) differently (but don't care to learn how most do it.) Newer tools would have to do something amazing for me to even start reading much about them.

As for running any other GNU/Linux in a chroot or similar, as long as they can use same kernel, and same /dev, /proc, /sys, /tmp, you don't need much else (like I know sbopkg used to have a Debian chroot, now might only work for Devuan, which I wouldn't use on my PC, but maybe a cheap server they didn't offer *BSD or Slackware)... in the case they have a different initialization system, maybe... but as said, won't be getting to that anytime soon. Other than doing more of my own mathematics/programming, I just like learning Unix tools... most of these new things aren't, but chroot is (so still learning it and other Unix tools first.)

dchmelik, the mount command you showed:

`mount -t proc ...`

creates a new mount, which I've seen used by some people for a couple of the special directories, but I don't know why using bind:

`mount -o bind /proc /path/to/chroot/proc`

can't be used. Perhaps someone knows why it's better to create a new mount instead of binding in this case? AFAIK binding is similar to the notion of symlinking, and just points to the original directory.

I'm with you as far as using chroots go. I want to keep things as simple as possible.

(I do have a -current VM using libvirt+qemu, purely because of different kernel versions that I need to keep separate to the host machine. I start and stop it with the virsh command, and then ssh into it, so 99% of what is do is purely CLI, and don't often need to start X.)

I am intrigued by the idea of overlays though, so I will see what needs to be done in the simplest way possible. It looks like making an overlay is a simple `mount -t overlay` command, with a few options, over the top of the chroot directory before chrooting into it. The mount man page doesn't mention overlay at all as a fstype though, so I need to look for docs elsewhere.

Supposedly, one can specify a `changes` directory that shows any changes in the chroot and it's possible to reset it to how it was before using it. This would be a great idea when testing slackbuilds. It's easy to make a simple typo and delete/clobber files outside of the package directory (I once managed to nuke /usr/share, which is the main reason I created mkslack that uses SBo templates and helps eliminate typos.)

1 members found this post helpful.

From orbea's orignal post:
He's using a bind mount, not creating a new proc filesystem.

I know the OP is against looking at solutions with newer technologies but the overlayfs type is supported in the kernel and would provide a very convenient way to maintain a clean build environment.

Basically an overlayfs mount is like a bind mount except that files from both filesystems are available, whereas a bind would only show the contents of the mounted system. The filesystems are distinguished as a "lower filesystem", which is read only, and an "upper filesystem", which is read-write. When you chroot into the overlay filesystem, all changes are done to the filesystem that is read-write, and the lower system remains unchanged. You could keep a pristine root filesystem for the lower fs and perform all changes and building in a separate upper fs. Any changes done can easily be separated afterwards. Kind of like you were building in a "live USB" environment that can always be reset to initial state (live distros use overlayfs, you can see that in Eric's liveslack scripts for an example).

Here's a short read on overlayfs that I thought were informative.
https://www.grant.pizza/blog/overlayfs/

1 members found this post helpful.

I think I am still the only one using overlayfs instead of aufs in a Live distro. Unlike overlayfs, the aufs setup allows for inserting and removing live modules during run-time. With overlayfs you need to do that on boot and then it's fixed until shutdown.
But, aufs is not part of the kernel and overlayfs is, which means Slackware Live Edition can be built with only Slackware packages.

1 members found this post helpful.

Well I stand corrected then. I'll admit that my only "live distro" experience comes from looking through liveslack so I assumed that overlayfs was in wider use than it is. I can see the appeal of aufs for the live distro use case, but I understand how that doesn't work with the slackware-mirror to working usb-drive approach of liveslack.

I didn't mean orbea specifically, but I remember someone starting new filesystems for 2 of the special directories. I'm not going to wade through the posts to see who it was.

Thanks for the link. I'll have a read up.

1 members found this post helpful.

You've disabled private messages so I'm posting a very short reply here. I hope you don't mind.

Over the years you've expressed an interest in this kind of thing on several occasions so I thought you might like to know NetBSD 9 ships with a new virtual machine monitor, nvmm. See here and here, for an introduction. I think it's the most promising of the BSD virtualisation platforms. I've heard that Xen is a second-class citizen on FreeBSD.
.

1 members found this post helpful.

I do this as well.

After replies above, I still really want to learn all I can about chroot because it's a standard Unix tool; don't know what else is... nevertheless, in the case of Slackware, I think I'll be switching to a chroot plus overlayfs only for the case of updating my SlackBuilds (just had to wait until I saw overlayfs, etc., explained in more detail, because I had no idea what some of this new stuff was but people were talking about it like I maybe already knew.) Of course, there are other cases.

Yes; I used to be getting a few messages from 'Nigerian scammers' and similar-speaking anonymous ladies supposedly looking for dates.

That's interesting, but I'd probably only use NetBSD on something FreeBSD or Slackware wouldn't boot on; got used to regular official and unofficial (or quasi-official) updates with Slackware, and FreeBSD is similar... on NetBSD you have to wait like for each season... which may lead to more stability, but I'm okay not having that a little with new packages... though I still suspect NetBSD has the most stable kernel on the planet.

@dchmelik
for loop can strip some lines:

1 members found this post helpful.

Thanks for the recent updates in the newer thread about Slackware SlackBuilds chroot.

For the other, theoretical case of chrooting into Slackware in a case one might not use a Slackware install/live media, I feel okay about chroot now. I think I'd just come back here and look what orbea said. The question is if it'll always work or some installation/live discs might have different systems. For example, sometimes I was booting two GNU/Linux... I might boot one they mount differently but want to chroot into Slackware... or (hopefully not) maybe a Slackware installation/live disc couldn't boot a system I messed up, but maybe something like SystemRescueCD or similar (someone mentioned Antix once in a way that was off-topic, and I said they lacked Slack, which was still a reasonable response for that thread, but just saying, there might be different utility/repair discs... others might run GParted, FlashROM, etc.) so in the case I run some utility/repair disc I might still want to chroot in.

Maybe above or in another thread I mentioned other examples. Another might be to chroot into an old Slackware. I still have a SlackBuild that only works on an older version, and similarly, some were removed from SlackBuilds.org (SBo)... and I don't recall if all old Slackware even left things setup to chroot after exiting installation from a disc... I seem to recall some years/decades ago learning to do it myself but making mistakes I had still been wondering about (and now there were new mount points, not relevant to that case)...

So there are always usually multiple reasons just for the simplest chroot... this thread was never about SlackBuilds only... in fact, my SlackBuilds are so simple, for most of them, I don't even need a chroot, because they don't have dependencies. One or two that do are either old (maybe won't work on next stable release) or it's only a couple known dependencies... almost no reason to setup an entire chroot for SlackBuilds... nevertheless, in the future, I think of myself doing so, but that never actually was my primary reason for the thread (rather than chroot because it's a Unix tool)... nevertheless, thanks for finally explaining how other tools (overlayfs) would seem to make chroot better for certain situations...

EXCLUDING developing SlackBuilds, but back to this topic, let's say I want to run a Slackware installation/recovery medium chroot--because it's Unix-like--and as such, for utility/testing. The most common reason might be to redo/repair LILO. Another reason might be to try a Slackware version on a system with FULL SETUP before you decide to keep it and maybe before your first reboot, maybe even some months later. How would you go about these? Finally after some partly-ridiculous/-off-topic answers, orbea gave a straight honest answer, but much remains to be said...

Such as... let's say you do the second option: install but don't want to reboot, but you want to use everything that could be mounted on a standard Slackware (and optionally from SlackBuilds.org, which has package managers, but without getting into into tertiary/non-Unix-like things like certain new/Apple-/Windows-like package managers that for every package, install a virtual filesystem, appearing in mount, even if that's potentially 40,000+ mounts.) We've discussed a little that since 14.2, cgroups are mounted--do you need those for desktop? On Unix or other Unix-like operating systems (OS) I've seen /var/run mounted, so presumably perhaps /run ... but is that all? I'm also interested in the case of servers, and though I don't do a lot with those right now, the whole process should be detailed... what other directories might potentially be mounted on a Slackware workstation or server just after installation, without too much difficulty?

The chroot threads always get derailed, so let's keep this to the two cases I mentioned. If you have other tools, fine: you can let me know when they're part of the POSIX standard (and endorsed by respectable old school Unix hackers/academics/professors) and invite me to consider reading new threads on those, but I'll still want to know more about chroot (first things first; basic tools first: ‘KISS.’)

I've successfully followed the steps I outlined in this post last weekend.

The only addition I would suggest is to chroot into the base directory and get your initial setup done (add a user, update Slackware, maybe install sbopkg, etc).

You'll also need to update your certificate store (/usr/sbin/update-ca-certificates --fresh) and either bind mount your /etc/resolv.conf or manually add a namerserver into it (I did the latter).