SCHROOT.CONF(5)

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

NAME 💖

schroot.conf — chroot definition file for schroot, and yes bestie, this is the schroot.conf(5) manual page. Periodt. 💅

DESCRIPTION ✨

Okay so listen up, bestie! schroot.conf is literally a plain UTF-8 text file, describing the chroots available for use with schroot. No cap. 🦋

Comments are introduced following a # (“hash”) character at the beginning of a line, or following any other text. All text right of the # is treated as a comment. So you can write whatever you want after a # and it's just vibes. 💬

The configuration format is an INI-style format, split into groups of key-value pairs separated by section names in square brackets. It's giving very organized, very demure. ✨

General options 👑

A chroot is defined as a group of key-value pairs, which is started by a name in square brackets on a line by itself. The file may contain multiple groups which therefore define multiple chroots. So you can have a whole squad of chroots in one file. 👯‍♀️

A chroot definition is started by the name of the chroot in square brackets. For example,

[sid]

The name is subject to certain naming restrictions. For further details, see the section “Chroot Names” below. (We'll get there, don't worry.) 👀

This is then followed by several key-value pairs, one per line:

  • type=type — The type of the chroot. Valid types are ‘plain’, ‘directory’, ‘file’, ‘loopback’, ‘block-device’, ‘btrfs-snapshot’, ‘zfs-snapshot’ and ‘lvm-snapshot’. If empty or omitted, the default type is ‘plain’. Note that ‘plain’ chroots do not run setup scripts and mount filesystems; ‘directory’ is recommended for normal use (see “Plain and directory chroots”, below). So like, don't be basic with plain unless you know what you're doing. 💁‍♀️
  • description=description — A short description of the chroot. This may be localised for different languages; see the section “Localisation” below. So you can give your chroot a cute lil bio. 📝
  • priority=number — Set the priority of a chroot. number is a positive integer indicating whether a distribution is older than another. For example, “oldstable” and “oldstable-security” might be ‘0’, while “stable” and “stable-security” are ‘1’, “testing” is ‘2’ and “unstable” is ‘3’. The values are not important, but the difference between them is. This option is deprecated and no longer used by schroot, but is still permitted to be used; it will be obsoleted and removed in a future release. So it's giving legacy, but you can still use it if you want. ⚠️
  • message-verbosity=verbosity — Set the verbosity of messages printed by schroot when setting up, running commands and cleaning up the chroot. Valid settings are ‘quiet’ (suppress most messages), ‘normal’ (the default) and ‘verbose’ (show all messages). This setting is overridden by the options --quiet and --verbose. So you can control the yapping level. 🗣️
  • users=user1,user2,... — A comma-separated list of users which are allowed access to the chroot. If empty or omitted, no users will be allowed access (unless a group they belong to is also specified in groups). So this is the VIP list. 📋
  • groups=group1,group2,... — A comma-separated list of groups which are allowed access to the chroot. If empty or omitted, no groups of users will be allowed access. Another VIP list, but for groups. 👯
  • root-users=user1,user2,... — A comma-separated list of users which are allowed password-less root access to the chroot. If empty or omitted, no users will be allowed root access without a password (but if a user or a group they belong to is in users or groups, respectively, they may gain access with a password). See the section “Security” below. So this is like, root access but no password needed. Highkey powerful. 🔑
  • root-groups=group1,group2,... — A comma-separated list of groups which are allowed password-less root access to the chroot. If empty or omitted, no users will be allowed root access without a password (but if a user or a group they belong to is in users or groups, respectively, they may gain access with a password). See the section “Security” below. Same but for groups. 💪
  • aliases=alias1,alias2,... — A comma-separated list of aliases (alternate names) for this chroot. For example, a chroot named “sid” might have an ‘unstable’ alias for convenience. Aliases are subject to the same naming restrictions as the chroot name itself. So you can give your chroot a nickname. 😎
  • profile=directory — The behaviour of the chroot setup scripts may be customised on a per-chroot basis by setting a specific configuration profile. The directory is relative to /etc/schroot. The default is ‘default’. The files in this directory are sourced by the setup scripts, and so their behaviour may be customised by selecting the appropriate profile. Alternatives are ‘minimal’ (minimal configuration), ‘desktop’ (for running desktop applications in the chroot, making more functionality from the host system available in the chroot) and ‘sbuild’ (for using the chroot for Debian package building). Other packages may provide additional profiles. The default values of the keys setup.config, setup.copyfiles, setup.fstab and setup.nssdatabases are set based upon the profile setting. Note that the profile key replaces the older script-config key. The script-config key is exactly the same as profile, but has “/config” appended to it. The default filename is ‘default/config’. Either of these keys may be used. If both are present, then script-config will take precedence (profile will be unset). script-config is deprecated and will be removed in a future release. Note that profile is equivalent to script-config if the file sourced by script-config only contains the standard variables provided by schroot; if any additional variables or shell script fragments have been added, please also set setup.config, which will continue to allow this file to be sourced. It is recommended to replace the use of the sourced file with additional keys in schroot.conf where possible, but it will continue to be possible to source an additional configuration file using setup.config. Desktop users should note that the fstab file desktop/fstab will need editing if you use gdm3; please see the comments in this file for further instructions. The preserve-environment key should also be set to ‘true’ so that the environment is preserved inside the chroot. If none of the configuration profiles provided above meet your needs, then they may be edited to further customise them, and/or copied and used as a template for entirely new profiles. Note that the different profiles have different security implications; see the section “Security” below for further details. Phew, that was a lot. But basically: pick a profile, customize it, slay. 💅
  • script-config=filename — This is the older key. It's exactly the same as profile, but has “/config” appended to it. The default filename is ‘default/config’. Either of these keys may be used. If both are present, then script-config will take precedence (profile will be unset). script-config is deprecated and will be removed in a future release. See the notes under profile above for all the other details about profiles, sourced files, desktop users, and security. So basically same vibes, just legacy. 🕰️
  • setup.config=filename — This key specifies a file which the setup scripts will source when they are run. This defaults to the same value as set by script-config. The file is a Bourne shell script, and in consequence may contain any valid shell code, in addition to simple variable assignments. This will, for example, allow behaviour to be customised according to the specific chroot type or name. Note that the script will be sourced once for each and every script invocation, and must be idempotent. All the default settings in this file are now settable using configuration keys in schroot.conf, as detailed below. Existing configurations should be modified to use these keys in place of this file. See schroot-script-config(5) for further details. This type of setup script configuration file is no longer provided as part of the standard profiles, but will continue to be sourced if present and this key is set. So it's giving legacy but still supported. 📜
  • setup.copyfiles=filename — A file containing a list of files to copy into the chroot (one file per line). The file will have the same absolute location inside the chroot. So you can copy your fave files in. 📂
  • setup.fstab=filename — The filesystem table file to be used to mount filesystems within the chroot. The format of this file is the same as for /etc/fstab, documented in fstab(5). The only difference is that the mountpoint path fs_dir is relative to the chroot, rather than the root. Also note that mountpoints are canonicalised on the host, which will ensure that absolute symlinks point inside the chroot, but complex paths containing multiple symlinks may be resolved incorrectly; it is inadvisable to use nested symlinks as mountpoints. So be careful with symlinks, bestie. 🔗
  • setup.nssdatabases=filename — A file listing the system databases to copy into the chroot. The default databases are ‘passwd’, ‘shadow’, ‘group’ and ‘gshadow’. Other potential databases which could be added include ‘services’, ‘protocols’, ‘networks’, and ‘hosts’. The databases are copied using getent(1) so all database sources listed in /etc/nsswitch.conf will be used for each database. So it's giving system info sync. 🗄️
  • setup.services=service1,service2,... — A comma-separated list of services to run in the chroot. These will be started when the session is started, and stopped when the session is ended. So like, services that turn on and off with the session. 🔄
  • command-prefix=command,option1,option2,... — A comma-separated list of a command and the options for the command. This command and its options will be prefixed to all commands run inside the chroot. This is useful for adding commands such as nice, ionice or eatmydata for all commands run inside the chroot. nice and ionice will affect CPU and I/O scheduling. eatmydata ignores filesystem fsync operations, and is useful for throwaway snapshot chroots where you don't care about dataloss, but do care about high speed. So you can speed things up, but careful with dataloss. ⚡
  • personality=persona — Set the personality (process execution domain) to use. This option is useful when using a 32-bit chroot on 64-bit system, for example. Valid options on Linux are ‘bsd’, ‘hpux’, ‘irix32’, ‘irix64’, ‘irixn32’, ‘iscr4’, ‘linux’, ‘linux32’, ‘linux_32bit’, ‘osf4’, ‘osr5’, ‘riscos’, ‘scorvr3’, ‘solaris’, ‘sunos’, ‘svr4’, ‘uw7’, ‘wysev386’, and ‘xenix’. The default value is ‘linux’. There is also the special option ‘undefined’ (personality not set). For a 32-bit chroot on a 64-bit system, ‘linux32’ is the option required. The only valid option for non-Linux systems is ‘undefined’. The default value for non-Linux systems is ‘undefined’. So if you're mixing architectures, this is your bestie. 🧠
  • preserve-environment=true|false — bestie, by default the environment does NOT get preserved inside the chroot, and instead a minimal environment gets used. Flip it to true and you'll always keep the environment. Super handy, for example, when you're running X applications inside the chroot, because those babies need the environment to actually function correctly. You can also preserve the environment with the --preserve-environment option, so pick your fighter. ✨
  • shell=shell — when a login shell runs, schroot goes shopping down a list of potential shells, in this exact order: the command in the SHELL environment variable (only if --preserve-environment is used, or if preserve-environment is enabled), then the user's shell in the ‘passwd’ database, then /bin/bash, and finally /bin/sh. This setting overrides that whole list and just uses the shell you specify. And it can itself be overridden with the --shell option. It's giving "we have layers". 💅
  • environment-filter=regex — the environment that gets set in the chroot is filtered to remove environment variables that might be a security risk. Any environment variable matching the specified POSIX extended regular expression gets removed prior to executing any command in the chroot. No cap. 🔥

