Reproducible Live images

This page tracks the progress on creating reproducible live images, using live-build from DebianLive

Contents

  1. Reproducible Live images
    1. Status
    2. Verification
  2. Configuration
    1. Modified configuration files
    2. Jenkins node osuosl3-amd64.debian.net
    3. Personal computer
  3. Building live images
    1. Preparation of the build directory
    2. Building
  4. Checking reproducibility
    1. Using diffoscope
    2. Using reprotest
    3. Disorderfs
  5. See also

Status

Bookworm: All official images are reproducible (the live-build stage)

Trixie: All unofficial images are reproducible (the live-build stage)

Image with simplified reproducible flow

Source code for the image

Verification

Configuration

Modified configuration files

Required entries in sudoers (assuming you are thisuser): 

Defaults env_keep += "SOURCE_DATE_EPOCH"
Defaults env_keep += "LIVE_BUILD"
thisuser ALL=(root) NOPASSWD: /usr/bin/lb build
thisuser ALL=(root) NOPASSWD: /usr/bin/lb clean --purge

Jenkins node osuosl3-amd64.debian.net

Personal computer

The computer that is used for generating live images:

Snapshot

In order to get a reproducible image, there are two main options:

  1. If the live image is expected to be reproducible, the image can be built twice in rapid succession from deb.debian.org (within its regular 6 hour update cycle)

  2. If the live image is expected to be non-reproducible, a snapshot server needs to be used.
    • By using a snapshot server, it is easier to re-generate images to track the difference and to polish on the work-around hook.

      Note that for live images in production, deb.debian.org needs to be used.

In the past snapshot.debian.org had issues (rejecting traffic when many requests are made). Since 2021-09-05 snapshot.notset.fr was used, until the issues with snapshot.debian.org have been resolved.

Considerations

Building live images

Preparation of the build directory

As a regular user (with sudo configured as mentioned earlier): 

# You need `dev` and `exec` active on your mount point
# Slightly more than 16GB is required (on a machine with 32GB memory /dev/shm gets half of it)
sudo mount /dev/shm -odev,exec,remount,size=24G
mkdir /dev/shm/live
cd /dev/shm/live

Building

All command lines can be executed as a regular user

Use case: build an image from the current Debian repository (testing, unstable or experimental)

/home/roland/git.nobackup/live-build/test/rebuild.sh --configuration gnome --debian-version sid

Use case: build an image from the current Debian repository (stable)

/home/roland/git.nobackup/live-build/test/rebuild.sh --configuration gnome --debian-version bookworm --debian-version-number 12.1.0 --timestamp archive --installer-origin archive

Use case: rebuild an image with a given timestamp

/home/roland/git.nobackup/live-build/test/rebuild.sh --configuration gnome --debian-version sid --timestamp 20220421T153504Z

Use case: get the latest image from the snapshot server

# The magic value 'snapshot' queries the snapshot server and fetches the latest/newest snapshot
/home/roland/git.nobackup/live-build/test/rebuild.sh --configuration gnome --debian-version sid --timestamp snapshot

Use case: while preparing new hooks, using the local git checkout of `live-build`

# Get the latest from https://salsa.debian.org/live-team/live-build
# When LIVE_BUILD is defined, the script will not checkout live-build from the timestamp, but will use the version pointed at by LIVE_BUILD
export LIVE_BUILD=/home/roland/git.nobackup/live-build
/home/roland/git.nobackup/live-build/test/rebuild.sh --configuration gnome --debian-version sid --timestamp 20220421T153504Z

Use case: rebuilding the official Debian live image

# Get the required packages
sudo apt-get install live-build git
#
# Get the latest version of the builder script
git clone https://salsa.debian.org/live-team/live-build.git rebuild_script --no-checkout --depth 1
cd rebuild_script
git checkout HEAD test/rebuild.sh
cd ..
#
# If needed, do some time travel, to fetch an older version of the rebuild.sh script. The sha256sum hash value can be found in .disk/generator of the official image
#
# Prepare the arguments for building, see https://salsa.debian.org/images-team/live-setup/-/blob/master/available/live-build-binary#L129
BUILD=gnome
CODENAME=bookworm
VERSION=12.10.0
SNAPSHOT_TIMESTAMP=archive
INSTALLER_ORIGIN=archive
DESCRIPTION="Official Debian GNU/Linux Live $VERSION $BUILD"
#
# Build it
rebuild_script/test/rebuild.sh --configuration ${BUILD} --debian-version ${CODENAME} --debian-version-number ${VERSION} --timestamp ${SNAPSHOT_TIMESTAMP} --installer-origin ${INSTALLER_ORIGIN} --disk-info "${DESCRIPTION}" --generate-source
#
# Verify the SHA256SUMs:
# ISO: https://get.debian.org/images/release/current-live/amd64/iso-hybrid/SHA256SUMS
# TAR: https://get.debian.org/images/release/current-live/source/tar/SHA256SUMS

Checking reproducibility

Ideally reprotest will be used to check reproducibility. For now, 2 images are built and then compared with diffoscope.

Using diffoscope

# 1) Prepare the build environment
# 2) Run the command line to create the configuration (see above)
lb build
mv live-image-amd64.hybrid.iso run01.iso
lb clean --purge
lb config
lb build
mv live-image-amd64.hybrid.iso run02.iso
diffoscope run01.iso run02.iso --html-dir html_run01_02

Using reprotest

reprotest requires full access on /tmp, so it must be remounted (when applicable) 

# 1) Prepare the build environment
# 2) Run the command line to create the configuration (see above)
mount /tmp -odev,exec,suid,remount
reprotest  --variations=-all,+environment,+build_path,-kernel,+aslr,+num_cpus,+time,-user_group,-fileordering,-domain_host,+home,+locales,+exec_path,+timezone,-umask  "lb clean --purge&&lb config&&lb build" "*.iso"
# Disabled tests:
#  kernel        The variant with kernel 2.6 is too old for debootstrap
#  user_group    Live build only works for root, the variation needs a list
#  fileordering  Disorderfs needs to be mounted with dev,exec,suid
#  domain_host   Needs additional rights during debootstrap
#  umask         Some files get a different umask, further investigation is required

Disorderfs

To ensure that file ordering is not a cause for non-reproducible images, the tool 'disorderfs' will offer the files from the file system in a different order: 

# As root
disorderfs live_regular live_reversed_order --reverse-dirents=yes --multi-user=yes -o suid,dev

See also

Page maintainer: Roland Clobus