SCHROOT(1)

📦
version 1.6.13 · 6 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

👑 schroot — securely enter a chroot environment 💖

from the Debian sbuild manual, page SCHROOT(1) — bestie edition, no cap ✨

🌸 NAME 🌸

schroot — securely enter a chroot environment 🚪✨

🦋 SYNOPSIS 🦋

okay so here's literally the whole shape of it, copy-paste vibes:

schroot [-h|--help | -V|--version  | -l|--list | -i|--info  | --config |
--location  | --automatic-session  | -b|--begin-session |
--recover-session  | -r|--run-session | -e|--end-session] [-f|--force]
[-n session-name|--session-name=session-name] [-d
directory|--directory=directory] [-u user|--user=user]
[-p|--preserve-environment] [-s shell|--shell=shell] [-q|--quiet |
-v|--verbose] [-c chroot|--chroot=chroot  | [--all | --all-chroots |
--all-source-chroots | --all-sessions] [--exclude-aliases]]
[-o|--option=key=value] [--] [COMMAND [ ARG1 [ ARG2 [ ARGn]]]]

like... that's a lot of brackets, I know. it's giving "choose your own adventure" but make it Unix 🫶

🌈 DESCRIPTION 🌈

so schroot lets you run a command — or a login shell — inside a chroot environment. slay.

If you don't specify a command, a login shell gets started, and it starts in the user's current working directory inside the chroot. cute, right?

The command is a program, plus as many optional arguments as you want. Each argument may be separately quoted — so don't be shy with the quotes bestie.

The directory that the command or login shell runs in depends on the context. There's a whole complete description of this in the --directory option below 👇 go look, it's thorough.

All chroot usage will be logged in the system logs. yep, everything. Under some circumstances, the user may be required to authenticate themselves — see the section “Authentication”, below.

If you don't specify a chroot, the chroot name or alias default will be used as a fallback. That's exactly the same as typing --chroot=default. periodt 💅

🧚 OVERVIEW 🧚

There is often a need to run programs in a virtualised environment rather than on the host system directly. And okay, unlike other virtualisation systems like kvm or Xen, schroot does not virtualise the entire system — it only virtualises the filesystem, and some parts of the filesystem may still be shared with the host. So it's fast, lightweight and flexible ✨

BUT. It does not virtualise other aspects of the system, such as shared memory, networking, devices etc., and so it may be less secure than other systems, depending upon its intended use. so like, vibe check it against what you actually need it for, okay? 🙈

Some examples of existing uses for schroot include:

  • Running an untrusted program in a sandbox, so that it can't interfere with files on the host system; this may also be used to limit the damage a compromised service can inflict upon the host 🛡️
  • Using a defined or clean environment, to guarantee the reproducibility and integrity of a given task 🎯
  • Using different versions of an operating system, or even different operating systems altogether, e.g. different GNU/Linux distributions 🐧
  • Running 32-bit programs using a 32-bit chroot on a 64-bit host system 🧩
  • Automatic building of Debian packages using sbuild(1), which builds each package in a pristine chroot snapshot when using LVM snapshots or unions 📦
  • Supporting multiple system images in a cluster setup, where modifying the base image is time-consuming and/or supporting all the required configurations needed by users is difficult: different chroots can support all the different configurations required, and cluster users may be given access to the chroots they need (which can include root access for trusted users to maintain their own images) 🏗️

A chroot may be used directly as root by running chroot(8), but normal users are not able to use this command. schroot allows access to chroots for normal users using the same mechanism, but with several additional features. 💖

While schroot uses a directory as a chroot just like chroot(8), it does not require this to be a regular directory in the filesystem. While this is the default, the chroot can also be created from:

  • a file 📄
  • a filesystem, including LVM and Btrfs snapshots and loopback mounts 💽
  • or composed of a unionfs overlay 🧅

Being user-extensible, the scope for creating chroots from different sources is limited only by your imagination. iconic, honestly.

schroot performs permissions checking and allows additional automated setup of the chroot environment, such as mounting additional filesystems and other configuration tasks. This automated setup is done through the action of setup scripts which may be customised and extended to perform any actions required. Typical actions include:

  • mounting the user's home directory 🏠
  • setting up networking and system databases 🌐
  • and even starting up services 🚀

These are again entirely customisable by the admin. The setup scripts are run for all types of chroot, with the exception of the plain type — the simplest chroot type, offering no automated setup features at all. 💀

The configuration of schroot is covered in more detail in schroot.conf(5) 📖