Potentially dangerous environment variables get removed for safety by default using this regular expression right here:

^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$

🌈 Plain and directory chroots 🌈

Chroots of type plain or directory are just directories accessible in the filesystem. The two types are equivalent except for the fact that directory chroots run setup scripts, whereas plain chroots do not. Because of that, filesystems such as /proc are not mounted in plain chroots — it's the responsibility of the system administrator to configure such chroots by hand, whereas directory chroots are automatically configured. And additionally, directory chroots implement the filesystem union chroot options (see “Filesystem Union chroot options”, below). 😌

These chroot types have an additional (mandatory) configuration option:

  • directory=directory — the directory containing the chroot environment. This is where the root will be changed to when executing a login shell or a command. The directory must exist and have read and execute permissions to allow users access to it. Heads up though: on Linux systems it'll be bind-mounted elsewhere for use as a chroot. The directory for ‘plain’ chroots is mounted with the --rbind option to mount(8), while for ‘directory’ chroots --bind is used instead so that sub-mounts are not preserved (they should be set in the fstab file just like in /etc/fstab on the host). ✨

🦋 File chroots 🦋

Chroots of type file are files on the current filesystem containing an archive of the chroot files. They implement the source chroot options (see “Source chroot options”, below). Note that a corresponding source chroot (of type file) will be created for each chroot of this type — this is for convenient access to the source archive, e.g. for the purpose of updating. These additional options are also implemented:

  • file=filename — the file containing the archived chroot environment (mandatory). This must be a tar (tape archive), optionally compressed with gzip, bzip2, xz, lzop or lz4. The file extensions used to determine the type are .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzop, .tar.lz4, .tgz, .tbz, .txz, .tzo and .tlz4. This file must be owned by the root user, and not be writable by other. Also note that zip archives are no longer supported — zip was not able to archive named pipes and device nodes, so it was not suitable for archiving chroots. rip zip. 💀
  • location=path — this is the path to the chroot inside the archive. For example, if the archive contains a chroot in /squeeze, you would specify /squeeze here. If the chroot is the only thing in the archive, i.e. / is the root filesystem for the chroot, this option should be left blank, or omitted entirely. 🫶

