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

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.