⚙️ OPTIONS ⚙️

okay bestie, buckle UP, because schroot takes the following options and there are a lot of them 💅

🎬 Actions

  • -h, --help — shows you the help summary. the lil "what do i do" card.
  • -V, --version — prints version info. say hi to the version number 👋
  • -l, --list — lists every available chroot. the full roster, no filter.
  • -i, --info — prints detailed info about the chroot(s) you specified. deep dive energy.
  • --config — prints the configuration of the specified chroots. super useful for testing that the configuration actually in use matches the config file, fr fr. heads up tho: any comments in the original file will be missing 😭
  • --location — prints the location (path) of the specified chroots. ⚠️ note that chroot types which can only be used within a session will not have a location until they are active — so don't come for them, they're just not there yet 🙈

🌿 General options

  • -q, --quiet — print only essential messages. minimalism era.
  • -v, --verbose — print all messages. yapper mode activated 🗣️

🎯 Chroot selection

  • -c, --chroot=chroot — specify a chroot or active session to use. you can use this option multiple times to specify more than one chroot, and in that case its effect is similar to --all. the chroot name may be prefixed with a namespace — peep the section “Chroot Namespaces” below, iykyk 🦋
  • -a, --all — selects all chroots, source chroots and active sessions. when a command has been specified, the command runs in all of them. if --info was used, it displays info about all chroots. this option does not make sense with a login shell (that's the run you get when no command has been specified). it's equivalent to --all-chroots --all-source-chroots --all-sessions — literally the whole squad ✨
  • --all-chroots — selects all chroots. identical to --all, except source chroots and active sessions are not considered.
  • --all-sessions — selects all active sessions. identical to --all, except chroots and source chroots are not considered.
  • --all-source-chroots — selects all source chroots. identical to --all, except chroots and sessions are not considered.
  • --exclude-aliases — does not select aliases in addition to chroots. this makes sure only real chroots are selected, and that they're only listed once. no dupes, no fakes 👑

🏠 Chroot environment

  • -d, --directory=directory — change to directory inside the chroot before running the command or login shell. if directory is not available, schroot exits with an error status. periodt.

the default behaviour goes like this (and yes, all directory paths are inside the chroot): a login shell is run in the current working directory. if that's not available, it tries $HOME (that's when --preserve-environment is used), then the user's home directory, and then / inside the chroot, in that order. a command, on the other hand, is always run in the current working directory inside the chroot. and if none of the directories are available, schroot exits with an error status. so like, have a plan bestie 💀

  • -u, --user=user — run as a different user. default is to run as the current user. if required, the user may be required to authenticate themselves with a password. more deets in the section “Authentication” below 🔐
  • -p, --preserve-environment — preserve the user's environment inside the chroot environment. the default is to use a clean environment; this option copies the entire user environment and sets it in the session. but the environment variables allowed are subject to certain restrictions — see the section “Environment” below 🌸
  • -s, --shell=shell — use shell as the login shell. when running a login shell, a bunch of potential shells get considered, in this order: the command in the SHELL environment variable (that's when --preserve-environment is used, or preserve-environment is enabled), then the user's shell in the ‘passwd’ database, then /bin/bash, and finally /bin/sh. this option overrides that whole list and uses the shell you specified. it also overrides the shell configuration key, if set. override queen 👑
  • -o, --option=key=value — set an option. the value of selected configuration keys in schroot.conf may be modified using this option. the key must be present in the user-modifiable-keys configuration key in schroot.conf, or additionally the user-modifiable-keys key if running as (or switching to) the root user. the key and value set here get set in the environment of the setup scripts, and may hence be used to customise the chroot on a per-session basis. cute and customisable 🎀

🔄 Session actions

  • --automatic-session — begin, run and end a session automatically. this is the default action, so you don't need to specify it in normal operation. it's just doing its thing.
  • -b, --begin-session — begin a session. a unique session identifier (session ID) is returned on standard output. you need that session ID to use the other session options. ngl the session identifier may also be specified with the --session-name option 💖
  • --recover-session — recover an existing session. if an existing session has become unavailable — like, say, becoming unmounted due to a reboot 😭 — this option makes the session available for use again, for example by remounting it. the session ID is specified with the --chroot option. it's giving resurrection ✨
  • -r, --run-session — run an existing session. the session ID is specified with the --chroot option.
  • -e, --end-session — end an existing session. the session ID is specified with the --chroot option.

🗂️ Session options

  • -n, --session-name=session-name — name a session. the specified session-name replaces the default session name containing an automatically-generated session ID. the session name must not contain a namespace qualifier, since sessions are always created within the ‘session:’ namespace. the session name is also subject to the chroot naming restrictions documented in schroot.conf(5).
  • -f, --force — force a session operation, even if it would otherwise fail. you can use this to forcibly end a session, even if it has active users. ⚠️ but heads up: this does not guarantee the session will be ended cleanly — filesystems may not be unmounted, for example. so, like, use with intention 💅

➖ Separator

  • -- — end of options. it indicates the end of the schroot options; any following options get passed to the command being run, rather than to schroot. the vibes-based boundary line 🦋

🔐 AUTHENTICATION

if the user is not an allowed user, or not a member of the allowed groups (or, if changing to root, not one of the allowed root users or allowed root groups) for the specified chroot(s), permission is immediately denied. no discussion. if switching users, and the user running the command has access, that user will be required to authenticate themselves using the credentials of the user being switched to.

on systems supporting Pluggable Authentication Modules (PAM), schroot uses PAM for authentication and authorisation of users. if and when required, schroot prompts for a password. and if PAM is not available, all authentication automatically fails — user switching is not supported without PAM, periodt.

note that when PAM is in use, the root user is not granted any special privileges by default in the program. however, the default PAM configuration permits root to log in without a password (pam_rootok.so), but this may be disabled to prevent root from accessing any chroots except if specifically permitted. in that situation, root must be added to the allowed users or groups just like any other user or group. and if PAM is not available, the root user will be permitted to access all chroots, even when not explicitly granted access. so yeah, root's got main character energy in that one specific case 👑

🦋 CHROOT NAMESPACES

✨ Namespace basics

there are three different types of chroot: regular chroots, source chroots and session chroots. these different types are separated into different namespaces. a namespace is a prefix to a chroot name. currently there are three namespaces: ‘chroot:’, ‘source:’ and ‘session:’. use --list --all to list all available chroots in all namespaces. and because ‘:’ is used as the separator between namespace and chroot names, it is not permitted to use this character in chroot names. sorry bestie, that's just the rules 💅

depending on the action you ask schroot to take, it may look for the chroot in one of the three namespaces, or a particular namespace may be specified. for example, a chroot named “sid” is actually named “chroot:sid” if the namespace is included — but the namespace may be omitted for most actions. so casual name or full government name, your call 🎀

🌸 Source chroots

some chroot types — like LVM snapshots and Btrfs snapshots — provide session-managed copy-on-write snapshots of the chroot. these also provide a source chroot so you can easily access the filesystem used as a source for snapshotting. they're regular chroots too, just with the snapshotting disabled. for a chroot named “sid-snapshot” (that's the fully qualified name “chroot:sid-snapshot”), there will also be a corresponding source chroot named “source:sid-snapshot”.

