This ReadMe explains the additions and non-standard modifications this live-build tree has. Author: Andreas Loibl http://kanotix.acritox.com live-build: KANOTIX =================== The purpose of this live-build tree is to build "KANOTIX" (http://kanotix.com) live-images. Full Example: lb config -a amd64 -p kanotix-master --bootloader grub2 --gfxoverlays true lb build ./isohybrid-acritox kanotix64.iso will create a 64bit multi-hybrid-ISO with GRUB2 and embedded gfxoverlays. Compat ====== Compatibility functions to be able to build this tree with live-build version 2 and 3. live-build 3 introduced various changes, e.g. some live-config parameters have been renamed or removed, also the directory-structure of config/ has changed. These compatibility functions allow to use the old format even if you use live-build 3. If you do not want to use this compatibility feature just remove the following files: auto/compat auto/functions/compat Sorting the files on the ISO ============================ You can create a sortfile for genisoimage where you can specify the order in which the files will be put in the ISO9660-filesystem: config/binary_iso/isoimage.sort See the option "-sort" in the manual of genisoimage for details on the sortfile-format. Debpool ======= All packages listed in config/chroot_debpool/packages will be downloaded and a repository will be created on the ISO: binary/debian/ This repository will be signed using the keys defined in config/chroot_debpool/live-media-keyring.pub config/chroot_debpool/live-media-keyring.sec If you did not create these key-files they will be autogenerated. If you want to keep the autogenerated key-files just touch /config/chroot_debpool/keep then you will find the generated keys in debpool/ The debpool-feature is implemented using a function-hack and a chroot-hook: auto/functions/debpool-hook config/chroot_local-hooks/XX_debpool Gfxoverlays =========== Gfxoverlays are a way to embedd binary-graphics-drivers (nvidia, fglrx) into the ISO. It uses the Kanotix-scripts to download and build the drivers in the chroot and create an aufs overlay of each built driver that will be put onto the ISO. The live-boot-initrd will then load one of these overlays on top of the rootfs. Each version of the drivers defined in config/gfxoverlays/versions will be built by config/binary_local-hooks/gfxoverlays using build_gfxoverlay.sh if you enable if with lb config --gfxoverlays true and they will be stored in cache/gfxoverlays Isohybrid with GRUB2 and isohybrid-acritox ========================================== There are various hooks in this config tree that intend to prepare and configure the image to become a multi-hybrid-ISO (if you are using GRUB2 as bootloader): 1. Multiple config-files for GRUB2, not only one grub.cfg: all of the following files will be copied to binary/boot/grub: config/binary_grub/grub*.cfg 2. Kanotix-GRUB2-theme will be copied to the ISO: binary/boot/grub/ 3. EFI for x64: - an image with GRUB2 will be built (including modules) - an EFI-Shell will be downloaded config/binary_local-hooks/grub2-efi they will be stored in binary/efi/boot/ 4. An isohybrid-acritox space-file necessary for isohybrid-acritox will be created by config/binary_local-hooks/isohybrid-acritox it will be stored in binary/boot.isohybrid it has the highest ISO-sorting weight in config/binary_iso/isoimage.sort because it is important for isohybrid-acritox that this file is the first file on the ISO Numbering of kernels on the binary ================================== This config tree has a hack included that mimics the kernel-numbering of lb_binary_syslinux for lb_binary_grub2, meaning that if you use GRUB2 as bootloader the kernels will be named vmlinuz/initrd.img, vmlinuz2/initrd2.img, ... instead of their full kernel versions (vmlinuz-3.x.y-z, ...) This is done by some function-overloading in auto/functions/livebuild-hacks Build using tmpfs ================= use "lb config --tmpfs true" to enable. you may specify mount-options with --tmpfs-options, e.g. lb config --tmpfs-options "size=9G" to set the maximum size of the ramdisk to 9GB. "lb build" will then mount a tmpfs into the "tmpfs" directory and the build process will take place there. after the build the result and the cache will reside on the tmpfs, so if you want to keep them you should move or copy them to somewhere else. everything inside the "tmpfs" directory will be lost when umounting it, so if you want to save the cache for later builds you have to move (or copy) it: mv tmpfs/cache . live-build will not umount the "tmpfs" unless you run "lb clean --tmpfs" or "lb clean --all", so if you are going to do multiple builds without umounting the "tmpfs" you do not need to backup the cache, it will stay there and will be used for the next build. Including Kanotix-scripts ========================= All urls listed in scripts.urls will be fetched to config/chroot_local-includes/usr/local/bin/ when "lb config" is called. They will be removed on "lb clean".