NAME¶

debootstick - Generate a bootable image from a Debian-based chroot environment

SYNOPSIS¶

debootstick [options] SOURCE DEST

DESCRIPTION¶

debootstick generates a bootable image (at DEST) from a Debian-based chroot environment (at SOURCE).
The output image generated at DEST should then be copied to a USB stick, disk or SD card.

debootstick can currently generate bootable images for:
- Standard PC systems (32 or 64bits)
- Raspberry Pi boards
This target system is automatically selected given the SOURCE chroot environment (Debian/Ubuntu or Raspbian-based).

Most popular options for generating the SOURCE directory are:
- exporting the content of a docker container
- using dedicated tools such as debootstrap(8) or qemu-debootstrap(1)
See section CHROOT ENVIRONMENTS below.

The embedded system is:
- ready to be used (no installation step)
- viable in the long-term, fully upgradable (kernel, bootloader included)
- compatible with BIOS and UEFI systems (PC), or Raspberry Pi Boards.

debootstick can also generate installer media (for PCs). See option --system-type below.

OPTIONS¶

debootstick follows the usual GNU command line syntax, with long options starting with two dashes (`-'). A summary of options is included below.

-h, --help: Show summary of options.
-v, --version: Show version of program.
--help-os-support: Describe which chroot environments are supported.
--system-type [live|installer]: Specify which kind of system is targeted. The default is live. When booting a system where installer was selected, the system will try to migrate to a larger device on first startup. If live was selected, or if no such option was specified, no migration will occur. See section INSTALLER MEDIA below.
--kernel-package PACKAGE_NAME: Specify the kernel that should be installed. Without this option, debootstick will install a default one (depending on the embedded distribution).
--config-hostname HOSTNAME: Specify the hostname the embedded system will have.
--config-kernel-bootargs BOOTARGS: Specify boot arguments to be added/removed from the kernel cmdline. Use a plus sign to get a bootarg added and a minus sign to have it removed from the existing bootloader configuration. For example, --config-kernel-bootargs "+console=ttyS0 -rootdelay" will add console=ttyS0 to the kernel cmdline, and remove any parameter matching rootdelay=<value> or just rootdelay. When no plus or minus sign is specified, the bootarg is added (like plus). An alternative to using this option is to have the bootloader installed and customized before you call debootstick.
--config-root-password-ask: Prompt for the root password of the embedded system and set it accordingly.
--config-root-password-none: Remove the root password of the embedded system (root login will not prompt any password).
--config-root-password-first-boot: Ask for the root password when the system will be booted for the first time.
--config-grub-on-serial-line: Update grub configuration to show boot menu on serial line. (This is obviously PC-specific.)

EXAMPLES¶

The most common workflow is the following.

1- Generate a chroot environment:
debootstrap --variant=minbase jessie /tmp/jessie_tree

2- (Optionally) customize it:
chroot /tmp/jessie_tree; [...]; exit

3- Generate the bootable image:
debootstick --config-root-password-ask /tmp/jessie_tree /tmp/img.dd
Enter root password:
Enter root password again:
OK
[...]

4- Test it with kvm.
cp /tmp/img.dd /tmp/img.dd-test # let's work on a copy, our test is destructive
truncate -s 2G /tmp/img.dd-test # simulate a copy on a 2G-large USB stick
kvm -m 2048 -hda /tmp/img.dd-test # the test itself (BIOS mode)

5- Copy the boot image to a USB stick or disk.
dd bs=10M if=/tmp/img.dd of=/dev/your-device

The USB device may now be booted on any BIOS or UEFI system.

CHROOT ENVIRONMENTS¶

An example of chroot environment generation for a PC system is given in the previous section.

In order to generate a chroot environment for a Raspberry Pi, you can use qemu-debootstrap(1):
qemu-debootstrap --no-check-gpg --arch=armhf --variant=minbase jessie rpi-fs http://mirrordirector.raspbian.org/raspbian

Exporting the OS files from a virtual machine or a docker container is another option to generate a chroot environment. The added benefit of this approach is that a virtualized environment is very convenient for the OS customization phase, before calling debootstick.

TARGET SYSTEM ARCHITECTURES¶

debootstick expects a chroot environment built for amd64 or i386 systems, or for Raspberry Pi boards. Of course, the resulting image will reflect this initial architecture, and thus it should be booted on a compatible system.

INSTALLER MEDIA¶

When first booting a system built with the --system-type installer option, it will look for a larger disk and move to that disk. This operation does not require a reboot. Once done, the system will just continue its bootup procedure (and the initial device can be removed).

Notes:
- CAUTION: Any data on the target disk will be lost!
- The system is moved, not copied. Thus the initial device cannot be used anymore after the migration, unless you copy an image on it again, of course.
- This option is not available for Raspberry Pi boards. It would make little sense anyway, since the SD card is usually the only bootable media available on this kind of board.

UEFI BOOTING¶

It is also possible to test the UEFI boot with kvm, if you have the ovmf package installed, by adding -bios /path/to/OVMF.fd to the kvm command line.

DESIGN NOTES¶

Many Live distributions propose a highly compressed system based on a squashfs image. They handle writes using an overlay based on a filesystem union. While this allows the system to remain compact in the first times, this also has disavantages:
- Some important files remain read-only and cannot be upgraded (that is the case of the linux kernel and the bootloader) which quickly leads to security issues or upgrade problems.
- Storing modified files in an overlay and never releasing the room needed for the original versions in the squashfs image is counter-productive in the long term.
One of the objectives behind debootstick was to provide a viable long-term live system, therefore this kind of setup has been discarded.

AUTHORS¶

Etienne Duble (etienne.duble@imag.fr) and contributors.

Source file:	debootstick.8.en.gz (from debootstick 2.4)
Source last updated:	2019-05-31T18:01:03Z
Converted to HTML:	2020-11-15T03:27:36Z