LinuxQuestions.org
Help answer threads with 0 replies.
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 02-09-2020, 03:17 AM   #16
sunnandt
LQ Newbie
 
Registered: Feb 2020
Distribution: Slackware
Posts: 4

Rep: Reputation: 6

Quote:
Originally Posted by crts View Post
I always use a copy of an LXC container for this. It is a bit faster than an actual virtual machine and after the build is done I can just delete/destroy the used container and start with a fresh copy for the next Slackbuild.
I am using LXC containers because I also do not know how to create a "clean" chroot environment without duplicating already installed packages. And if I am going to duplicate package installation I may just as well use LXC for isolation.
Good idea. I'll give it a try.
 
1 members found this post helpful.
Old 02-09-2020, 07:20 PM   #17
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 4,265

Rep: Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498
i use virtual box here
 
1 members found this post helpful.
Old 02-10-2020, 03:45 AM   #18
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 1,628

Rep: Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682
I also use VirtualBox.
 
1 members found this post helpful.
Old 05-17-2020, 12:22 AM   #19
dchmelik
Member
 
Registered: Nov 2008
Location: USA
Distribution: FreeBSD Unix, Slackware GNU/Linux, Open Solaris/IllumOS Unix, OpenBSD Unix, FreeDOS
Posts: 525

Rep: Reputation: 54
I asked some years ago (for your reasons and others: ) https://www.linuxquestions.org/quest...ot-4175615212/ and maybe finally got some simpler answers, but maybe not a complete final answer (as Slackware is mounting some other directories than /dev, /proc, /sys, /tmp )... again & again (since many, many versions ago) people immediately suggest much more complicated things instead. I still don't need any of those and firstly would've preferred a completely on-topic answer (as originally requested, 'KISS.') It's okay to inform people about new/complicated methods but they're other topics (off-topic) people may (or not) want to learn about afterwards. At least to know why some of these may (or not) be more useful, it's probably important to fully understand & compare to the standard method (chroot) in the past.

One on-topic thing is you don't actually need overlayfs as part of a chroot. Maybe there's some reason it might help someone... not me so far.

It used to be the case after a fresh installation, I'd chroot in and add packages, and that's part of why I wanted to know in the past (maybe in threads before 14.2?) Now it seems the installation .ISO mounts what you need to be able to chroot, so in the future, one can just examine that (but people do it different ways.) Of course, if you build something depending on stuff not mounted at installation, but on first boot (like control groups, cgroups,) you'll have to look into mounting those for a chroot. For anything but complicated programs, you likely won't need it... yet after those appeared, people avoided answering whether you needed them in chroot (I didn't know what they were; maybe they didn't either)...

My SlackBuilds are just non-networked, non-X, command-line games & command-line graphics... zero need for anything else (so still wish to see a discussion without overlayfs, docker, containers & lxc, emulators/virtual-machines (emu/VM,) jails, whatever else people might want to use for complicated SlackBuilds but I and some others won't need.)

In another case, one might be dual-booting two GNU/Linux and might want to chroot in to do some simple things... maybe won't need a 'container' for that (but useful for complicated things I don't do yet.)

In another case, I still occasionally use Slackware (and other OSes) on a p3/'786' (the last 32-bit you could sometimes use ISA cards)... it won't have some of these new methods, or they may be too slow or even more overkill than it already is on my main workstation... and again, I'd just be testing non-networked, command-line programs...

In another case, someone might have to boot from something such as SysRescueCD (such as for graphical partition or other tools not necessarily in the Slackware .ISO without a lot of setup, or may be on LiveCD/liveslak but might be more difficult/overkill for something, or if it might not even have something SysRescueCD has)... so there's always a reason for people to learn the complete way of something that was always a main method (chroot) in the past and still has various possible uses in which it's simply the simplest/quickest, best solution.

Anyway, take a look at what's mounted during installaton and after boot, and find out or ask someone if you need any of the rest... I'd still like to know in the case of cgroups, because another thing I used to do after a fresh installation is just chroot in and test X/KDE... had no idea if any of it uses cgroups. However what cgroups seems to do is let you limit usage of system resources. Average PC users (rather than system administrators, sysadmins) likely wouldn't be doing that (at least not for simple command-line 'user' usage, except some cases of unusual stuff they might install themselves) but KDE, etc., are getting so complicated now, it's a nightmare to keep up on what you might need to have installed/loaded simply to start it in some cases...

After several 'changing the topic' I finally got a complete answer in my thread above, for 14.1 or earlier (as described in earlier threads and posts on various documentation/wiki sites I lost track of) or if you don't need cgroups, then I guess 14.2. I found out there's a mkchroot package, and I also wrote (haven't tested) my own script in that thread above based on what someone said, but I'm not sure my script works or would work for you (without modification.)

Last edited by dchmelik; 05-17-2020 at 06:30 AM.
 
Old 05-18-2020, 11:43 AM   #20
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,457

Rep: Reputation: Disabled
I also like to KISS, so I use a simple chroot, installed from DVD media. There are other ways to install it, but it doesn't really matter how. Once it's installed it's done. You can update using slackpkg when you need to. I usually blacklist the kernels to make sure they aren't updated.

I don't know the minimum of the special directories needed are, but you can test to see how little you need. You may not need any at all.

I mount my chroot special directories/filesystems in fstab so they are mounted at boot and need no further interaction from me, but since my first answer I've changed them slightly (this assumes your chroot is in /home/chroot):

Code:
/proc      /home/chroot/proc      auto   rw,bind,noatime  0   0
/dev       /home/chroot/dev       auto   rw,bind,noatime  0   0
/dev/pts   /home/chroot/dev/pts   auto   rw,bind,noatime  0   0
/sys       /home/chroot/sys       auto   rw,bind,noatime  0   0
/home/tmp  /home/chroot/tmp       auto   rw,bind,noatime  0   0
The last one is just to make it easier to get files in and out of the chroot. Anything in /tmp in the chroot is accessible in /home/tmp on the host.

I use /dev/pts because I like to use screen in the chroot and it needs a tty. Problems with programs not running because of `not a tty` can be cured using this.

The noatime option may not make any difference/sense with special filesystems(?)

Since they are mounted on boot (or mount -a if you added them afterwards), all you need to do is:

Code:
chroot /home/chroot
any time you want to use the chroot.

That's all. I don't think there's any `slackware way' of doing it. Everyone seems to have different needs. I have a lot of respect for the people that make scripts like mkchroot and others, but it does all start to sound over complicated.

The idea of being able to use an overlay to reset a chroot and undo changes seems nice so I'll look into the easiest way. It looks like just a `mount -t overlay (+options)` over the chroot is all that's needed. Perhaps it could be added to fstab with the other mounts.

Last edited by dive; 05-18-2020 at 11:48 AM.
 
2 members found this post helpful.
Old 05-18-2020, 11:56 AM   #21
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 302

Rep: Reputation: 249Reputation: 249Reputation: 249
I was testing out running an overlay home directory with an nfs home. The fstab syntax for overlayfs I was using was
Code:
overlay  /home/bob  overlay    defaults,auto,lowerdir=/mnt/home/bob,upperdir=/home/local/bob,workdir=/home/local/.bob 0 0
This of course is mounting home directories but you can use it as a reference to get something working for you.
 
1 members found this post helpful.
Old 05-18-2020, 03:50 PM   #22
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,457

Rep: Reputation: Disabled
I did a little testing.

The command I used (after creating the empty, working, and overlay dirs, and unmounting my usual chroot dirs) was:

Code:
mount -t overlay -o lowerdir=/home/chroot,upperdir=/home/empty,workdir=/home/workdir overlay /home/overlay
Then:

Code:
chroot /home/overlay
Using overlayfs over a chroot is a bit complicated by needing at least some of /dev working, for scripts and programs to use special files like /dev/null, /dev/zero, /dev/(u)random etc.

I didn't want all /dev/sd* etc. exposed so I made a few special files (null,zero,(u)random) with mknod, which does add some extra complexity, but is safer than bind mounting all of /dev.

Inside, to get `free` and `df' to work I needed to mount /proc, which I did from inside the chroot, but could also be done in fstab in the host. Not really necessary I guess though. I also tested mounting a tmpfs inside (I use one as $TMP for slackbuilds).

Looking around after making these changes, I see new files in /home/empty, and an empty /home/workdir/work. I was expecting to see something in the workdir.

To unmount the overlay, I had to umount my tmpfs and /proc, before exiting the chroot. The files in /home/empty are persistant and are available the next time the overlay/chroot is used.

So it's a bit more involved than a simple chroot, but it makes it easy to restore it back to the original, clean state by deleting everything in /home/empty.
 
1 members found this post helpful.
Old 05-18-2020, 04:19 PM   #23
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,865

Rep: Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442Reputation: 5442
@dchmelik, I think the biggest benefit with using overlayfs (and probably lxc using some form of snapshots) is to keep a sane base install. If you simply chroot to a directory that has Slackware packages installed, any changes will be "permanently" made to that system. With overlayfs, it will keep the base system clean and untouched, meaning as soon as you exit the chroot and clear the upper/working directories, you're back to a clean install in the lower directory. This makes it extremely easy to test SlackBuilds, as you simply chroot, install (or build and install) the required dependencies, and then run the new script and see if it functions properly. Without it, you'd need to worry about removing all changes to that chroot'd directory before attempting another clean build session.
 
1 members found this post helpful.
Old 05-18-2020, 04:52 PM   #24
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 302

Rep: Reputation: 249Reputation: 249Reputation: 249
I'm building lutris & deps this afternoon and trying out an overlay chroot build environment since we've been talking about it. I'm running it from a script like so:
Code:
#!/bin/bash

# This script will setup the bind mounts and overlayfs
# for the chroot environment and chroot you in.
# When you exit the chroot this script will also clean
# up the binds and overlayfs.

ROOTFS="/home/build/rootfs" # The read-only base system 
CHANGES="/home/build/changes" # All work will be saved here
WORKDIR="/home/build/.work" # overlayfs requires a writable, empty work directory
CHROOT="/home/build/chroot" # Location where we mount the overlayfs, for chrooting in to

# Set up the overlayfs:
mount -t overlay overlay -o lowerdir=${ROOTFS},upperdir=${CHANGES},workdir=${WORKDIR} ${CHROOT}

# Set up bind mounts:
mount -o bind /proc ${CHROOT}/proc
mount -o bind /sys ${CHROOT}/sys
mount -o bind /dev ${CHROOT}/dev
mount -o bind /etc/resolv.conf ${CHROOT}/etc/resolv.conf

# Enter the chroot environment:
printf "You are now in the chroot build environment.\nType 'exit' when you are done.\n"
chroot ${CHROOT}

# Unmount overlay and bind mounts after exiting chroot:
umount ${CHROOT}/proc
umount ${CHROOT}/sys
umount ${CHROOT}/dev
umount ${CHROOT}/etc/resolv.conf
umount ${CHROOT}

# All done. Grab packages from the changes/tmp directory, or wherever they are built under
# the changes directory, clean up 'changes' and start fresh again as needed.
The rootfs is just a clean installpkg run from my local slackware64-current mirror. Seems to work alright so far
 
1 members found this post helpful.
Old 05-19-2020, 01:50 AM   #25
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,457

Rep: Reputation: Disabled
Quote:
Originally Posted by 0XBF View Post
I'm building lutris & deps this afternoon and trying out an overlay chroot build environment since we've been talking about it. I'm running it from a script like so:
Code:
#!/bin/bash

# This script will setup the bind mounts and overlayfs
# for the chroot environment and chroot you in.
# When you exit the chroot this script will also clean
# up the binds and overlayfs.

ROOTFS="/home/build/rootfs" # The read-only base system 
CHANGES="/home/build/changes" # All work will be saved here
WORKDIR="/home/build/.work" # overlayfs requires a writable, empty work directory
CHROOT="/home/build/chroot" # Location where we mount the overlayfs, for chrooting in to

# Set up the overlayfs:
mount -t overlay overlay -o lowerdir=${ROOTFS},upperdir=${CHANGES},workdir=${WORKDIR} ${CHROOT}

# Set up bind mounts:
mount -o bind /proc ${CHROOT}/proc
mount -o bind /sys ${CHROOT}/sys
mount -o bind /dev ${CHROOT}/dev
mount -o bind /etc/resolv.conf ${CHROOT}/etc/resolv.conf

# Enter the chroot environment:
printf "You are now in the chroot build environment.\nType 'exit' when you are done.\n"
chroot ${CHROOT}

# Unmount overlay and bind mounts after exiting chroot:
umount ${CHROOT}/proc
umount ${CHROOT}/sys
umount ${CHROOT}/dev
umount ${CHROOT}/etc/resolv.conf
umount ${CHROOT}

# All done. Grab packages from the changes/tmp directory, or wherever they are built under
# the changes directory, clean up 'changes' and start fresh again as needed.
The rootfs is just a clean installpkg run from my local slackware64-current mirror. Seems to work alright so far

Some things to point out with this approach:

Unless you are changing DNS servers all the time, /etc/resolv.conf only needs *copying* into the rootfs *once*, rather than mount binding into the overlay, which is a bit overkill anyway. Do you really want that showing up when you list mounts with the `mount' command?

If you are mount binding all of /dev then you will have all of the hard drive and other block devices exposed, which isn't really what you want in a `safe build environment'. I know that I did this in the past, but all you need to do is `mknod' a few character files like /dev/null etc in the rootfs *once*. Use the `stat' command on the real files in the host to see which mode, major, and minor numbers you need - e.g.

Code:
mknod -m 0666 /dev/null c 1 3
You may also need to chgrp on some files.

If there are any block devices you need, e.g. like your CD/DVD device, then mount bind those individually.

Edit* The above might be my wishful thinking ;-)