earlier versions of schroot provided source chroots with a ‘-source’ suffix. those are also provided for compatibility — in this example, it would be called “chroot:sid-snapshot-source”. ⚠️ these compatibility names will be dropped in a future version, so programs and scripts should switch to using the namespace-qualified names rather than the old suffix. don't get attached to the legacy name, it's leaving 🥲

🧚 Session chroots

all sessions created with --begin-session are placed within the ‘session:’ namespace. a session named with --session-name may have any name — even the same name as the chroot it was created from — providing that it is unique within this namespace. this was not permitted in previous versions of schroot which did not have namespaces. glow up ✨

🎯 Actions and default namespaces

all actions use ‘chroot:’ as the default namespace, with some session actions being the exception. --run-session, --recover-session and --end-session use ‘session:’ as the default namespace instead, since these actions work on session chroots. the upshot is that the namespace is usually never required, except when you need to work with a chroot in a namespace other than the default — like when using a source chroot. and to make chroot selection unambiguous, it is always possible to use the full name including the namespace, even when it's not strictly required. so you can never really get it wrong with the full name, bestie 🫶

✨ PERFORMANCE ✨

ok so bestie, listen 💖 performance on some filesystems — Btrfs being the main culprit, we're calling it out — is bad when you're running dpkg, and it's literally just because of how many fsync operations it does. so many. an unreasonable amount. 😭

the fix? install the eatmydata package, then add eatmydata to the command-prefix configuration key. that disables all the fsync operations and honestly it slays.

⚠️ but bestie, only do this in snapshot chroots where losing data isn't a whole thing. it's giving "living dangerously" and you should know that going in. 🙈

