.\" (C) Copyright 2015 Etienne Dublé <etienne.duble@imag.fr>,
.\"
.TH DEBOOTSTICK 8 "November 2, 2020"
.\" Please adjust this date whenever revising the manpage.

.SH NAME
debootstick \- Generate a bootable image from a Debian-based chroot environment

.SH SYNOPSIS
.B debootstick
.RI [ options ]
.I SOURCE DEST

.SH DESCRIPTION

.B debootstick
generates a bootable image (at \fIDEST\fP) from a Debian-based chroot environment (at \fISOURCE\fP).
.br
The output image generated at \fIDEST\fP should then be copied
to a USB stick, disk or SD card.

.PP
\fBdebootstick\fP can currently generate bootable images for:
.br
- Standard PC systems (32 or 64bits)
.br
- Raspberry Pi boards
.br
This target system is automatically selected given the \fISOURCE\fP chroot environment
(Debian/Ubuntu or Raspbian-based).
.PP
Most popular options for generating the \fISOURCE\fP directory are:
.br
- exporting the content of a \fBdocker\fP container
.br
- using dedicated tools such as \fBdebootstrap\fP(8) or \fBqemu-debootstrap\fP(1)
.br
See section \fBCHROOT ENVIRONMENTS\fP below.

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

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

.SH OPTIONS
.B debootstick
follows the usual GNU command line syntax, with long
options starting with two dashes (`\-').
A summary of options is included below.
.TP
.B \-h, \-\-help
Show summary of options.
.TP
.B \-v, \-\-version
Show version of program.
.TP
.B \-\-help\-os\-support
Describe which chroot environments are supported.
.TP
.B \-\-system\-type [live|installer]
Specify which kind of system is targeted. The default is \fBlive\fP.
When booting a system where \fBinstaller\fP was selected,
the system will try to migrate to a larger device on first startup.
If \fBlive\fP was selected, or if no such option was specified,
no migration will occur.
See section \fBINSTALLER MEDIA\fP below.
.TP
.B \-\-kernel\-package PACKAGE_NAME
Specify the kernel that should be installed. Without this option, \fBdebootstick\fP
will install a default one (depending on the embedded distribution).
.TP
.B \-\-config\-hostname HOSTNAME
Specify the hostname the embedded system will have.
.TP
.B \-\-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, \fB\-\-config\-kernel\-bootargs \(dq+console=ttyS0 -rootdelay\(dq\fP
will add \fBconsole=ttyS0\fP to the kernel cmdline, and remove any parameter
matching \fBrootdelay=<value>\fP or just \fBrootdelay\fP.
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 \fBdebootstick\fP.
.TP
.B \-\-config\-root\-password\-ask
Prompt for the root password of the embedded system and set it accordingly.
.TP
.B \-\-config\-root\-password\-none
Remove the root password of the embedded system (root login will not prompt any password).
.TP
.B \-\-config\-root\-password\-first\-boot
Ask for the root password when the system will be booted for the first time.
.TP
.B \-\-config\-grub\-on\-serial\-line
Update grub configuration to show boot menu on serial line. (This is obviously PC-specific.)
.TP
.B \-\-disk\-layout DISK_LAYOUT_FILE
Specify an alternate disk layout configuration file. See section \fBDISK LAYOUTS\fP below.
.TP
.B \-\-run\-on\-first\-boot FIRST_BOOT_SCRIPT_FILE
Let \fBdebootstick\fP 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.
.TP
.B \-\-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 \fB\-\-sector\-size 4096\fP.
.br
See section \fBDISK SECTOR SIZE\fP below.

.SH EXAMPLES

The most common workflow is the following.

.PP
.B 1-
Generate a chroot environment:
.br
\fBdebootstrap\fP \-\-variant=minbase buster /tmp/buster_tree

.PP
.B 2-
(Optionally) customize it:
.br
\fBchroot\fP /tmp/buster_tree; [...]; exit

.PP
.B 3-
Generate the bootable image:
.br
\fBdebootstick\fP \-\-config\-root\-password\-ask /tmp/buster_tree /tmp/img.dd
.br
Enter root password:
.br
Enter root password again:
.br
OK
.br
[...]
.br

.PP
.B 4-
Test it with kvm.
.br
\fBcp\fP /tmp/img.dd /tmp/img.dd\-test    # let's work on a copy, our test is destructive
.br
\fBtruncate\fP \-s 2G /tmp/img.dd\-test    # simulate a copy on a 2G-large USB stick
.br
\fBkvm\fP \-m 2048 \-hda /tmp/img.dd\-test  # the test itself (BIOS mode)

.PP
.B 5-
Copy the boot image to a USB stick or disk.
.br
\fBdd\fP bs=10M if=\fB/tmp/img.dd\fP of=/dev/your\-device

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

.SH CHROOT ENVIRONMENTS

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

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

.PP
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 \fBdebootstick\fP.

.SH TARGET SYSTEM ARCHITECTURES
\fBdebootstick\fP 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.

.SH INSTALLER MEDIA

When first booting a system built with the \fB\-\-system\-type installer\fP
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).
.PP
Notes:
.br
- \fBCAUTION:\fP Any data on the target disk will be lost!
.br
- The system is \fBmoved\fP, not copied. Thus the initial device cannot be used
anymore after the migration, unless you copy an image on it again, of course.
.br
- This option is \fBnot\fP 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. 

.SH UEFI BOOTING

It is also possible to test the UEFI boot with \fBkvm\fP, if you have the
\fBovmf\fP package installed, by adding \fB\-bios /path/to/OVMF.fd\fP to
the \fBkvm\fP command line.

.SH DISK LAYOUTS

It is possible to modify the disk layout of the system \fBdebootstick\fP generates.
.PP
If option \fB\-\-disk\-layout\fP is not specified, a default layout file is used,
and the path of this file is printed.
.br
The preferred way to write a new layout file is to copy this default file, modify it,
and then add option \fB\-\-disk\-layout <modified\-layout>\fP.
.br
An example of a modification could be to set \fB/var\fP on a different partition or
dedicated LVM volume.
.PP
Notes:
.br
- Not all modifications are allowed. \fBdebootstick\fP will print an error message if needed.
.br
- Currently \fBdebootstick\fP only handles fat and ext4 filesystems.
.PP
About the size of a partition or lvm volume:
.br
- \fBauto\fP means \fBdebootstick\fP 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.
.br
- \fB<xx>[G|M]\fP (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, \fBdebootstick\fP has to
reserve the space for them on the disk image it generates, which can make it large.
.br
- \fB<xx>%\fP (e.g. 10%) means debootstick should allocate the given percentage of the
disk to this partition/volume.
.br
- \fBmax\fP means debootstick should allocate any remaining free space to this partition/volume.
.PP
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 \fBmax\fP and \fB<xx>%\fP 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.
.PP
If LVM is used, it is possible to set a custom volume group name by using keyword \fBlvm_vg_name\fP.
For instance, one could specify \fBlvm_vg_name "MYVG"\fP (quotes are optional).
If not specified, or when special value \fBauto\fP is given instead of the group name,
\fBdebootstick\fP generates a random name \fBDBSTCK_<hex\-value>\fP.
.br
Note that on first boot, even if a volume group name was specified, the system will first use the
random name \fBDBSTCK_<hex\-value>\fP, 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.

.SH 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 \fB\-\-sector\-size <value>\fP to change it.

The value of option \fB\-\-sector\-size\fP should match the logical sector size of \fBthe disk the
image will be flashed on\fP. 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 \fBnot\fP mean the image sector size should be changed.

.SH 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:
.br
- 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.
.br
- 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.
.br
One of the objectives \fBdebootstick\fP achieves is to provide a viable long-term
live system, therefore this kind of setup has been discarded.

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

.SH SEE ALSO
.BR debootstrap (8),
.BR qemu-debootstrap (1),
.BR kvm (1).