The build script is thus well suited for preparing a bootable
Live-USB stick that can be used as a substitute for special
purpose rescue distributions like Grml. In contrast to
traditional Live systems it can be used like a normal Linux
/ isn't read-only and union mounted with a ramdisk,
but normal read/write root and home filesystem).
virt-builder because it is very fast - modulo slow USB
write speeds and slow internet access.
2017, Georg Sauthoff firstname.lastname@example.org
# chmod juser /dev/sdz $ cat > config-local.sh hostname=f25-rescue.example.org pubkey="$HOME"/.ssh/my_key_ed25519.pub pwfile=rootpw dev=/dev/sdz $ ./build.sh [..] [1434.2] Finishing off Output file: /dev/sdz Output size: 14.5G Output format: raw Total usable space: 12.9G Free space: 10.5G (81%) + cat Created rescue system in /dev/sdz successfully. Test it with e.g.: qemu-system-x86_64 -enable-kvm -drive file=/dev/sdz,if=virtio,format=raw -m 2048 -netdev bridge,id=nd0,name=tap0,br=virbr0 -device e1000,netdev=nd0,id=d0 -display curses
I tested it with a 16 GB Sandisk Ultra Fit USB 3 stick which is a medium performance and low cost USB mass storage device (as of 2017). In my experience, it performs well enough for the described use cases.
The build script needs
virt-builder from libguestfs
- including XFS support.
For example, on a Fedora system:
# dnf install libguestfs-tools libguestfs-xfs
The used virt-builder enforces a minimal target image/device size of 6 GB - with Fedora 25 images.
As of early 2017 (Linux 4.9), writing a disk image to a relatively slow USB stick might trigger some disk bufferbloat symptoms - with the kernel defaults. Thus, it is a good idea to apply more sane settings.
Grml is a great live system for system administration
tasks. Unfortunately, as of 2017, the latest stable Grml image
was released 2014. In contrast to a boot image generated with
build.sh, Grml is based on Debian and it is
distributed as hybrid ISO image, i.e. it is bootable when written
to a CD but also when dumped to a USB stick. It is a classic Live
system, i.e. the software selection is restricted to fit on a CD.
Also, the filesystem is union mounted, i.e. filesystem changes
aren't retained between boots. Nowadays perhaps less relevant,
but still interesting - there is also a (larger) variant that
both includes a 32 and 64 Bit version of the live system (named
Grml96) , i.e. one can multi-boot into 32 or 64 Bit Debian via
On the other hand, an image produced by
build.sh is based on
the latest stable x86-64 Fedora with very current software and
Linux Kernel. It pretty much behaves like a standard Linux
system, e.g. the bootloader is the default Grub2 (not
ISOLINUX), the root/home filesystem is normally
mounted, i.e. read/write, such that changes are retained between
boots. The generation of the image can easily be customized.
Since it uses Grub2, it needs a BIOS that supports booting from a USB mass storage device (i.e. as if it were a harddisk). Basically every BIOS shipped after 2002 or so should be sufficient.
Of course, how to exactly instruct the BIOS to boot from the USB stick varies much between different vendors and versions. Some provide an extra boot menu that can be entered via pressing ESC, F12, F7 or something like that. With others the only way to boot from a USB mass storage device is to enter the real BIOS setup (e.g. via DEL or ESC), entering the boot order menu and selecting the USB stick there. Some BIOS also hide the USB stick under the category 'harddisks'. For certain use cases it would be optimal to be able to configure the BIOS boot order such that - if a USB stick is present - the BIOS should first try to boot from it before trying other devices. Unfortunately, while many BIOS support this for flopyy, cdrom, USB-floppy, USB-cdrom and similar legacy devices they don't support it for USB mass storage devices (i.e. USB sticks).
Currently, the build script uses the Fedora base image that is distributed by the libguestfs team. This image uses XFS for the root file system. In practice this works good enough - but perhaps it is beneficial to use a copy-on-write (COW) filesystem like Btrfs on USB flash drives.
There is an optimization opportunity to create the filesystems with parameters optimized for USB flash drives (cf. pages, erase blocks and segments). It has to be shown whether such tuning still makes sense with current flash device firmware, though. The default performance arguably is good enough.
Another feature to look into is the creation of encrypted
filesystems. For example, to protect data in case the USB stick
is lost. Currently,
virt-builder doesn't support