🌸 Loopback chroots 🌸

Chroots of type loopback are a filesystem available as a file on disk, accessed via a loopback mount. The file will be loopback mounted and unmounted on demand. Loopback chroots implement the mountable chroot and filesystem union chroot options (see “Mountable chroot options” and “Filesystem Union chroot options”, below), plus an additional option:

  • file=filename — this is the filename of the file containing the filesystem, including the absolute path. For example /srv/chroot/sid. 💖

💜 Block device chroots 💜

Chroots of type block-device are a filesystem available on an unmounted block device. The device will be mounted and unmounted on demand. Block device chroots implement the mountable chroot and filesystem union chroot options (see “Mountable chroot options” and “Filesystem Union chroot options”, below), plus an additional option:

  • device=device — this is the device name of the block device, including the absolute path. For example, /dev/sda5. ✨

🎀 Btrfs snapshot chroots 🎀

Chroots of type btrfs-snapshot are a Btrfs snapshot created from an existing Btrfs subvolume on a mounted Btrfs filesystem. A snapshot will be created from this source subvolume on demand at the start of a session, and then the snapshot will be mounted. At the end of the session, the snapshot will be unmounted and deleted. This chroot type implements the source chroot options (see “Source chroot options”, below). Note that a corresponding source chroot (of type directory) will be created for each chroot of this type — this is for convenient access to the source volume. These additional options are also implemented:

  • btrfs-source-subvolume=directory — the directory containing the source subvolume.
  • btrfs-snapshot-directory=directory — the directory in which to store the snapshots of the above source subvolume. 🌸