super useful when you're using a chroot for package building, for example. periodt. 🎀

🦋 DIRECTORY FALLBACKS 🦋

so here's the vibe: schroot picks which directory to use inside the chroot based on whether it's an interactive login shell or a command being invoked, plus whether you passed --directory. 💅

the way that it works: if you're running commands directly, or you explicitly named a directory, only one directory gets used — for safety and consistency, no games. but for a login shell? it'll try several possibilities, one after another. it's giving "we have options." ✨

the subsections below list the fallback sequence for each case. CWD = the current working directory. DIR = the directory you specified with --directory. iykyk. 🫶

🌸 Login shell 🌸

here's the host → chroot transition tea:

  • CWD → CWD — normal behaviour (if --directory is not used) 💖
  • CWD → $HOME — happens if CWD is nonexistent and --preserve-environment is used
  • CWD → passwd pw_dir — happens if CWD is nonexistent, or if --preserve-environment is used and no $HOME exists
  • CWD → / — when none of the above exist 🫠
  • FAIL — if / is nonexistent 💀

🌈 Command 🌈

the transition table for when you're just running a command:

  • CWD → CWD — normal behaviour (if --directory is not used) ✨
  • FAIL — if CWD is nonexistent 😭
🚨 no fallbacks should exist under any circumstances. like, none. zero. periodt.

💅 --directory used 💅

when you've explicitly said where you wanna be:

  • CWD → DIR — normal behaviour 👑
  • FAIL — if DIR is nonexistent 💀
🚨 again for the people in the back: no fallbacks should exist under any circumstances. no cap.

🧚 Debugging 🧚

oh this is such a good tip bestie — --debug=notice will show you the internal fallback list computed for the session. literally watching the decision-making happen in real time. obsessed. 🌟

✨ EXAMPLES ✨

ok bestie this is the part where it all clicks, fr fr. real commands, real output, no cap 💅

List available chroots 🎀

% schroot -l↵
chroot:default
chroot:etch
chroot:sid
chroot:testing
chroot:unstable

Get information about a chroot 🔍

% schroot -i -c sid↵
  ——— Chroot ———
  Name                   sid
  Description            Debian sid (unstable)
  Type                   plain
  Priority               3
  Users                  rleigh
  Groups                 sbuild
  Root Users
  Root Groups            sbuild
  Aliases                unstable unstable-sbuild unstable-p
owerpc-sbuild
  Environment Filter     ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|I\
FS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMA\
IN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TE\
RMPATH)$
  Run Setup Scripts      true
  Script Configuration   script-defaults
  Session Managed        true
  Personality            linux32
  Location               /srv/chroot/sid
ok so that Environment Filter line is LONG long, the backslashes are just the terminal wrapping it, she's not broken, she's just ✨thriving✨

Use --all or -c multiple times to use all or multiple chroots, respectively.

Running commands in a chroot 🏃♀️💨

% schroot -c sid /bin/ls↵
[sid chroot] Running command: “/bin/ls”
CVS          sbuild-chroot.c   sbuild-session.h  schroot.conf.5
Makefile     sbuild-chroot.h   schroot.1         schroot.conf.5.in
Makefile.am  sbuild-config.c   schroot.1.in
Makefile.in  sbuild-config.h   schroot.c
pam          sbuild-session.c  schroot.conf
% schroot -c sid -- ls -1 | head -n 5↵
[sid chroot] Running command: “ls -1”
ABOUT-NLS
AUTHORS
COPYING
ChangeLog
INSTALL

so basically, use -- to let options that start with ‘-’ or ‘--’ sneak through into the command you're running inside the chroot. without it, schroot would be like "hm is this for ME?" and eat your flag 🙈. This stops them being interpreted as options for schroot itself.

and listen — that top line got echoed to <b>standard error</b>, and the rest went to <b>standard output</b>. That's <b>intentional</b>, bestie, not a glitch. The whole point is so that program output from commands run in the chroot may be piped and redirected as required; the data will be the same as if the command was run directly on the host system. chef's kiss 🫶

Switching users 🔄👑

% schroot -c sid -u root↵
Password:
[sid chroot] (rleigh→root) Running login shell: “/bin/bash”
#

ok so if the user ‘rleigh’ was in root-users in /etc/schroot/schroot.conf, or one of the groups he belonged to was in root-groups, they would be granted root access without authentication, but the PAM authorisation step is still applied. so you skip the password prompt but PAM still gets a lil say, iykyk 💅

Sessions 🌱

