LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-17-2020, 11:14 AM   #16
drgibbon
Member
 
Registered: Nov 2014
Distribution: Slackware64 -current
Posts: 651

Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423

Quote:
Originally Posted by dchmelik View Post
I still want to try the pure chroot tools (scripts, not combined with other tools I don't need like all those 'containers,' etc. people always mention instead)...
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.
Old 05-17-2020, 09:04 PM   #17
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware, OpenBSD, Linux From Scratch
Posts: 1,412

Rep: Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781
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:
Code:
#lxc.network.type = empty

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.name = eth0
Code:
USE_LXC_BRIDGE="true"
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)
Code:
/usr/libexec/lxc/lxc-net start
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.
Code:
lxc-create -n test1 -t slackware
This is what I use:
Code:
lxc-create -n slack64-14.2 -t slackware -- --arch=x86_64 --release=14.2
OR
lxc-create -n slack-14.2 -t slackware -- --arch=i486 --release=14.2
You can point lxc to a specific mirror you wish to use to download the base system.
Code:
MIRROR=http://mirrors.xmission.com/slackware/ lxc-create -n slack64-14.2 -t slackware -- --release=14.2
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.
Old 05-17-2020, 10:36 PM   #18
dchmelik
Member
 
Registered: Nov 2008
Location: Washington state, USA
Distribution: FreeBSD Unix, Slackware, FreeSlack GNU/Linux, OpenBSD Unix, FreeDOS
Posts: 460

Original Poster
Rep: Reputation: 51
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.

Code:
sudo mount -t proc /proc /root/slackbuildchroot/proc
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.)

Last edited by dchmelik; 05-17-2020 at 11:02 PM.
 
Old 05-18-2020, 08:53 AM   #19
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,408

Rep: Reputation: Disabled
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.
Old 05-18-2020, 10:02 AM   #20
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 174

Rep: Reputation: 124Reputation: 124
From orbea's orignal post:
Code:
#! /bin/sh

TARGET=/media/data/home/chroot/Slackware64-14.2
mount -o bind /proc $TARGET/proc
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.
Old 05-18-2020, 10:19 AM   #21
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,012

Rep: Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743Reputation: 6743
Quote:
Originally Posted by 0XBF View Post
live distros use overlayfs, you can see that in Eric's liveslack scripts for an example
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.
Old 05-18-2020, 10:35 AM   #22
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 174

Rep: Reputation: 124Reputation: 124
Quote:
Originally Posted by Alien Bob View Post
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.
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.
 
Old 05-18-2020, 10:39 AM   #23
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,408

Rep: Reputation: Disabled
Quote:
Originally Posted by 0XBF View Post
From orbea's orignal post:
Code:
#! /bin/sh

TARGET=/media/data/home/chroot/Slackware64-14.2
mount -o bind /proc $TARGET/proc
He's using a bind mount, not creating a new proc filesystem.

Here's a short read on overlayfs that I thought were informative.
https://www.grant.pizza/blog/overlayfs/
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.
Old 05-18-2020, 04:19 PM   #24
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Brú na Bóinne, IE
Distribution: Slackware, NetBSD
Posts: 1,719

Rep: Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208
Quote:
Originally Posted by dchmelik View Post
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.
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.
Old 05-18-2020, 04:56 PM   #25
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,668

Rep: Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013
Quote:
Originally Posted by dive View Post
(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 do this as well.
 
Old 05-18-2020, 06:14 PM   #26
dchmelik
Member
 
Registered: Nov 2008
Location: Washington state, USA
Distribution: FreeBSD Unix, Slackware, FreeSlack GNU/Linux, OpenBSD Unix, FreeDOS
Posts: 460

Original Poster
Rep: Reputation: 51
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.

Quote:
Originally Posted by Gerard Lally View Post
You've disabled private messages so I'm posting a very short reply here. I hope you don't mind..
Yes; I used to be getting a few messages from 'Nigerian scammers' and similar-speaking anonymous ladies supposedly looking for dates.

Quote:
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.
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.
 
Old 05-19-2020, 02:40 AM   #27
bormant
Member
 
Registered: Jan 2008
Posts: 380

Rep: Reputation: 211Reputation: 211Reputation: 211
@dchmelik
for loop can strip some lines:
Code:
...
TARGET=...
for d in proc sys dev tmp etc/resolv.conf; do 
  mount --bind $d $TARGET/$d
done
...
for d in etc/resolv.conf tmp dev sys proc; do
  umount -l $TARGET/$d
done
...
 
1 members found this post helpful.
Old 05-20-2020, 05:24 AM   #28
dchmelik
Member
 
Registered: Nov 2008
Location: Washington state, USA
Distribution: FreeBSD Unix, Slackware, FreeSlack GNU/Linux, OpenBSD Unix, FreeDOS
Posts: 460

Original Poster
Rep: Reputation: 51
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...

Last edited by dchmelik; 05-20-2020 at 05:28 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware in an android chroot? michaelslack Slackware 0 02-25-2014 09:44 AM
slackware 10.2 chroot/jail ssh zdannar Slackware 3 07-12-2007 05:51 PM
segmentation fault with chroot in Slackware 11 vilnisr Slackware 1 10-30-2006 06:16 PM
Chroot bind 9.3.0 in slackware 10 - noobie houler Linux - Security 8 04-01-2005 05:53 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:43 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration