SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I use Slackware64 up-to-date stable 14.2 and would like full chroot setup instructions (just into Slackware(64) 14.2.)
Some things (emulators, emus, virtual machines, VMs) are becoming more popular (and usually recommended on freenode IRC ##slackware & #slackbuilds) but for me, that's normally a stressful, over-complicated hassle overkill (I rarely use VMs and can't paste into AQEMU.)
Sure, I'll be updating SlackBuilds I write, which don't need an entire emu/VM (maybe two, GRX, and KuickShow, would be better in VM, but KuickShow has no new version in years, may not even work on next Slackware & X/KDE. GRX was also old until they rewrote with only Debian/etc. compile instructions, so unsure I'll continue; anyone else may attempt/take GRX rewrite's SlackBuild for SBo, which nothing depends on anyway, just is interesting in supporting both console/SVGAlib & X/SDL.) My other SlackBuilds are just command-line daemons/libraries and/or games; they don't need an entire OS as if running on hardware (let alone X, nor anything else, beyond command-line, emu/VM may provide, like emulated asm & hardware.)
I'd really just like to 'Keep It Simple ('KISS(!):') chroot (with a shell alias I have) to immediately compile on consoles directly there (if I'm even in X) or also terminal I can paste into (X or even from it with clipb to tty,) instead of a complicated, resource-hungry emulator/VM window in X with way more than I need, that takes longer to get into (some minutes boot,) more maintenance/setup, more crashes, corruption if the process is killed, etc., then I have to set up the method to copy in & out... just too many more issues, too cumbersome, for likely no fewer potential bugs, no more benefits, in my case.
Well, it all depends why you want to chroot. Assuming that it's to build stuff, if you have in mind the risks running a SlackBuild that you just wrote as root, you could simply use fakeroot. That's what I always do.
Now, if what you want is run the SlackBuild in a clean environment, i.e. in a genuine Slackware without any third party software but the needed deps of the software you are compiling, I think that using a VM is the simplest way, unless you have another (clean) Slackware in a dedicated partition where you could just chroot (assuming the same Arch).
This being said I am very far be an expert in that field, but there has been an interesting discussion in this thread.
Last edited by Didier Spaier; 10-07-2017 at 06:40 AM.
I don't worry much about 'running stuff as root,' even though I login as root at least every week, if not every day. The reason is clean environment. Maybe for that, emu/VM is simplest for you, not me.
For building packages on a clean install, I'd like to recommend looking into overlayfs.
You can mount a read-write directory structure over your read-only system, and afterwards you can view and delete the diff. It's very useful for quickly reverting to the "clean" state.
As for setting up the chroot, I found the slackware wiki isn't as complete as I'd like. This script can set up a slackware chroot, even on systems that don't run slackware, and generate all necessary files: http://chunk.io/midkid/b31b78e3eaef4df7b7ffdaf4e25a2ba5
As for entering the chroot, this is really up to you. As I mentioned earlier, I like using overlayfs. I have a script, to which you feed the clean chroot, a "build" directory, and a slackbuild, and it'll mount the slackbuild's directory under /mnt, runs it, and saves build log in the build directory, next to the filesystem diff: http://chunk.io/midkid/16c2a2ef3fc344619e5e730a908ae2fd
It's a bit of a hassle to use, but you can modify it to simply enter a shell, and it's good enough for illustrative purposes.
If you don't like manual work like this, I'd recommend you look into docker, which also serves fine for this purpose. You feed it your clean tared chroot directory, from which it creates an "image", and you can spawn as many "containers" as you want from it, and it works like overlayfs, allowing you to see the filesystem diff based on the "base" image, extract files, create new reuseable "layers" on top of it, etc.
It's a bit more of a learning curve but much less of a hassle than shell scripting, and even though it has a ton of features you'll probably never use, it comes with a negligible overhead, since it actually uses the same techniques as in the shell script above (overlayfs, chroot, uunshare), as well as other techniques to provide better isolation.
I ... would like full chroot setup instructions (just into Slackware(64) 14.2.)
I use a chroot for compiling SBo packages. Why don't I use slackrepo? Not-invented-here syndrome, I guess.
Step 1: Download and save all bash scripts in /root/build/*
Step 2: Modify PKG_SRC and SLACK_TREE variables in all scripts (and also possibly RELEASE_ROOT, PATCHED_ROOT, BUILD_ROOT, UPPERDIR, WORKDIR, and CHROOT). There is also a hard-coded reference to /home/erich in use-build-environment.sh that you'll have to update. It's for non-SBo (but locally installed) packages (e.g. alien's packages). Also modify /etc/sbopkg/sbopkg.conf and set the OUTPUT variable to /tmp/SBo/pkgs.
Step 3: Run install-release.sh
Code:
#!/bin/bash
# install-release.sh
#
# Copyright 2016 Erich Ritz
#
# This script installs Slackware64 14.2 to a chroot environment.
IFS="$(printf '\n\t')"
SERIES=(a ap d e f k kde l n t tcl x xap xfce y)
PKG_SRC=/home/erich/pkgs/slackware/slackware64-14.2/slackware64
NEW_ROOT=/root/build/14.2-release
if [ ! -d "$NEW_ROOT" ]; then
mkdir -p "$NEW_ROOT"
fi
# These packages are safe to install using the --root option of installpkg and
# set up the initial chroot environment from which we can install all other
# packages.
BASE_PKGS=( \
a/aaa_base-14.2-x86_64-2.txz \
a/aaa_elflibs-14.2-x86_64-23.txz \
a/aaa_terminfo-5.9-x86_64-1.txz \
a/devs-2.3.1-noarch-25 \
a/pkgtools-14.2-noarch-10.txz \
a/etc-14.2-x86_64-7.txz \
a/tar-1.29-x86_64-1.txz \
a/xz-5.2.2-x86_64-1.txz \
a/findutils-4.4.2-x86_64-1.txz \
a/bash-4.3.046-x86_64-1.txz \
a/coreutils-8.25-x86_64-2.txz \
a/grep-2.25-x86_64-1.txz \
a/sed-4.2.2-x86_64-1.txz \
a/util-linux-2.27.1-x86_64-1.txz)
for pkg in "${BASE_PKGS[@]}" ; do
echo " *** --- *** Installing package $pkg *** --- ***"
installpkg --root "$NEW_ROOT" "$PKG_SRC/$pkg"
done
# Copy files needed by the chroot installpkg. All of these will be overwritten
# when installing glibc-solibs-*.txz.
copy_file() {
cp "$1" "$NEW_ROOT$1"
}
link_file() {
( cd "$NEW_ROOT$1" ; ln -sf "$2" "$3" )
}
copy_file /lib64/libdl-2.23.so
link_file /lib64 libdl-2.23.so libdl.so.2
copy_file /lib64/libc-2.23.so
link_file /lib64 libc-2.23.so libc.so.6
copy_file /lib64/ld-2.23.so
link_file /lib64 ld-2.23.so ld-linux-x86-64.so.2
copy_file /lib64/libpthread-2.23.so
link_file /lib64 libpthread-2.23.so libpthread.so.0
# The only packages that touch /proc, /sys, and /dev are aaa_base and devs.
# Since they are already installed, they will be skipped when using upgradepkg
# to install all packages. Thus, it is safe to mount /proc, /sys, and /dev in
# the chroot environment.
mount -t proc proc "$NEW_ROOT"/proc || exit 1
#mount -B /sys "$NEW_ROOT"/sys || exit 1
#mount -B /dev "$NEW_ROOT"/dev || exit 1
# The only package to touch /mnt is aaa_base, so use /mnt as the location of the
# Slackware tree.
mount -B "$PKG_SRC" "$NEW_ROOT"/mnt || exit 1
# Define the installpkg_chroot function. Use upgradepkg rather than installpkg
# because upgradepkg will skip packages that are already installed - a desirable
# behavior because we don't want to reinstall aaa_base and devs packages.
installpkg_chroot() {
chroot "$NEW_ROOT" upgradepkg --install-new "$1"
}
# Install a few more base packages, now using the chroot.
# These packages provide binaries called from various doinst.sh scripts.
installpkg_chroot /mnt/a/glibc-solibs-2.23-x86_64-1.txz
installpkg_chroot /mnt/ap/texinfo-6.1-x86_64-1.txz
installpkg_chroot /mnt/l/glib2-2.46.2-x86_64-2.txz
installpkg_chroot /mnt/l/desktop-file-utils-0.22-x86_64-1.txz
installpkg_chroot /mnt/l/shared-mime-info-1.6-x86_64-1.txz
installpkg_chroot /mnt/l/gdk-pixbuf2-2.32.3-x86_64-1.txz
installpkg_chroot /mnt/l/gtk+2-2.24.30-x86_64-1.txz
# fontconfig is used by all font packages
installpkg_chroot /mnt/l/glibc-2.23-x86_64-1.txz
installpkg_chroot /mnt/l/freetype-2.6.3-x86_64-1.txz
installpkg_chroot /mnt/l/harfbuzz-1.2.7-x86_64-1.txz
installpkg_chroot /mnt/x/libfontenc-1.1.3-x86_64-1.txz
installpkg_chroot /mnt/x/fontconfig-2.11.1-x86_64-2.txz
installpkg_chroot /mnt/x/mkfontscale-1.1.2-x86_64-2.txz
installpkg_chroot /mnt/x/mkfontdir-1.0.7-noarch-1.txz
for series in "${SERIES[@]}" ; do
echo " *** --- *** Installing series $series *** --- ***"
for pkgfull in $PKG_SRC/$series/*.t?z ; do
pkg="$(basename "$pkgfull")"
installpkg_chroot "/mnt/$series/$pkg"
done
done
# Unmount
umount "$NEW_ROOT"/mnt
#umount "$NEW_ROOT"/dev
#umount "$NEW_ROOT"/sys
umount "$NEW_ROOT"/proc
Step 4: Run install-patched.sh to install Slackware patches:
Step 5: Run install-build-environment.sh to install sbopkg into your chroot:
Code:
#!/bin/bash
# install-build-environment.sh
#
# Copyright 2016 Erich Ritz
#
# This script installs sbopkg in the chroot Slackware64 14.2
IFS="$(printf '\n\t')"
PKG_SRC=/home/erich/pkgs
RELEASE_ROOT=/root/build/14.2-release
PATCHED_ROOT=/root/build/14.2-patched
BUILD_ROOT=/root/build/14.2-build
WORKDIR=/root/build/workdir
CHROOT=/root/build/chroot
if [ ! -d "$BUILD_ROOT" ]; then
mkdir -p "$BUILD_ROOT"
fi
if [ ! -d "$WORKDIR" ]; then
mkdir -p "$WORKDIR"
fi
if [ ! -d "$CHROOT" ]; then
mkdir -p "$CHROOT"
fi
mount -t overlay overlay \
-olowerdir=$PATCHED_ROOT:$RELEASE_ROOT,upperdir=$BUILD_ROOT,workdir=$WORKDIR \
$CHROOT
mount -t proc proc "$CHROOT"/proc || exit 1
mount -B "$PKG_SRC" "$CHROOT"/mnt || exit 1
installpkg_chroot() {
chroot "$CHROOT" installpkg "$1"
}
installpkg_chroot /mnt/sbopkg/sbopkg-0.38.1-noarch-1_wsr.tgz
# Copy configuration file
cp /etc/sbopkg/sbopkg.conf $CHROOT/etc/sbopkg/sbopkg.conf
# Create directories for sbo
mkdir -p $CHROOT/var/lib/sbopkg
mkdir -p $CHROOT/var/cache/sbopkg
mkdir -p $CHROOT/var/log/sbopkg
mkdir -p $CHROOT/tmp/SBo
umount "$CHROOT"/mnt
umount "$CHROOT"/proc
umount "$CHROOT"
Every time new Slackware patches are released, edit install-patched.sh and rerun. There is no need to rerun install-build-environment.sh due to the way overlayfs works.
Now, any time you want to use the chroot, run use-build-environment.sh:
Code:
#!/bin/bash
# use-build-environment.sh
#
# Copyright 2016 Erich Ritz
#
# This script uses the chroot Slackware environment
IFS="$(printf '\n\t')"
PKG_SRC=/home/erich/pkgs
RELEASE_ROOT=/root/build/14.2-release
PATCHED_ROOT=/root/build/14.2-patched
BUILD_ROOT=/root/build/14.2-build
UPPERDIR=/root/build/changes
WORKDIR=/root/build/workdir
CHROOT=/root/build/chroot
# First delete UPPERDIR to remove any previous changes
if [ -d "$UPPERDIR" ] ; then
rm -rf -- "$UPPERDIR"
fi
mkdir -p "$UPPERDIR"
if [ ! -d "$WORKDIR" ]; then
mkdir -p "$WORKDIR"
fi
if [ ! -d "$CHROOT" ]; then
mkdir -p "$CHROOT"
fi
mount -t overlay overlay \
-olowerdir=$BUILD_ROOT:$PATCHED_ROOT:$RELEASE_ROOT,upperdir=$UPPERDIR,workdir=$WORKDIR \
$CHROOT
cp -a /root/.gnupg "$CHROOT"/root
mount -B "$PKG_SRC" "$CHROOT"/mnt
# Bind sbo directories from /
mount -B /var/lib/sbopkg "$CHROOT"/var/lib/sbopkg
mount -B /var/cache/sbopkg "$CHROOT"/var/cache/sbopkg
mount -B /var/log/sbopkg "$CHROOT"/var/log/sbopkg
mount -B /tmp/SBo "$CHROOT"/tmp/SBo
# Also bind pkgs directory
mkdir -p "$CHROOT"/home/erich/pkgs
mount -B /home/erich/pkgs "$CHROOT"/home/erich/pkgs
./chroot.sh "$CHROOT"
umount "$CHROOT"/home/erich/pkgs
umount "$CHROOT"/tmp/SBo
umount "$CHROOT"/var/log/sbopkg
umount "$CHROOT"/var/cache/sbopkg
umount "$CHROOT"/var/lib/sbopkg
umount "$CHROOT"/mnt
umount $CHROOT
And finally, a dependent script used by the above scripts:
Code:
#!/bin/bash
# chroot.sh
# Exit if location not specified
if [ -z "$1" ]; then
echo "chroot folder not specified"
exit 1
elif [ "$1" = -h ]; then
echo "./chroot.sh <chroot-folder>"
exit 1
fi
location="$1"
cd "$location" || exit 1
# Mounting, basic
mount -t proc proc "$1"/proc || exit 1
mount -o bind /sys "$1"/sys || exit 1
mount -o bind /dev "$1"/dev || exit 1
# Mounting extra partition which is already mounted on host
# first one is host mount path, second is chroot mount
#mount -B /mnt/datalinux2 "$1"/mnt/data
# For internet access
cp /etc/resolv.conf "$1"/etc/resolv.conf
# Prevent D-Bus errors
cp /var/lib/dbus/machine-id "$1"/var/lib/dbus/machine-id
# Finally, chroot
chroot "$location" /bin/bash -l
# Unmounting after exit from chroot
#umount "$1"/mnt/data
umount "$1"/{proc,sys,dev}/ || exit 1
echo "Done"
Note there are a few differences between my scripts and orbea's solution. His bind mounts /etc/resolv.conf, while my solution copies, for example.
Earlier today I upgraded nodejs from SBo. My session looked something like this:
Code:
# cd ~/build
# # Edit install-patched.sh due to Slackware patches released recently.
# ./install-patched.sh
# ./use-build-environment.sh
(chroot) # sbopkg -k -b nodejs
(chroot) # exit
# upgradepkg /tmp/SBo/pkgs/nodejs-6.11.4-x86_64-1_SBo.tgz
You can of course modify use-build-environment.sh to edit which system directories are available in the chroot. For example, currently I have /tmp/SBo and /home/erich/pkgs as shared directories to the chroot.
Drumz, orbea, zerouno, thanks! Though I didn't ask for debate, I might try overlayfs, though am not going to try an entire other install (same drive or different PC, worst option yet,) nor Docker (bad experience with that so far, though it might be easier for something else.)
However, I noticed Slackware 14.2 also mounts some stuff it runs from /etc/rc.d/rc.cg* files. There should be instructions how to mount those, though stuff I build doesn't use them (I should start another thread, 'what's cg* really for,' because when I type 'mount' it's getting cluttered.)
Drumz, orbea, zerouno, thanks! Though I didn't ask for debate, I might try overlayfs, though am not going to try an entire other install (same drive or different PC, worst option yet,) nor Docker (bad experience with that so far, though it might be easier for something else.)
I don't really like Docker either, but it's the only thing I have found thus far that implements this "Just spin up a new one to get a clean slate" paradigm and filesystem layer-based approach in a generic way that isn't a huge hassle to manage. I might someday™ implement it myself properly, but for now it's good enough for what I need.
I failed to mention slackrepo, which also uses overlayfs to manage multiple layers on top of a "clean" chroot, and is more tailored towards SlackBuild building than any other approach. You might want to look into that if you need ideas.
I hope you find the approach that's most useful to you, and can continue creating packages.
Quote:
Originally Posted by dchmelik
However, I noticed Slackware 14.2 also mounts some stuff it runs from /etc/rc.d/rc.cg* files. There should be instructions how to mount those, though stuff I build doesn't use them (I should start another thread, 'what's cg* really for,' because when I type 'mount' it's getting cluttered.)
For what I'm aware, cg stands for cgroups, or control groups. It's a method to allocate per-process resources, such as CPUs, memory, etc. Often used by container software (docker, lxc) or systemd, but you could use it yourself to restrict some programs, if you figure out how.
On my machine, the cgroups filesystems are mounted on boot, even if the rc.cg* are disabled, by rc.S. You can see how to mount them there, but I wouldn't bother mounting them inside a chroot, as they're usually unecessary, and I'm unsure what kind of side-effects it could have.
I'm still wondering whether cgroups should be mounted in chroot on 14.2, and how to do them.
I should be more careful responding/thanking for mentioning/explaining stuff different than the thread title; now it seems to happen after every post I do. In replies on the actual topic, I don't mind just mentioning the names of alternatives, but posts just on that or explanation start to lead to off-topic discussion. One alternative I had tried; three others I'm considering later, but won't discuss here rather than other threads.
Right now I'm still wondering how to do an exactly right chroot on 14.2. Even if some alternatives may be better and I might start using one or all of them someday, I still want to know how to chroot, as it's more standard. None of my SlackBuilds use chroot, but maybe one might someday, or I might install something else in a chroot for some reason.
Lots of different ways of making/using chroots here.
I use chroots a lot to test new slackbuilds, without clobbering the host system.
I use a 32bit chroot to test build new wine versions before submitting to slackbuilds.org.
This is my chroot maker script. Colours are optional of course and need real escape codes.
mkchroot:
Code:
#!/bin/sh
set -e
SERIES="a ap d f k kde l n t tcl x xap y"
CHROOT="/home/chroots/slackware64"
CDPATH="/mnt/cdrom/slackware64"
bgreen="^[[01;32m"
normal="^[[0m"
mkdir -p "$CHROOT"
cd $CDPATH
for i in $SERIES
do
echo "${bgreen}Installing series $i${normal}"
installpkg -root "$CHROOT" $i/*.t?z
done
mkdir -p $CHROOT/proc
mkdir -p $CHROOT/dev
mkdir -p $CHROOT/sys
mkdir -p $CHROOT/tmp
I mount everything in /etc/fstab. I used to do it in the script when I chrooted, but use chroots so often it just made more sense to mount at boot.
/etc/fstab:
Code:
/proc /home/chroots/chroot32/proc auto rw,bind,noatime 0 0
/dev /home/chroots/chroot32/dev auto rw,bind,noatime 0 0
/sys /home/chroots/chroot32/sys auto rw,bind,noatime 0 0
/tmp /home/chroots/chroot32/tmp auto rw,bind,noatime 0 0
/proc /home/chroots/chroot/proc auto rw,bind,noatime 0 0
/dev /home/chroots/chroot/dev auto rw,bind,noatime 0 0
/sys /home/chroots/chroot/sys auto rw,bind,noatime 0 0
/tmp /home/chroots/chroot/tmp auto rw,bind,noatime 0 0
I have two shell scripts: cht and cht32:
Code:
#!/bin/sh
CHROOT=/home/chroots/chroot
if [ ! -r "$CHROOT" ]; then
exit 1
fi
cp /etc/resolv.conf $CHROOT/etc
cp /home/david/.Xauthority $CHROOT/root
chroot $CHROOT /bin/zsh
I copy the .Xauthority so that I can run GUI apps if I need.
Looking at the readme it seems to use hard linking rather than installing packages the normal way. I think it's probably a shell script so it might be worth downloading the source and taking a look.
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)... but I ended up making a script... might use it, but definitely want to try mkchroot package/script mentioned in recent discussion. If I wanted to chroot on other media (like SysRescueCD) or to do simple SlackBuilds (don't need X, don't really need network, but might want it to download source code) I'd do something like this (based on what orbea said, but I did one major thing different (mount /proc) and forgot why.)
Though I did want a full straight answer for years on what's needed to chroot on the install .ISO (it sets it up itself now, so one can see with 'mount,' just not how... most people do it the same way... but in that situation all you need is 'chroot /mnt') and what's needed to simulate Slackware after boot if really necessary (i.e., it mounts control groups, cgroups, which you may not need and can mostly unmount, but if you do need them, will be needed to be mounted)... it seems no one was sure. There was some explanation above: cgroups usually would be not needed. In some case (someone else) they might be needed, so there has been no full straight answer as of yet and people are still asking with new threads on basically the same topic.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