okok so sometimes one command isn't enough and you need a chroot to hang around for a whole TASK. A chroot may be needed to run more than one command. In particular, where the chroot is created on the fly from an LVM LV or a file on disc, there is a need to make the chroot persistent while a given task (or set of tasks) is performed. Sessions exist for this purpose. For simple chroot types such as ‘plain’ and ‘directory’, sessions may be created but are not strictly necessary.

Let's start by looking at a session-capable chroot:

% schroot -i -c sid-snap↵
  ——— Chroot ———
  Name                   sid-snap
  Description            Debian sid snapshot
  Type                   lvm-snapshot
  Priority               3
  Users                  maks rleigh
  Groups                 sbuild
  Root Users
  Root Groups            root sbuild
  Aliases
  Environment Filter     ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|I\
FS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMA\
IN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TE\
RMPATH)$
  Run Setup Scripts      true
  Script Configuration   script-defaults
  Session Managed        true
  Personality            linux
  Device                 /dev/hda_vg/sid_chroot
  Mount Options          -o atime,async,user_xattr
  Source Users
  Source Groups          root rleigh
  Source Root Users
  Source Root Groups     root rleigh
  LVM Snapshot Options   --size 2G -c 128

peep that Session Managed option set to ‘true’. This is a requirement in order to use session management, and is supported by most chroot types. no Session Managed true, no sessions, periodt. 🚫

Next, we will create a new session:

% schroot -b -c sid-snap↵
sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f

The session ID of the newly-created session is returned on standard output. It is common to store it like this:

% SESSION=$(schroot -b -c sid-snap)↵
% echo $SESSION↵
sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f

The session may be used just like any normal chroot. This is what the session looks like:

% schroot -i -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f↵
  ——— Session ———
  Name                   sid-snap-46195b04-0893-49bf-beb8-0d\
4ccc899f0f
  Description            Debian sid snapshot
  Type                   lvm-snapshot
  Priority               3
  Users                  maks rleigh
  Groups                 sbuild
  Root Users
  Root Groups            root sbuild
  Aliases
  Environment Filter     ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|I\
FS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMA\
IN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TE\
RMPATH)$
  Run Setup Scripts      true
  Script Configuration   script-defaults
  Session Managed        true
  Personality            linux
  Mount Location         /var/lib/schroot/mount/sid-snap-461\
95b04-0893-49bf-beb8-0d4ccc899f0f
  Path                   /var/lib/schroot/mount/sid-snap-461\
95b04-0893-49bf-beb8-0d4ccc899f0f
  Mount Device           /dev/hda_vg/sid-snap-46195b04-0893-\
49bf-beb8-0d4ccc899f0f
  Device                 /dev/hda_vg/sid_chroot
  Mount Options          -o atime,async,user_xattr
  Source Users
  Source Groups          root rleigh
  Source Root Users
  Source Root Groups     root rleigh
  LVM Snapshot Device    /dev/hda_vg/sid-snap-46195b04-0893-\
49bf-beb8-0d4ccc899f0f
  LVM Snapshot Options   --size 2G -c 128

notice the header flipped from ——— Chroot ——— to ——— Session ——— bestie, she's a whole different girl now 💖

Now the session has been created, commands may be run in it:

% schroot -r -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f -- \
  uname -sr↵
I: [sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f chroot] Running \
command: “uname -sr”
Linux 2.6.18-3-powerpc
% schroot -r -c $SESSION -- uname -sr↵
I: [sid-snap-fe170af9-d9be-4800-b1bd-de275858b938 chroot] Running \
command: “uname -sr”
Linux 2.6.18-3-powerpc

When all the commands to run in the session have been performed, the session may be ended:

% schroot -e -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f↵
% schroot -e -c $SESSION↵

Finally, the session names can be long and unwieldy. A name may be specified instead of using the automatically generated session ID:

% schroot -b -c sid-snap -n my-session-name↵
my-session-name

ok that -n move is SO iconic, name your session something you'll actually remember instead of vibing with a UUID forever 🦋

🛠️ TROUBLESHOOTING 🛠️

If something is not working, and it's not clear from the error messages what is wrong, try using the --debug=level option to turn on debugging messages. This gives a great deal more information. Valid debug levels are ‘none’, and ‘notice’, ‘info’, ‘warning’ and ‘critical’ in order of increasing severity. The lower the severity level, the more output. so like, none = absolute firehose, critical = only the dire stuff 🔥

If you are still having trouble, the developers may be contacted on the mailing list:

Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>

