This ReadMe explains the additions and non-standard modifications this live-build tree has.

Author: Andreas Loibl <andreas@andreas-loibl.de>
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".

