DEBOOTSTICK(8)

✨ DEBOOTSTICK ✨

okay bestie, so this is the manual page for debootstick, from the System Manager's Manual, section 8 (that's the sysadmin-y one 💅). Sit down, grab a strawberry 🍓, and let me tell you about the coolest little image-builder in the game.

---

🌸 NAME 🌸

debootstick — generate a bootable image from a Debian-based chroot environment 🦋

---

✨ SYNOPSIS ✨

debootstick [options] SOURCE DEST

---

💖 DESCRIPTION 💖

so basically, debootstick generates a bootable image (at DEST) from a Debian-based chroot environment (at SOURCE). that's it. that's the whole vibe. 🎀

The output image generated at DEST should then be copied to a USB stick, disk or SD card. (like, that's the whole point, you're making a little baby operating system and then yeeting it onto physical media ✨)

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). no cap, it just knows. 👑

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. 💀 (in a good way)

---

🎀 OPTIONS 🎀

debootstick follows the usual GNU command line syntax, with long options starting with two dashes (`-`). A summary of options is included below. here we go bestie, the full list, no skipping, I would never 🫶

• -h, --help — Show summary of options. (your lil map 🗺️)
• -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). > yes this is exactly as spicy as it sounds, root with no password, be careful bestie 😭
• --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. bestie this is THE workflow, main character energy fr fr ✨

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

---

🦋 CHROOT ENVIRONMENTS 🦋

An example of chroot environment generation for a PC system is given in the previous section. (scroll up bestie 👆)

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. like, don't put an armhf image on your x86 laptop and act surprised, iykyk 💀

---

🔥 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). iconic behaviour honestly 👑

Notes:

• CAUTION: Any data on the target disk will be lost! like. GONE. gone gone. 🙈
• 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. (do not do the thing. i'm begging 🙈)

---

🍓 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. periodt. ✨

---

🌸 AUTHORS 🌸

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

---

👑 SEE ALSO 👑

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

---

and that's the whole page bestie!! this one was dated November 2, 2020, and it lives in the System Manager's Manual as DEBOOTSTICK(8). go forth and make bootable images, you've got this 💖✨🎀