💀 BUGS 💀

ok so on the mips and mipsel architectures, Linux kernels up to and including at least version 2.6.17 have broken personality(2) support, which results in a failure to set the personality. This will be seen as an “Operation not permitted” (EPERM) error. To work around this problem, set personality to ‘undefined’, or upgrade to a more recent kernel. not us getting humbled by mips 🙈

heads up, bestie: The default execution of a login shell is <b>silently</b> changed to a regular shell if at least one of --preserve-environment or command-prefix is used. no warning, no nothing. sneaky behavior but that's just how she is 💀

🌸 ENVIRONMENT 🌸

By default, the environment is not preserved, and the following environment variables are defined: HOME, LOGNAME, PATH, SHELL, TERM (preserved if already defined), and USER.

The environment variables SCHROOT_COMMAND, SCHROOT_USER, SCHROOT_GROUP, SCHROOT_UID and SCHROOT_GID are set inside the chroot specifying the command being run, the user name, group name, user ID and group ID, respectively.

Additionally, the environment variables SCHROOT_SESSION_ID, SCHROOT_CHROOT_NAME and SCHROOT_ALIAS_NAME specify the session ID, the original chroot name prior to session creation, and the alias used to originally identify the selected chroot, respectively. 🎀

ok this next bit is IMPORTANT bestie, don't skip: The following, <b>potentially dangerous</b>, environment variables are removed for safety by default: BASH_ENV, CDPATH, ENV, HOSTALIASES, IFS, KRB5_CONFIG, KRBCONFDIR, KRBTKFILE, KRB_CONF, LD_.*, LOCALDOMAIN, NLSPATH, PATH_LOCALE, RES_OPTIONS, TERMINFO, TERMINFO_DIRS, and TERMPATH.

If desired, the environment-filter configuration key will allow the exclusion list to the modified; see schroot.conf(5) for further details.

📁 FILES 📁

Configuration files 🗂️

  • /etc/schroot/schroot.conf — The system-wide chroot definition file. This file must be owned by the root user, and not be writable by other. (yes, actually, root-owned and not world-writable, this is not optional 💅)
  • /etc/schroot/chroot.d — Additional chroot definitions may be placed in files under this directory. They are treated in exactly that same manner as /etc/schroot/schroot.conf. Each file may contain one or more chroot definitions. Note that the files in this directory follow the same naming rules as run-parts(8) when run with the --lsbsysinit option. so like, the filenames actually matter, no random vibes-only names 🙈
  • /etc/schroot/setup.d — The system-wide chroot setup script directories. See schroot-setup(5).
  • /etc/pam.d/schroot — PAM configuration.

System directories 🖥️

  • /usr/lib/x86_64-linux-gnu/schroot — Directory containing helper programs used by setup scripts.

Session directories 🌱

Each directory contains a directory or file with the name of each session. Not all chroot types make use of all the following directories.

  • /var/lib/schroot/session — Directory containing the session configuration for each active session.
  • /var/run/schroot/mount — Directory used to mount the filesystems used by each active session.
  • /var/lib/schroot/union/underlay — Directory used for filesystem union source (underlay).
  • /var/lib/schroot/union/overlay — Directory used for filesystem union writeable overlay.
  • /var/lib/schroot/unpack — Directory used for unpacking file chroots.

👑 AUTHORS 👑

Roger Leigh.

Copyright © 2005-2012 Roger Leigh <rleigh@codelibre.net>

schroot is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

💖 SEE ALSO 💖

okay bestie, when you're done with this page and you're like "wait. I need MORE reading" — say less, here's the squad 🫶

  • dchroot(1) — the old-school cousin, still out here doing its thing 💅
  • sbuild(1) — for building stuff in a clean little chroot, iconic behaviour
  • chroot(2) — the syscall itself, the origin story, the main character 🔥
  • schroot.conf(5) — the config file page, literally where all the chroot definitions live, you will be reading this one
  • schroot-setup(5) — setup scripts, the behind-the-scenes girlies doing the actual work
  • schroot-faq(7) — the FAQ!! when you're confused (you will be, we all are, it's fine 🥲) go here first
  • run-parts(8) — for running all the scripts in a directory, a classic

okay so that's the whole page, we did it, we made it to the end together 🌈✨

this was schroot, version 1.6.13, dated 14 Aug 2022 — go forth and chroot responsibly, bestie 💜 no cap, you're gonna do amazing. mwah 🎀🦋💖

📦 where this page comes from