I am beginning to experiment with chroot. I am using the Ubuntu Help page although I am running Debian:

https://help.ubuntu.com/community/BasicChroot

Here is my progress so far:

May I ask why I am getting this error message and what to do about it?

Hi

Why are you experimenting with it, on what hardware; I assume that's different commands of [code] not quotes?

Is "--variant=buildd" correct? Is it supposed to be two 'd's?

# /usr/sbin/debootstrap --variant=buildd --arch amd64 bullseye /var/chroot/ http://ftp.us.debian.org/debian/dist/bullseye


Your trying to run an (old) installer script that makes a DEBIAN ROOT for install disks: but your getting an error from UBUNTU who apparently would rather that job be left to themselves? Otherwise it'd be working! it wasn't (maybe is now, but wasn't) made for making configure chroots.

Try making your own chroot using Busybox, a slackware boot disk, something. There's not much to it: just a standard list of files that need to be copied.

INFACT: JUST

# cp -a /dev /lib /lib64 /bin /sbin /tmp/foo
# mkdir -p /tmp/foo/var /tmp/foo/tmp ...
# chroot /tmp/foo

(now, that'll be a huge chroot in ubuntu, perhaps you need a huge one perhaps your seeking a busybox size one and can preen things)

NOTE: CHROOT AND JAILS ARE NOT SECURE (freebsd jails if kernel supported ... have some extra security)

It only tells the kernel where to read files for (the session / logged in user). It literally does NOTHING else.

But the effect is as strong as you think: you can run older, same, even newer "roots" without effecting the root you booted from in the other console window. (um, you can effect the other window easily - it's just you have to want to. no applications will do that usually no worry there. there's no security, as i said, between chroots.)

Maybe a virtual machine (Virtualbox, KVM, GNOME Boxes &c...) would work?

... or a container.

"chroot" is a comparatively weak technology. Containers have taken the whole idea much farther, using newly-added kernel features to create strong isolation (and phantom perceived environments) while the processes in question continue to run natively on the host. They're also generally much easier to manage. There's Docker, of course, but also "lxc/lxd."

The clear advantage of containers is that they are lightweight. The processes are "wearing rose-colored glasses," but they are still running "on the host." Container technology now is quite mature, with several good options to choose from, so that's how I would do it today.

3 members found this post helpful.