Ubuntu Manpage: debootstick - Generate a bootable image from a Debian-based chroot environment

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.)

--disk-layout DISK_LAYOUT_FILE
Specify an alternate disk layout configuration file. See section DISK LAYOUTS below.

--run-on-first-boot FIRST_BOOT_SCRIPT_FILE
Let debootstick run the specified custom script (or other kind of executable) on first boot, after
OS resizing or migration is completed. The path specified must be relative to the root of the
chroot environment.

--sector-size SECTOR_SIZE
Specify an alternate sector size (default is 512). For instance, to build an image that will be
flashed on a 4Kn disk, use --sector-size 4096.
See section DISK SECTOR SIZE below.

EXAMPLES

       The most common workflow is the following.

       1- Generate a chroot environment:
       debootstrap --variant=minbase buster /tmp/buster_tree

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

       3- Generate the bootable image:
       debootstick --config-root-password-ask /tmp/buster_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       buster      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.

DISK LAYOUTS

It is possible to modify the disk layout of the system debootstick generates.

If option --disk-layout is not specified, a default layout file is used, and the path of this file is
printed.
The preferred way to write a new layout file is to copy this default file, modify it, and then add option
--disk-layout <modified-layout>.
An example of a modification could be to set /var on a different partition or dedicated LVM volume.

Notes:
- Not all modifications are allowed. debootstick will print an error message if needed.
- Currently debootstick only handles fat and ext4 filesystems.

About the size of a partition or lvm volume:
- auto means debootstick will reserve enough space for this volume, with a little margin. For instance,
on a /boot partition with fat filesystem, it will estimate the size needed for the files stored there and
size the partition accordingly.
- <xx>[G|M] (e.g. 1G or 50M) means debootstick should allocate exactly the specified size to this
partition/volume. Use this preferably on LVM volumes or on the last disk partition: since previous disk
partitions cannot be resized, debootstick has to reserve the space for them on the disk image it
generates, which can make it large.
- <xx>% (e.g. 10%) means debootstick should allocate the given percentage of the disk to this
partition/volume.
- max means debootstick should allocate any remaining free space to this partition/volume.

Keep in mind that debootstick is supposed to generate a minimal image, and, at this time, it has no
knowledge about the size of the device where the image will be copied. Using max and <xx>% on an lvm
volume and on last partition allows one to ensure an appropriate disk layout, when the OS will expand
itself over the device (or migrate), on first boot.

If LVM is used, it is possible to set a custom volume group name by using keyword lvm_vg_name. For
instance, one could specify lvm_vg_name "MYVG" (quotes are optional). If not specified, or when special
value auto is given instead of the group name, debootstick generates a random name DBSTCK_<hex-value>.
Note that on first boot, even if a volume group name was specified, the system will first use the random
name DBSTCK_<hex-value>, and then rename it at the end of the bootup procedure. This allows the system
to boot properly even if the target name conflicts with a volume group already present on a secondary
disk.

DISK SECTOR SIZE

       If the image should be flashed on a disk with non-default logical sector size (default is 512 bytes), one
       may use option --sector-size <value> to change it.

       The  value  of  option  --sector-size  should match the logical sector size of the disk the image will be
       flashed on. Usually, this disk is a removable device with a logical sector size of 512 bytes. Thus, in  a
       vast majority of cases debootstick should generate a compatible image with its default option value.

       When  using  the  installer mode, the fact the target disk (i.e. the disk the OS will finally migrate to)
       has a different sector size does not mean the image sector size should be changed.

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 debootstick achieves is 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.