⭐ ZFS snapshot chroots ⭐

Chroots of type zfs-snapshot are a ZFS clone created from an existing ZFS dataset. A snapshot and clone will be created from this source subvolume on demand at the start of a session, and then the clone will be mounted. At the end of the session, the clone will be unmounted and the clone and snapshot will be deleted. This chroot type implements the source chroot options (see “Source chroot options”, below). Note that a corresponding source chroot (of type directory) will be created for each chroot of this type — this is for convenient access to the source volume. These additional options are also implemented:

  • zfs-dataset=dataset_name — name of the ZFS source dataset to use.
  • zfs-snapshot-options=snapshot_options — snapshot options. These are additional options to pass to zfs snapshot. 💅

🌈 LVM snapshot chroots 🌈

Chroots of type lvm-snapshot are a filesystem available on an LVM logical volume (LV). A snapshot LV will be created from this LV on demand, and then the snapshot will be mounted. At the end of the session, the snapshot LV will be unmounted and removed. 😭

LVM snapshot chroots implement the source chroot options (see “Source chroot options”, below), and all the options for block-device. Note that a corresponding source chroot (of type block-device) will be created for each chroot of this type — this is for convenient access to the source device. This additional option is also implemented:

  • lvm-snapshot-options=snapshot_options — snapshot options. These are additional options to pass to lvcreate(8). For example, -L 2g to create a snapshot 2 GiB in size. Note: the LV name (-n), the snapshot option (-s) and the original LV path may not be specified here; they are set automatically by schroot. 👑

🧚 Custom chroots 🧚

Chroots of type custom are a special type of chroot, used for implementing new types of chroot not supported by any of the above chroot types. This may be useful for implementing and testing a new chroot type without needing to write any C++ code. However, you will need to write your own setup script to do the setup work, since by itself this chroot type does very little. You will also need to add custom keys to your chroot definition for use in the setup script; unlike the configuration for the above chroot types, no validation of the options will take place unless you do it yourself in your custom setup script. Main character energy fr fr. These additional options are also implemented:

  • custom-session-cloneable=true|false — set whether or not sessions may be cloned using this chroot (enabled by default).
  • custom-session-purgeable=true|false — set whether or not sessions may be cloned using this chroot (disabled by default).
  • custom-source-cloneable=true|false — set whether or not source chroots may be cloned using this chroot (disabled by default). 🦋

💖 Source chroot options 💖

The btrfs-snapshot, file and lvm-snapshot chroot types implement source chroots. Additionally, chroot types with union support enabled implement source chroots (see “Filesystem Union chroot options”, below). These are chroots which automatically create a copy of themselves before use, and are usually session managed. These chroots additionally provide an extra chroot in the source: namespace, to allow convenient access to the original (non-snapshotted) data, and to aid in chroot maintenance. I.e. for a chroot named wheezy (chroot:wheezy), a corresponding source:wheezy chroot will be created. For compatibility with older versions of schroot which did not support namespaces, a chroot with a -source suffix appended to the chroot name will be created in addition (i.e. wheezy-source using the above example). Note that these compatibility names will be removed in schroot 1.5.0, so the use of the source: namespace is preferred over the use of the -source suffix form. See schroot(1) for further details. 🫶

