Provided by: debootstick_2.5_amd64 bug


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


       debootstick [options] SOURCE DEST


       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.


       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.

              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.

              Prompt for the root password of the embedded system and set it accordingly.

              Remove the root password of the embedded system (root login  will  not  prompt  any

              Ask for the root password when the system will be booted for the first time.

              Update  grub configuration to show boot menu on serial line. (This is obviously PC-

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


       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:

       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.


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

       In order to generate  a  chroot  environment  for  a  Raspberry  Pi,  you  can  use  qemu-
       qemu-debootstrap    --no-check-gpg    --arch=armhf    --variant=minbase    buster   rpi-fs

       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.


       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.


       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

       - 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


       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.


       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.

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


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


       Etienne Duble ( and contributors.


       debootstrap(8), qemu-debootstrap(1), kvm(1).

                                         November 2, 2020                          DEBOOTSTICK(8)