Last edited by dive; 05-19-2020 at 04:14 PM.
 
1 members found this post helpful.
Old 05-19-2020, 04:08 PM   #26
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,457

Rep: Reputation: Disabled
More thoughts and findings on overlays, and trying to keep usage as simple as possible, but also trying to keep more separation between the chroot and the host.

Here I'm using /home/chroot for the permanent, base file system. I renamed my /home/empty to /home/dirty. Probably more fitting. No bind mounting of any special dirs from inside chroot to host except /dev/pts, which is minimal, it may not be needed anyway except by screen/dialog/ncurses.

Note: I haven't really done much without a full /dev directory (I tested downloading and starting a slackbuild using sbopkg), so I have no idea if trimming it down will work, or if it gets too complicated and I end up mounting a full /dev eventually.

Listing of /home/chroot/dev so far. Devices made manually with `mknod' (see notes below for a short guide.)

Code:
drwxr-xr-x 2 root root     0 May 19 18:54 pts/
crw-rw---- 1 root video 5, 1 May 19 18:30 console
crw-rw-rw- 1 root root  1, 3 May 19 18:10 null
crw-rw-rw- 1 root tty   5, 2 May 19 18:14 ptmx
crw-rw-rw- 1 root root  1, 8 May 19 18:12 random
crw-rw-rw- 1 root root  1, 9 May 19 18:12 urandom
crw-rw-rw- 1 root root  1, 5 May 19 18:11 zero
All those are permanent. They don't need to be remade every time the overlay is used.

My new overlay mount command:

Code:
# mount -v -t overlay -o lowerdir=/home/chroot,upperdir=/home/dirty,workdir=/home/workdir overlay /home/overlay
Any mounts bound from inside the overlay to the host should be mounted after the overlay is mounted. E.g.:

Code:
# mount -v -t auto -o bind /dev/pts /home/overlay/dev/pts
Now screen and dialog should work.

If they need to be unmounted, then they need unmounting before the overlay is unmounted, or umount will complain.

Mounts to be kept within the overlay must be mounted after mounting the overlay and chrooting in to it:

Code:
# mount -v -t proc proc /proc
/sys may or may not be necessary. YMMV.

If they need to be unmounted, then it should also be when chrooted into the overlay, but they don't need to be mounted/unmounted every time the overlay is used. All the mounts can be left in place, until the chroot needs to be reset and the `dirty' directory cleaned to get back to the initial state.

