|
Slackware(64) 14.2 chroot?
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. |
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.
|
Could you not have two installs of Slackware and keep one clean to boot into and use for this purpose?
|
This is how I make chroots.
https://www.linuxquestions.org/quest...root-825598/#5 To chroot into them I do this. Code:
#! /bin/shCode:
#! /bin/shCode:
#! /bin/sh |
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. |
Quote:
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/bashCode:
#!/bin/bashCode:
#!/bin/bashNow, any time you want to use the chroot, run use-build-environment.sh: Code:
#!/bin/bashCode:
#!/bin/bashEarlier today I upgraded nodejs from SBo. My session looked something like this: Code:
# cd ~/build |
Consider to use lxc that provide a running chroot enviroment with ip, services and all other, similar to a virtual machine, using paravirtualization.
Also you can do a REAL BOOT of a system installed on chroot, so you can test natively X applications, kernel modules, services and other. enter in chroot enviroment Code:
mount -o bind /proc /CHROOT/procCode:
mkinitrd -c -f ext4 -r /dev/sda1-k <kernel_version> -m <modules_list> where kernel_version is the kernel installed in chroot enviroment then Code:
cd /boot/initrd-treeCode:
mount -o ro${ROOTFLAGS:+,$ROOTFLAGS} -t $ROOTFS $ROOTDEV /mntCode:
mount -o ro${ROOTFLAGS:+,$ROOTFLAGS} -t $ROOTFS $ROOTDEV /mnt2Code:
mkinitrdbe sure that fstab is configured as the main slackware system optionally you can add Code:
/dev/sda1 /ORIGINAL ext4 defaults 0 0to access to the main slackware from chroot exit from chroot edit /etc/lilo.conf and add Code:
image = /CHROOT/boot/vmlinuznow reboot. |
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.) |
Quote:
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:
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/etc/fstab: Code:
/proc /home/chroots/chroot32/proc auto rw,bind,noatime 0 0 Code:
#!/bin/sh |
I noticed there's a mkchroot package on SBo. Anyone know if this would do the proper chroot including for the mount changes for 14.2?
|
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.)
Code:
#!/bin/sh |
| All times are GMT -5. The time now is 09:35 AM. |