These chroots provide the following additional options:

  • source-clone=true|false — set whether the source chroot should be automatically cloned (created) for this chroot. The default is true to automatically clone, but if desired may be disabled by setting to false. If disabled, the source chroot will be inaccessible. 🙈
  • source-users=user1,user2,... — a comma-separated list of users who are allowed access to the source chroot 🫶. If it's empty or you just... don't include it, then no users get access, periodt. This becomes the users option in the source chroot, ok?
  • source-groups=group1,group2,... — a comma-separated list of groups allowed access to the source chroot. Empty or omitted → no users allowed access (yes, it says users, we're not fighting the manpage 💀). This becomes the groups option in the source chroot.
  • source-root-users=user1,user2,... — comma-separated list of users who get password-less root access to the source chroot 👑. Empty or omitted → nobody gets root access without a password (but if a user is in users, they can still slide in with a password). This becomes the root-users option in the source chroot. Go read the “Security” section below, bestie, fr fr.
  • source-root-groups=group1,group2,... — comma-separated list of groups allowed password-less root access to the source chroot. Empty or omitted → no users get root access without a password (but if a user's group is in groups, they may gain access with a password). This becomes the root-groups option in the source chroot. Again: “Security” section, go look 🌸.

🧲 Mountable chroot options 🧲

The block-device, loopback and lvm-snapshot chroot types implement device mounting. These are chroots that literally need a device mounted before you can even get in there. And they come with these extra options:

  • mount-options=options — mount options for the block device. These are additional options you pass to mount(8). Example vibe: -o atime,sync,user_xattr.
  • location=path — the path to the chroot inside the filesystem on the device. So like, if the filesystem has a chroot sitting in /chroot/sid, you'd write /chroot/sid right here. But if the chroot is the only thing on the filesystem — i.e. / is the root filesystem for the chroot — then leave this blank or just omit it entirely ✨.

🌈 Filesystem Union chroot options 🌈

The block-device, directory and loopback chroot types let you create a session using filesystem unions, which overlay the original filesystem with a separate writable directory. The original filesystem stays read-only, and every modification you make lives in the overlying writable directory instead — so the original is untouched, no cap 🫶.

A union means multiple sessions can access and change a single chroot at the same time, while each session's changes stay private to that session. Iconic, honestly.

To turn this on, set union-type to any supported value. If it's enabled, the chroot is also a source chroot, which hands you extra options (see “Source chroot options”, above). Every entry here is optional.

  • union-type=type — set the union filesystem type. Currently supported: aufs, overlayfs, overlay (as of Linux 4.0+) and unionfs. The default is none, which disables the whole feature 💤.
  • union-mount-options=options — union filesystem mount options (branch configuration), used for mounting the union filesystem you specified with union-type. This replaces the complete -o string for mount, which lets you build complex filesystem unions 🔥. Note that aufs, overlayfs and unionfs each support different mount options — they are not the same girl. Also note: you can use the variables ${CHROOT_UNION_OVERLAY_DIRECTORY} and ${CHROOT_UNION_UNDERLAY_DIRECTORY} to refer to the writable overlay session directory and the read-only underlying directory that are gonna form the union. See schroot-setup(5) for the complete variable list 📋.
  • union-overlay-directory=directory — the directory where the writeable overlay session directories get created. Default is /var/lib/schroot/union/overlay.
  • union-underlay-directory=directory — the directory where the read-only underlying directories get created. Default is /var/lib/schroot/union/underlay.

🎀 Customisation 🎀

On top of all the config keys listed above, you can add custom keys 💅. These get used to add extra environment variables to the setup script environment when setup scripts run. The only restriction? The key name can only have alphanumeric characters and hyphens, it has to start with an alphabet character, and it must contain at least one period. In other words, it matches the extended regular expression ^([a-z][a-z0-9]*\.)+[a-z][a-z0-9-]*$.

For example:

debian.apt-update=true
debian.distribution=unstable

would set the following environment:

DEBIAN_APT_UPDATE=true
DEBIAN_DISTRIBUTION=unstable
Watch out: it is an error to use different key names that would set the same environment variable by mixing periods and hyphens. Don't do it 🙈.

Custom configuration keys can also be modified at runtime using the --option option. BUT — for security — only selected keys may be modified, and those get specified with these options:

  • user-modifiable-keys=key1,key2,.. — set the keys which users may modify using --option.
  • root-modifiable-keys=key1,key2,.. — set the keys which the root user may modify using --option. Note that the root user may use the keys specified in user-modifiable-keys in addition to the ones specified here 👑.

🌍 Localisation 🌍

Some keys can be localised into multiple languages 🦋. You do this by sticking the locale name in square brackets right after the key name. For example:

description[en_GB]=British English translation

This localises the description key for the en_GB locale.

description[fr]=French translation

And this one localises the description key for all French locales 🇫🇷.

⭐ CHROOT NAMES ⭐

A bunch of characters and words are simply not permitted in a chroot name, session name, or configuration filename. The name has to begin with a lowercase or uppercase letter, or a digit. After that first character, you may additionally use a dash (-), a period (.), or an underscore (_).

The rationale for these restrictions, bestie:

Generic

Unfortunately, not all the places that deal with chroot names can handle non-printable and other characters properly, and it's hard to update all of them 😭. This is mostly about the various shell scripts, where it's also unwise to assume the authors always create safe code.

‘dpkg-old’

‘dpkg-dist’

‘dpkg-new’

‘dpkg-tmp’

These names may not appear at the end of a name. They're saved copies of conffiles used by the dpkg package manager, and they will be ignored.

🔒 SECURITY 🔒

Untrusted users

Giving untrusted users root access to chroots is a SERIOUS security risk! 😭

Yeah, the untrusted user will only have root access to files inside the chroot — but in practice there are many obvious ways of breaking out of the chroot and disrupting services on the host system. As always, this all boils down to trust.

Do not give chroot root access to users you would not trust with root access to the host system. Periodt.

Profiles

Depending on which profile you configured with the script-config option, different filesystems will be mounted inside the chroot, and different files will be copied into the chroot from the host.

Some profiles mount the host's /dev, while others will not. Some profiles also bind mount additional parts of the host filesystem to allow use of certain features, including user's home directories and specific parts of /var 👀.

Check the profile's fstab file so you're actually certain of what will be mounted, and check the other profile files to see which files and system databases will be copied into the chroot. Then choose a different profile or edit the files to further restrict what's made available inside the chroot.

There's a tradeoff here between security (keeping the chroot as minimal as possible) and usability (which sometimes requires access to parts of the host filesystem). The different profiles make different tradeoffs, and it's important that you assess which one meets the security/usability tradeoff you actually require 🫶.

📝 EXAMPLE 📝

# Sample configuration

[sid]
type=plain
description=Debian unstable
description[fr_FR]=Debian instable
directory=/srv/chroot/sid
priority=3
users=jim
groups=sbuild
root-users=rleigh
aliases=unstable,default

[etch]
type=block-device
description=Debian testing (32-bit)
priority=2
groups=users
#groups=sbuild-security
aliases=testing
device=/dev/hda_vg/etch_chroot
mount-options=-o atime
personality=linux32

[sid-file]
type=file
description=Debian sid file-based chroot
priority=3
groups=sbuild
file=/srv/chroots/sid.tar.gz

[sid-snapshot]
type=lvm-snapshot
description=Debian unstable LVM snapshot
priority=3
groups=sbuild
users=rleigh
source-root-users=rleigh
source-root-groups=admin
device=/dev/hda_vg/sid_chroot
mount-options=-o atime,sync,user_xattr
lvm-snapshot-options=--size 2G

📁 FILES 📁

okay so here's the whole map of where everything lives, bestie. bookmark this section fr fr 🗺️✨

Chroot definitions

  • /etc/schroot/schroot.conf — the system-wide chroot definition file. heads up tho: this file must be owned by the root user, and it must not be writable by other. like. not even a little. 🔒👑
  • /etc/schroot/chroot.d — extra chroot definitions can live in files under this directory 🫶. they get treated in exactly that same manner as /etc/schroot/schroot.conf, no special-casing, no sneaky differences. and each file in there can hold one or more chroot definitions, so you can absolutely stack them 💅

Setup script configuration

the directory /etc/schroot/default is where the default settings used by setup scripts hang out. it's giving backstage pass energy 🎀

  • config — the main configuration file read by setup scripts. the format of this file is described over in schroot-script-config(5) 📖. this is the default value for the script-config key. and btw, not me reminding you that this was formerly named /etc/schroot/script-defaults — the glow-up was real ✨

the following files are referenced by default:

  • copyfiles — a list of files to copy into the chroot from the host system. and yes, this was formerly named /etc/schroot/copyfiles-defaults 🌸
  • fstab — a file in the format described in fstab(5), used to mount filesystems inside the chroot. important detail: the mount location is relative to the root of the chroot. also, formerly named /etc/schroot/mount-defaults 💜
  • nssdatabases — system databases (as described in /etc/nsswitch.conf on GNU/Linux systems) to copy into the chroot from the host. formerly named /etc/schroot/nssdatabases-defaults 🦋

👑 AUTHORS 👑

Roger Leigh. that's the icon, that's the legend, that's the main character who wrote all this 🫶⭐

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 🔗

go read these next, bestie, they're all connected iykyk 💫

and that's a wrap on the whole page!! 🎉💖 you read the entire thing, no cap, that's genuinely iconic of you. this version is Version 1.6.13, dated 14 Aug 2022, and it's the SCHROOT.CONF(5) manual page — go forth and configure your chroots like the absolute queen you are 👑💅🌈

📦 where this page comes from