Once all the mounts are done, all that's needed is:

Code:
# chroot /home/overlay
and that's all.


Notes:

`stat' is useful to find the necessary info for `mknod':

Code:
# stat -c "%a %t %T %U %G (%F)" /dev/console
660 5 1 root video (character special file)

Explanation:

-c     An output format sequence follows
%a     Mode/Permissions of the file
%t     Major device number
%T     Minor device number
%U     User
%G     Group
%F     File type

(There are more format sequences in the man page.)
Armed with that info you can:

Code:
# mknod -m 660 /home/chroot/dev/console c 5 1
# chgrp video /home/chroot/dev/console

Explanation:

mknod -m [mode] [/path/to/device] [type (c=char)] [major] [minor]

Result:

crw-rw---- 1 root video 5, 1 May 18  14:10 /home/chroot/dev/console
(I used /dev/console as an example because it has a different group to root.)


To see if any files have been created in the file system, look in the `dirty' directory, e.g.:

Code:
# find /home/dirty -ls | less
`diff' could be used to find before and after states. Very quick untested example off the top of my head, for e.g. testing a slackbuild:

Code:
# find /home/dirty -ls > before.state

... test slackbuild in chroot ...

# find /home/dirty -ls > after.state
# diff before.state after.state | less
That should give a list of changes. To check only certain areas of the file system would be a bit more involved. At least /tmp should be excluded if testing slackbuilds (diff -x /tmp or -x /tmp/* perhaps), or perhaps it would be easier to include only certain parts of the file system. Obviously needs looking at much more. (Diff's 2 column output might be useful, but very wide.)


To clean the chroot, do all unmounting in reverse order to mounting:

Unmount everything mounted inside the chroot
Exit the chroot
Unmount all bind mounts in the overlay
Unmount the overlay itself

Then:

Code:
# rm -rf /home/dirty/*
This turned out longer than I expected...
 
3 members found this post helpful.
Old 05-20-2020, 06:21 AM   #27
dchmelik
Member
 
Registered: Nov 2008
Location: USA
Distribution: FreeBSD Unix, Slackware GNU/Linux, Open Solaris/IllumOS Unix, OpenBSD Unix, FreeDOS
Posts: 525

Rep: Reputation: 54
I must say I feel even more mystified about overlayfs chroot setup than when the basic idea was finally explained. The abstract basic idea sounds better (i.e., use your Slackware 'host' instead of duplicating, so only changes are your packages?) but as I read this late at night, I think I just have to come back to it and read more... maybe from a manpage... if it only has a manpage (rather than hopefully GNU info hypertext or hopefully at least HTML or PDF) I don't feel optimistic, and if it doesn't have one at all, I don't either... but it's good to see this new method.

Last edited by dchmelik; 05-20-2020 at 06:23 AM.
 
Old 05-20-2020, 08:49 AM   #28
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,457

Rep: Reputation: Disabled
You've got the idea of the two main uses of chroot:

1) Chroot from a slackware install disk, or other media, into a slackware installation on disk to repair it.

2) Install a full slackware installation inside a directory (the [Chroot Directory] below) that we can use without affecting anything on the host outside that directory. No rebooting is required.

A diagram of an overlay setup might look like this:

Code:
Top Layer:    [Overlay Directory] -> [Changes Directory]  (These are initially empty)
Bottom Layer: [Chroot Directory]
When using (2) in the normal way, you would use only [Chroot Directory]. Any changes you make will affect that directory.

When you use an overlay, you chroot into the [Overlay Directory] instead, but you see what is in [Chroot Directory], plus any changes that you make.

You won't notice any difference between the two methods while you are working, but, with an overlay, any changes you make won't affect [Chroot Directory]. They are made in [Changes Directory].

The advantage of using an overlay like that is that it is easy to reset everything back to the initial state, by remounting the overlay using empty directories again. This is much faster than e.g. VM snapshots etc.

I hope that makes it clearer and helps you to visualise what's happening.
 
1 members found this post helpful.
Old 05-24-2020, 09:28 AM   #29
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 571

Original Poster
Rep: Reputation: Disabled
I see this thread got some new content, so I'll add a bit of feedback too.

The workflow I've settled on is to use a recent Slackware Live Edition and just fiddle with stuff inside it. If I ruin anything, I just restart the VirtualBox machine back to clean state. It works for almost all use cases, except heavy resource consuming tasks like building Qt5 from source.
 
1 members found this post helpful.
Old 10-01-2020, 08:34 PM   #30
Gordie
Member
 
Registered: Aug 2007
Location: Nolalu, Ontario, Canada
Distribution: Slackware64
Posts: 752

Rep: Reputation: 289Reputation: 289Reputation: 289
Quote:
Originally Posted by FlinchX View Post
I see this thread got some new content, so I'll add a bit of feedback too.

The workflow I've settled on is to use a recent Slackware Live Edition and just fiddle with stuff inside it. If I ruin anything, I just restart the VirtualBox machine back to clean state. It works for almost all use cases, except heavy resource consuming tasks like building Qt5 from source.
I was going to ask about Slackware Live but not with VirtualBox. Cannot persistence be used to advantage here?
 
  


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
Questions for Robby, ponce, or anyone from SBo about SBo submission requirements. ReaperX7 Slackware 4 06-07-2015 12:30 PM
Nvidia-driver.SlackBuild from SBo (or: I am a bad and sloppy SBo maintainer) kingbeowulf Slackware 8 08-31-2012 03:41 AM
Buildscripts for E17 on Slackware64 voyciz Slackware 3 12-02-2009 10:50 AM
Adding buildscripts or ./configure lines to packages piete Slackware 18 09-12-2008 01:24 PM
KDE base to work with dropline's HAL & rworkman's buildscripts for xfce 4.4 ? Doable? Old_Fogie Slackware 13 04-16-2007 11:57 PM

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

All times are GMT -5. The time now is 12:47 AM.

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
Open Source Consulting | Domain Registration