Skip to content
Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
README.md
build.sh
guest-setup.sh
package.list

README.md

Scripts for installing Fedora 25 to a raw disk using virt-builder and applying a default configuration suitable for console work like preparing a system for installation or rescuing data.

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 system (e.g. / isn't read-only and union mounted with a ramdisk, but normal read/write root and home filesystem).

It uses virt-builder because it is very fast - modulo slow USB write speeds and slow internet access.

2017, Georg Sauthoff mail@gms.tf

Example

# 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

Hardware

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.

Dependencies

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.

Comparison

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 this 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 the bootloader.

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

Outlook

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

You can’t perform that action at this time.