NEW:
– kgen: –kernname=mykernel replaced by –rename=mykernel
– kgen: –initramfs=/file accepts a user generated initramfs gzipped cpio archive to embed into the kernel(use igen)
– kgen: –fixdotconfig attempts to fix kernel .config if not set. Currently checks for CONFIG_INITRAMFS_SOURCE only.
– igen: –rename=myinitramfs lets the user rename the initramfs
– igen: –plugin=/dir[,/dir] lets the user provide a custom root dir to append to the initramfs
– igen: –glibc will ship /lib/libnss_files.so.2 /lib/libnss_dns.so.2 /lib/libresolv.so.2 /lib/ld-linux.so.2 /lib/libc.so.6 from the host to the initramfs to make DNS resolution work
– igen: removed –stheme=theme in favor of –splash=theme
– igen: –linuxrc=/linuxrc[,/file] takes a custom linuxrc along with possible extra file (i.e. initrd.scripts initrd.defaults)

Initramfs features:
– busybox (custom .config and ship custom applets – tlenet udhcpc vi awk sed etc)
– cryptsetup (from host or from sources)
– lvm2 (from host or from sources)
– splash
– e2fsprogs (blkid – from sources)
– glibc for DNS resolution
– Funtoo boot-update kernel modules compatibility (/etc/boot.conf)

Kernel features:
– oldconfig
– menuconfig
– custom kernel name
– clean
– mrproper
– fakeroot
– nomodinstall
– embed custom initramfs

KIGen is intended as a Genkernel replacement for the Portage framework and supports Gentoo/Funtoo/Sabayon/VidaLinux.

It’s maintained on github.com/r1k0/kigen.

NEW: kernel class rewrite and bug fixes. k/igen works out of the box without any ebuild install if you’re too lazy setting up an overlay.

# git clone http://github.com/r1k0/kigen.git

You’ll need to pass the master config file or copy it to /etc.

# cd kigen
# ./kgen --config=doc/kigen.conf

Initramfs features:
– busybox (custom .config and ship custom applets – tlenet udhcpc vi awk sed etc)
– cryptsetup (from host or from sources)
– lvm2 (from host or from sources)
– splash
– e2fsprogs (blkid – from sources)
– Funtoo boot-update kernel modules compatibility (/etc/boot.conf)

Kernel features:
– oldconfig
– menuconfig
– custom kernel name
– clean
– mrproper
– fakeroot
– nomodinstall

KIGen is intended as a Genkernel replacement for the Portage framework and supports Gentoo/Funtoo/Sabayon/VidaLinux.

It’s maintained on github.com/r1k0/kigen.

NEW: kernel class rewrite and bug fixes. k/igen works out of the box without any ebuild install if you’re too lazy setting up an overlay.

# git clone http://github.com/r1k0/kigen.git

You’ll need to pass the master config file or copy it to /etc.

# cd kigen
# ./kgen --config=doc/kigen.conf

Initramfs features:
– busybox (custom .config and ship custom applets – tlenet udhcpc vi awk sed etc)
– cryptsetup (from host or from sources)
– lvm2 (from host or from sources)
– splash
– Funtoo boot-update kernel modules compatibility (/etc/boot.conf)

Kernel features:
– oldconfig
– menuconfig
– custom kernel name
– clean
– mrproper
– fakeroot
– nomodinstall

KIGen is intended as a Genkernel replacement for the Portage framework and supports Gentoo/Funtoo/Sabayon/VidaLinux.

It’s maintained on github.com/r1k0/kigen.

Because of the kgen/igen split I had to change to name of the directory from /modules to /kigen within the ebuild too.
This allows KIGen to work directly when cloned from git with the same code as when installed.

You are too lazy for setting up an overlay? Fine.

git clone http://github.com/r1k0/kigen.git

Remember to pass –config=doc/kigen.conf because you’ll be missing it in /etc.

Initramfs features:
– cryptsetup
– lvm2
– splash

Kernel features:
– oldconfig
– menuconfig
– custom kernel name
– clean
– mrproper
– fakeroot
– nomodinstall

KIGen is intended as a Genkernel replacement for the Portage framework and supports Gentoo/Funtoo/Sabayon/VidaLinux.

It’s maintained on github.com/r1k0/kigen.

KIGen is intended as a Genkernel replacement for the Funtoo framework and supports Gentoo/Sabayon/VidaLinux.

kigen has been split into kgen and igen for better/easier support.

It’s maintained on github.com/r1k0/kigen.

KIGen is intended as a Genkernel replacement for the Funtoo framework and supports Gentoo/Sabayon/VidaLinux.

It’s maintained on github.com/r1k0/kigen.

KIGen replaces it and aims at supporting non Portage systems too.
The is project page is accessible at http://github.com/r1k0/kigen and its ebuild at http://github.com/downloads/r1k0/kigen/kigen-9999.ebuild

Funkernel is intended as a Genkernel replacement for the Funtoo framework and supports Gentoo/Sabayon/VidaLinux.

It’s maintained on github.com/r1k0/funkernel by myself.

What’s new:
- improved sanity checks,
- improved installation steps,
- Funtoo stable and unstable chpasswd profiles fixed.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Stage4 builds (highly customizable).

Profiles supported

doc/gentoo.profile
doc/gentoo-noboot.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/funtoo.profile
doc/funtoo-noboot.profile
doc/funtoo-luks.profile
doc/funtoo-luks-noswap.profile
doc/~funtoo-noboot.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/exherbo-noboot.profile
doc/stage4.profile

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Exherbo builds (as standard as the doc says )
• Stage4 builds (highly customizable).

Profiles supported

doc/gentoo.profile
doc/gentoo-noboot.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/funtoo.profile
doc/funtoo-noboot.profile
doc/funtoo-luks.profile
doc/funtoo-luks-noswap.profile
doc/~funtoo-noboot.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/exherbo-noboot.profile
doc/stage4.profile

What’s new:
- a fast and light livecd featuring tools for all profiles,
- improved sanity checks,
- improved installation steps,
- Funtoo stable profiles.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Exherbo builds (as standard as the doc says )
• Stage4 builds (highly customizable).

Profiles supported

doc/gentoo.profile
doc/gentoo-noboot.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/funtoo.profile
doc/funtoo-noboot.profile
doc/funtoo-luks.profile
doc/funtoo-luks-noswap.profile
doc/~funtoo-noboot.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/exherbo-noboot.profile
doc/stage4.profile

What’s new:
- removed some error checking to give more freedom on a profile level (you can skip setting the $rootpw variable – handy when deploying stage4 – and you can skip the $part variable in case of dual boot – assumes your partition design is already done)
- new $stage_path variable for profile (use with caution due to size issue on a livecd)
- new .tar.gz stage support (for the $stage_uri profile variable)
- new .tar.lzma stage support (for the $stage_uri profile variable)
- new .tar.xz stage support (for the $stage_uri profile variable)
- stage4 support
- removed $logger variable from profile along with the install_logging_daemon routine (use $extra_packages to set syslog-ng for example)
- removed the $cron variable from profile along with the install_cron_daemon routine (use $extra_packages to set vixie-cron for example)
- removed the call to sanity_check_config() before starting the installation. Use ‘kicktoo -s ‘ to check the profile.
- ‘kicktoo-rescue’ now properly mounts /proc when chrooting.
- ‘kicktoo’ default password behavior uses Gentoo settings. In Gentoo you can still use ‘chpasswd –md5′ as no options are provided for chpasswd in Funtoo but rather uses SHA512 by default. Hence the extra password configuration in every Funtoo profile.

You can now install Gentoo/Funtoo stage4 tarballs (why not Exherbo too? not tested)
New default profiles have been updated.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Exherbo builds (as standard as the doc says )
• Stage4 builds (highly customizable).

Profiles supported

doc/gentoo.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/~funtoo.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/exherbo.profile
doc/stage4.profile ]]> http://www.openchill.org/?feed=rss2&p=855 2 http://www.openchill.org/?p=892 http://www.openchill.org/?p=892#comments Sun, 15 Nov 2009 10:58:50 +0000 erick http://www.openchill.org/?p=892 2 weeks offline and now we’re back online! Yiiihaaa

I was hosting all my vhosts on the same server behind a router. The real problem was that I had to go through 2 different carriers.
First wireless from the wifi router to my own room (in France) and another link going through a PLC (powerline coms). Sometimes the PLC link goes down which makes me debug by phone with my ol’ man and sometimes the wifi has just too much interference.

Now a friend is hosting me in exchange of maintenance: fair enough

What’s fixed:
- dfstouch progress bar bugfix (passing 1024K->1M 1024M->1G 1024G->1T resets to 0%, not anymore)

What’s new:
- dfstest released
- dfstouch –size option accepts M/G/T bytes
- dfstouch now displays a percent progress bar
- dfsopen –password prefix

aspire ~ # dfstest -h
Usage:
/usr/sbin/dfstest [options]

Options:
-f, --file [/path/fs] Path to your container
-l, --loop [loopback dev] Loopback device (typically /dev/loop0)
-s, --size [int]M/G/T Size of filesystem
-i, --hidden [int] Number of hidden devices
-b, --blocks [int] Number of blocks per hidden device
-p, --password [prefix] Provide an iterative password prefix
-h, --help This
-v, --version Version

Exampe:
/usr/sbin/dfstest -f /tmp/fs -l loop0 -s 400M -i 3
aspire ~ #


‘dfstest’ is now shipped within the denyfs project. It aims at running automatic create/open/inject data/close/reopen/compare data/reclose processes. You can provide parameters such the number of hidden device and/or the number of blocks (size of hidden device) per device.

By running ‘dfstest’ one will know whether your device design works or not. It prevents the user from manually testing all combinations. ‘dfstest’ will help the user finding the correct ‘dfstouch/dfsopen’ parameters.
‘dfstest’ is just an upper layer of ‘dfstouch/dfsopen/dfsclose’ where ‘dfsopen’ is an upper layer of ‘denyfs’ (it makes sense at the end).

Here is an example of what it would look like:

aspire denyfs-0.2.1 # dfstest -f /tmp/fs -l loop0 -s 400M -i 3 -b 2
>>> Creating filesystem 100%
>>> Binding to /dev/loop0 ... OK
>>> Setting up cryptsetup block devices ...
/dev/mapper/fs1 OK
/dev/mapper/fs2 OK
/dev/mapper/fs3 OK
>>> Sizing up block devices ...
Enlarging ...
Empty block 161 becomes block 0 of /dev/mapper/fs1
Empty block 60 becomes block 1 of /dev/mapper/fs1
Enlarging ...
Empty block 182 becomes block 0 of /dev/mapper/fs2
Empty block 187 becomes block 1 of /dev/mapper/fs2
Enlarging ...
Empty block 91 becomes block 0 of /dev/mapper/fs3
Empty block 124 becomes block 1 of /dev/mapper/fs3
>>> Mapping crytpsetup block devices to a new filesystem...
>>> Creating filesystems ...
>>> Mounting filesystems ...
/mnt/here1 mounted
/mnt/here2 mounted
/mnt/here3 mounted
>>> Injecting data ...
hidden1 > /mnt/here1/hidden1
hidden2 > /mnt/here2/hidden2
hidden3 > /mnt/here3/hidden3
>>> Dumping data ...
hidden1
hidden2
hidden3
>>> Unmounting filesystems ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping dmsetup block devices ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping cryptsetup devices ...
/dev/mapper/fs1 OK
/dev/mapper/fs2 OK
/dev/mapper/fs3 OK
>>> Unbinding /dev/loop0 ...
>>> Binding to /dev/loop0 ... OK
>>> Setting up cryptsetup block devices ...
/dev/mapper/fs1 OK
/dev/mapper/fs2 OK
/dev/mapper/fs3 OK
>>> Sizing up block devices ...
>>> Mapping crytpsetup block devices to a new filesystem...
>>> Mounting filesystems ...
/mnt/here1 mounted
/mnt/here2 mounted
/mnt/here3 mounted
>>> Comparing data ...
/mnt/here1/hidden1 data OK
/mnt/here2/hidden2 data OK
/mnt/here3/hidden3 data OK
Nb of blocks Device Device nb Size
+ 2 /dev/mapper/fs1 1 4Mb
+ 2 /dev/mapper/fs2 2 4Mb
+ 2 /dev/mapper/fs3 3 4Mb
+ 193 < -- Total nb of free blocks
-----------
= 199 <-- Total nb of blocks
space ratio: 96% free
>>> Unmounting filesystems ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping dmsetup block devices ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping cryptsetup devices ...
/dev/mapper/fs1 OK
/dev/mapper/fs2 OK
/dev/mapper/fs3 OK
>>> Unbinding /dev/loop0 ...
>>> SUCCESS
aspire denyfs-0.2.1 #


Should I precise unlimited under certain constraints; your environment especially the passwords entropy (generated by your kernel device), the size of the filesystem, the limitations of system open files and the hardware (especially the processor and the hard drive). Given a configured GNU/Linux system, denyfs can create a whole lot of hidden containers.

denyfs-0.2.0 ships a new –yes option that if passed will not ask you any question when it comes to resize. If you type in a wrong password then nothing will mount the process will fail. The usefulness of this option stands up during automated testings. It is advised to use the default behaviour.

‘dfstest’ is planned for the 0.2 branch but not yet ready. One step at a time. I’m currently writing it and the implementation is almost finished. I need to test dfstest before any release. Awesome, test the testers!

denyfs-0.2.0 supports hidden devices up to thousands. The maximum test yet performed so far succeeded in creating 1001 hidden devices of 512K size each (1 block) inside a 20Gb file in 129 minutes on a Gentoo Linux given appropriate ulimit rules:

openchill denyfs # uname -a
Linux openchill.org 2.6.30-gentoo-r2 #1 SMP Fri Jul 31 14:46:49 Local time zone must be set--see zic i686 Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz GenuineIntel GNU/Linux
openchill denyfs # ulimit -a | grep open
open files (-n) 20048
openchill denyfs #


Such a command line would look like that (no space within the -d parameter, it’s just text formatting here):
openchill denyfs # dfsopen -f /tmp/fs -l loop0 -d
1=1,2=1,3=1,4=1,5=1,6=1,7=1,8=1,9=1,10=1,
11=1,12=1,13=1,14=1,15=1,16=1,17=1,18=1,19=1,20=1,
21=1,22=1,23=1,24=1,25=1,26=1,27=1,28=1,29=1,30=1,
31=1,32=1,33=1,34=1,35=1,36=1,37=1,38=1,39=1,40=1,
41=1,42=1,43=1,44=1,45=1,46=1,47=1,48=1,49=1,50=1,
51=1,52=1,53=1,54=1,55=1,56=1,57=1,58=1,59=1,60=1,
61=1,62=1,63=1,64=1,65=1,66=1,67=1,68=1,69=1,70=1,
71=1,72=1,73=1,74=1,75=1,76=1,77=1,78=1,79=1,80=1,
81=1,82=1,83=1,84=1,85=1,86=1,87=1,88=1,89=1,90=1,
91=1,92=1,93=1,94=1,95=1,96=1,97=1,98=1,99=1,100=1,
101=1,102=1,103=1,104=1,105=1,106=1,107=1,108=1,109=1,110=1,
111=1,112=1,113=1,114=1,115=1,116=1,117=1,118=1,119=1,120=1,
121=1,122=1,123=1,124=1,125=1,126=1,127=1,128=1,129=1,130=1,
131=1,132=1,133=1,134=1,135=1,136=1,137=1,138=1,139=1,140=1,
141=1,142=1,143=1,144=1,145=1,146=1,147=1,148=1,149=1,150=1,
151=1,152=1,153=1,154=1,155=1,156=1,157=1,158=1,159=1,160=1,
161=1,162=1,163=1,164=1,165=1,166=1,167=1,168=1,169=1,170=1,
171=1,172=1,173=1,174=1,175=1,176=1,177=1,178=1,179=1,180=1,
181=1,182=1,183=1,184=1,185=1,186=1,187=1,188=1,189=1,190=1,
191=1,192=1,193=1,194=1,195=1,196=1,197=1,198=1,199=1,200=1,
201=1,202=1,203=1,204=1,205=1,206=1,207=1,208=1,209=1,210=1,
211=1,212=1,213=1,214=1,215=1,216=1,217=1,218=1,219=1,220=1,
221=1,222=1,223=1,224=1,225=1,226=1,227=1,228=1,229=1,230=1,
231=1,232=1,233=1,234=1,235=1,236=1,237=1,238=1,239=1,240=1,
241=1,242=1,243=1,244=1,245=1,246=1,247=1,248=1,249=1,250=1,
251=1,252=1,253=1,254=1,255=1,256=1,257=1,258=1,259=1,260=1,
261=1,262=1,263=1,264=1,265=1,266=1,267=1,268=1,269=1,270=1,
271=1,272=1,273=1,274=1,275=1,276=1,277=1,278=1,279=1,280=1,
281=1,282=1,283=1,284=1,285=1,286=1,287=1,288=1,289=1,290=1,
291=1,292=1,293=1,294=1,295=1,296=1,297=1,298=1,299=1,300=1,
301=1,302=1,303=1,304=1,305=1,306=1,307=1,308=1,309=1,310=1,
311=1,312=1,313=1,314=1,315=1,316=1,317=1,318=1,319=1,320=1,
321=1,322=1,323=1,324=1,325=1,326=1,327=1,328=1,329=1,330=1,
331=1,332=1,333=1,334=1,335=1,336=1,337=1,338=1,339=1,340=1,
341=1,342=1,343=1,344=1,345=1,346=1,347=1,348=1,349=1,350=1,
351=1,352=1,353=1,354=1,355=1,356=1,357=1,358=1,359=1,360=1,
361=1,362=1,363=1,364=1,365=1,366=1,367=1,368=1,369=1,370=1,
371=1,372=1,373=1,374=1,375=1,376=1,377=1,378=1,379=1,380=1,
381=1,382=1,383=1,384=1,385=1,386=1,387=1,388=1,389=1,390=1,
391=1,392=1,393=1,394=1,395=1,396=1,397=1,398=1,399=1,400=1,
401=1,402=1,403=1,404=1,405=1,406=1,407=1,408=1,409=1,410=1,
411=1,412=1,413=1,414=1,415=1,416=1,417=1,418=1,419=1,420=1,
421=1,422=1,423=1,424=1,425=1,426=1,427=1,428=1,429=1,430=1,
431=1,432=1,433=1,434=1,435=1,436=1,437=1,438=1,439=1,440=1,
441=1,442=1,443=1,444=1,445=1,446=1,447=1,448=1,449=1,450=1,
451=1,452=1,453=1,454=1,455=1,456=1,457=1,458=1,459=1,460=1,
461=1,462=1,463=1,464=1,465=1,466=1,467=1,468=1,469=1,470=1,
471=1,472=1,473=1,474=1,475=1,476=1,477=1,478=1,479=1,480=1,
481=1,482=1,483=1,484=1,485=1,486=1,487=1,488=1,489=1,490=1,
491=1,492=1,493=1,494=1,495=1,496=1,497=1,498=1,499=1,500=1,
501=1,502=1,503=1,504=1,505=1,506=1,507=1,508=1,509=1,510=1,
511=1,512=1,513=1,514=1,515=1,516=1,517=1,518=1,519=1,520=1,
521=1,522=1,523=1,524=1,525=1,526=1,527=1,528=1,529=1,530=1,
531=1,532=1,533=1,534=1,535=1,536=1,537=1,538=1,539=1,540=1,
541=1,542=1,543=1,544=1,545=1,546=1,547=1,548=1,549=1,550=1,
551=1,552=1,553=1,554=1,555=1,556=1,557=1,558=1,559=1,560=1,
561=1,562=1,563=1,564=1,565=1,566=1,567=1,568=1,569=1,570=1,
571=1,572=1,573=1,574=1,575=1,576=1,577=1,578=1,579=1,580=1,
581=1,582=1,583=1,584=1,585=1,586=1,587=1,588=1,589=1,590=1,
591=1,592=1,593=1,594=1,595=1,596=1,597=1,598=1,599=1,600=1,
601=1,602=1,603=1,604=1,605=1,606=1,607=1,608=1,609=1,610=1,
611=1,612=1,613=1,614=1,615=1,616=1,617=1,618=1,619=1,620=1,
621=1,622=1,623=1,624=1,625=1,626=1,627=1,628=1,629=1,630=1,
631=1,632=1,633=1,634=1,635=1,636=1,637=1,638=1,639=1,640=1,
641=1,642=1,643=1,644=1,645=1,646=1,647=1,648=1,649=1,650=1,
651=1,652=1,653=1,654=1,655=1,656=1,657=1,658=1,659=1,660=1,
661=1,662=1,663=1,664=1,665=1,666=1,667=1,668=1,669=1,670=1,
671=1,672=1,673=1,674=1,675=1,676=1,677=1,678=1,679=1,680=1,
681=1,682=1,683=1,684=1,685=1,686=1,687=1,688=1,689=1,690=1,
691=1,692=1,693=1,694=1,695=1,696=1,697=1,698=1,699=1,700=1,
701=1,702=1,703=1,704=1,705=1,706=1,707=1,708=1,709=1,710=1,
711=1,712=1,713=1,714=1,715=1,716=1,717=1,718=1,719=1,720=1,
721=1,722=1,723=1,724=1,725=1,726=1,727=1,728=1,729=1,730=1,
731=1,732=1,733=1,734=1,735=1,736=1,737=1,738=1,739=1,740=1,
741=1,742=1,743=1,744=1,745=1,746=1,747=1,748=1,749=1,750=1,
751=1,752=1,753=1,754=1,755=1,756=1,757=1,758=1,759=1,760=1,
761=1,762=1,763=1,764=1,765=1,766=1,767=1,768=1,769=1,770=1,
771=1,772=1,773=1,774=1,775=1,776=1,777=1,778=1,779=1,780=1,
781=1,782=1,783=1,784=1,785=1,786=1,787=1,788=1,789=1,790=1,
791=1,792=1,793=1,794=1,795=1,796=1,797=1,798=1,799=1,800=1,
801=1,802=1,803=1,804=1,805=1,806=1,807=1,808=1,809=1,810=1,
811=1,812=1,813=1,814=1,815=1,816=1,817=1,818=1,819=1,820=1,
821=1,822=1,823=1,824=1,825=1,826=1,827=1,828=1,829=1,830=1,
831=1,832=1,833=1,834=1,835=1,836=1,837=1,838=1,839=1,840=1,
841=1,842=1,843=1,844=1,845=1,846=1,847=1,848=1,849=1,850=1,
851=1,852=1,853=1,854=1,855=1,856=1,857=1,858=1,859=1,860=1,
861=1,862=1,863=1,864=1,865=1,866=1,867=1,868=1,869=1,870=1,
871=1,872=1,873=1,874=1,875=1,876=1,877=1,878=1,879=1,880=1,
881=1,882=1,883=1,884=1,885=1,886=1,887=1,888=1,889=1,890=1,
891=1,892=1,893=1,894=1,895=1,896=1,897=1,898=1,899=1,900=1,
901=1,902=1,903=1,904=1,905=1,906=1,907=1,908=1,909=1,910=1,
911=1,912=1,913=1,914=1,915=1,916=1,917=1,918=1,919=1,920=1,
921=1,922=1,923=1,924=1,925=1,926=1,927=1,928=1,929=1,930=1,
931=1,932=1,933=1,934=1,935=1,936=1,937=1,938=1,939=1,940=1,
941=1,942=1,943=1,944=1,945=1,946=1,947=1,948=1,949=1,950=1,
951=1,952=1,953=1,954=1,955=1,956=1,957=1,958=1,959=1,960=1,
961=1,962=1,963=1,964=1,965=1,966=1,967=1,968=1,969=1,970=1,
971=1,972=1,973=1,974=1,975=1,976=1,977=1,978=1,979=1,980=1,
981=1,982=1,983=1,984=1,985=1,986=1,987=1,988=1,989=1,990=1,
991=1,992=1,993=1,994=1,995=1,996=1,997=1,998=1,999=1,1000=1,1001=1
-m /mnt/here -k -y

This will run for a couple of hours. To run such a huge number of containers in “production” you’ll _have_ to alter dfsopen and write your own password generator. You don’t want to manually type in 1000 passwords. You want a clever loop that will autogenerate your passwords for the flaring containers and ask interactively for your real hidden password when processing the 754th container for example. You can now hide 512Kb of data in each of the 1000 containers.

I think it may become handy to have such a program. One that will autogenerate passwords for flaring containers and just ask the manual typing for the real hidden container. I will think about that.

dfsclose usage() now reflects what it does:
aspire 0.1.3 # dfsclose -h
Usage:
/usr/sbin/dfsclose [options]

Example:
/usr/sbin/dfsclose -f /tmp/fs -l loop0 -n 9
aspire 0.1.3 #

dfstouch has been updated to display a progress bar. It will look like:
12+6 enregistrements lus
12+5 enregistrements écrits
8416766 octets (8,4 MB) copiés, 11,3928 s, 739 kB/s
The user gets informed in real time of the file creation. Convenient when you create a 50G file.

dfsclose usage() now reflects what it does:
aspire 0.1.2 # dfsclose -h
Usage:
scripts/dfsclose [options]

Example:
dfsclose -f fs -l loop0 -n 9
aspire 0.1.2 #

Minor header update in denyfs itself.

I recently came across this news:
http://it.slashdot.org/story/09/08/12/1255241/Encryption-What-Encryption?from=rss

I was expecting it since the first time I dug into steganographic filesystems. This goes back to when I was in university. At that time in UK the RIP Act had been voted in 2000.

From wikipedia:

Especially contentious was Part III of the Act, which requires persons to supply decrypted information (which had been previously encrypted by the owner) and/or the cryptographic key to government representatives. Failure to disclose these items is a criminal offence, with a maximum penalty of two years in jail.

Reading through the post I went back to have a look at denyfs I hosted on tuxfamily that was doing the job so well. I still have that denyfs-cvs.ebuild somewhere I thought. And then I went back to google and saw what had been done since the past few years. Surprisingly only Truecrypt is still supporting this feature. The old and dusty Rubberhose has not moved from an inch I still can’t make it work and deniability filesystems are still not popular. Few know its concept (outside image processing which is lame honestly;) and even fewer actually use this tool in the public domain except paranoid or curious users.

I don’t understand how Truecrypt implements their steganographic feature; it creates a standard Truecrypt volume and using the free space from this same volume it hides data within it says. From a social perspective who would that convince you are not using the steganographic feature? It is too much of a binary concept. You have a steganographic filesystem or not but noone can prove it exists or not so it still sucks because you get prosecuted by part III.

The way I see steganographic filesystems is more nuanced and balanced; a user should be able to have as many passwords as his social deniability scheme requires him to, period.

To create deniability you have to fit the profile that you don’t hold information people want and most of all you gotta prove it. What if now you do provide them data but a convincing flare instead? The purpose of a data flare would be to confuse as to the fact you hold sensitive information. The deniability concept lives by its social application. The system should allow the user to deny as much as he planned to knowing that to deny you have to prove it in the real world. You may hold not valuable information which especially crafted and presented may incline to a plausible and probable deniability. This becomes possible with multiple volumes; and the more volumes the more arguments a user may have.

The idea is to let the software fit the user social scheme and the precious data it hides. A user could create 9 hidden volumes within a single random file each of which would decrypt sensitively increasing data. Depending on the password you provide one of the 9 volumes will open. This scheme would allow a greater ability to adapt on social events and social scenarios may be built and accredited by providing a password that would decrypt a precise volume only.

In theory, the denyfs design should allow an unlimited amount of volumes (given constraints). In practice it is limited to 9 (more will fail – known bug) volumes (with an 80% free space ratio) within a single file or less depending on your password combination (because some hash password combinations will overlap blocks therefore failing during creation, you’ll have to change password of the specific device failure).

denyfs-0.1.1 ships:

• denyfs – core program
• dfstouch – will allocate random space for your outer container
• dfsopen – will open your container and the devices within
• dfsclose – will close all devices and the container

The ‘/usr/sbin/denyfs’ binary is still available but you don’t have to interact with it anymore for a daily use or if you want to customize stuff then you’d be better wrapping your own scripts around. The good news too is that I made a ‘configure.in’ file and a ‘Makefile.in’; you can use make install’ and ‘make uninstall’ regardless of your package manager. Whatever your Linux distro installing from sources should be easier than using an ebuild or dpkg.

denyfs-0.1.1 requires:

• util-linux (losetup)
• cryptsetup (to create a cryptsetup volume)
• device-mapper (libdevmapper.h is required to compile)

Tutorial:

1. First create a container in a location of your choice.

aspire 0.1.1 # dfstouch -h
Usage:
/usr/sbin/dfstouch [options]

Options:
-f, --file [/path/fs] Path to your filesystem
-c, --count [int] Block iteration (multiple of 512K)
-h, --help This
-v, --version Print version

Example:
# this creates a 200M file container
/usr/sbin/dfstouch -f fs -c 400

aspire 0.1.1 #
aspire 0.1.1 # dfstouch -f /tmp/fs -c 400
>>> Creating 204M fs ... OK
aspire 0.1.1 #


2. Then open the file and give your secret volume mapping. Assume the stealth volume is the 3rd one. The -m option will create your volume mount points within /mnt/here. The -k option asks to create an Ext2 filesystem an top of the new volumes. Of course -k is required only for the first time.

aspire 0.1.1 # dfsopen -h
Usage:
/usr/sbin/dfsopen [options]

Options:
-f, --file [/path/fs] Path to your container
-b, --block [int]K/M Size of a single block
-c, --count [int] Block iteration (-b X -c = size of file)
-m, --mount [/path] Path to mountpoint
-k, --mkfs Initialize the filesystem (run the first time only)
-h, --help This
-v, --version Print version

Example:
# note the -k option will create a filesystem when first run
/usr/sbin/dfsopen -f fs -l loop0 -d 1=2,2=2,3=5,4=2,5=6,6=4,7=2,8=3,9=2 -m /mnt/here -k

# a daily command
/usr/sbin/dfsopen -f fs -l loop0 -d 1=2,2=2,3=5,4=2,5=6,6=4,7=2,8=3,9=2 -m /mnt/here

aspire 0.1.1 #
aspire 0.1.1 # dfsopen -f /tmp/fs -l loop0 -d 1=10,2=3,3=1 -m /mnt/here -k
>>> Binding to loop0 ... OK
>>> Mapping cryptsetup block devices ...
Enter passphrase:
Enter passphrase:
Enter passphrase:
>>> Sizing up block devices ...
device 1 ...
Checking device structure ...
Do you intend to resize? (CTRL-C to abort)
Enlarging ...
using empty block 81 becomes block 0 of /dev/mapper/fs1
using empty block 84 becomes block 1 of /dev/mapper/fs1
using empty block 5 becomes block 2 of /dev/mapper/fs1
using empty block 83 becomes block 3 of /dev/mapper/fs1
using empty block 86 becomes block 4 of /dev/mapper/fs1
using empty block 95 becomes block 5 of /dev/mapper/fs1
using empty block 15 becomes block 6 of /dev/mapper/fs1
using empty block 18 becomes block 7 of /dev/mapper/fs1
using empty block 64 becomes block 8 of /dev/mapper/fs1
using empty block 67 becomes block 9 of /dev/mapper/fs1
device 2 ...
Checking device structure ...
Do you intend to resize? (CTRL-C to abort)
Enlarging ...
using empty block 4 becomes block 0 of /dev/mapper/fs2
using empty block 8 becomes block 1 of /dev/mapper/fs2
device 3 ...
Checking device structure ...
Do you intend to resize? (CTRL-C to abort)
Enlarging ...
using empty block 90 becomes block 0 of /dev/mapper/fs3
>>> Mapping to crytpsetup block devices ...
Checking device structure ...
Checking device structure ...
Checking device structure ...
>>> Creating filesystems ...
mke2fs 1.41.8 (11-July-2009)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=1024 (log=0)
Taille de fragment=1024 (log=0)
5136 i-noeuds, 20480 blocs
0 blocs (0.00%) réservés pour le super utilisateur
Premier bloc de données=1
Nombre maximum de blocs du système de fichiers=20971520
3 groupes de blocs
8192 blocs par groupe, 8192 fragments par groupe
1712 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
8193

Écriture des tables d'i-noeuds : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

Le système de fichiers sera automatiquement vérifié tous les 20 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
mke2fs 1.41.8 (11-July-2009)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=1024 (log=0)
Taille de fragment=1024 (log=0)
1024 i-noeuds, 4096 blocs
0 blocs (0.00%) réservés pour le super utilisateur
Premier bloc de données=1
Nombre maximum de blocs du système de fichiers=4194304
1 groupe de bloc
8192 blocs par groupe, 8192 fragments par groupe
1024 i-noeuds par groupe

Écriture des tables d'i-noeuds : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

Le système de fichiers sera automatiquement vérifié tous les 37 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
mke2fs 1.41.8 (11-July-2009)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=1024 (log=0)
Taille de fragment=1024 (log=0)
256 i-noeuds, 2048 blocs
0 blocs (0.00%) réservés pour le super utilisateur
Premier bloc de données=1
Nombre maximum de blocs du système de fichiers=2097152
1 groupe de bloc
8192 blocs par groupe, 8192 fragments par groupe
256 i-noeuds par groupe

Écriture des tables d'i-noeuds : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

Le système de fichiers sera automatiquement vérifié tous les 21 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
>>> Mounting filesystems ...
/mnt/here1 mounted
/mnt/here2 mounted
/mnt/here3 mounted
aspire 0.1.1 #

3. Check things are as expected. Verify your block table matches your design. The -t option will dump you a view of the space ratio. Dump the block offset per volume using the -o option.

aspire 0.1.1 #
aspire 0.1.1 # df -h | grep here
/dev/mapper/fs1_new 20M 172K 20M 1% /mnt/here1
/dev/mapper/fs2_new 3,9M 29K 3,9M 1% /mnt/here2
/dev/mapper/fs3_new 2,0M 21K 2,0M 2% /mnt/here3
aspire 0.1.1 #
aspire 0.1.1 # mount | grep here
/dev/mapper/fs1_new on /mnt/here1 type ext2 (rw)
/dev/mapper/fs2_new on /mnt/here2 type ext2 (rw)
/dev/mapper/fs3_new on /mnt/here3 type ext2 (rw)
aspire 0.1.1 #
aspire 0.1.1 # tree -h /mnt/here?
/mnt/here1
`-- [ 12K] lost+found
/mnt/here2
`-- [ 12K] lost+found
/mnt/here3
`-- [ 12K] lost+found

3 directories, 0 files
aspire 0.1.1 #
aspire 0.1.1 # denyfs -h
Usage:
denyfs [option]

Where [option] is one of the following:
-t, --table [loop]? display devices block table
-l, --list-freeblocks [loop]? list free blocks
-o, --offset [cryptsetup device] print offsets of blocks of a single device
-s, --setsize [int1],[int2] [loop]? set size of device nb [int1] with [int2] block
-d, --dmsetup [new device] dmsetup device mount
-v, --version version
-h, --help this.

Example:
denyfs -o /dev/mapper/fs1
denyfs -t /dev/mapper/fs?
denyfs -s 1,12 /dev/mapper/fs?
denyfs -s 2,2 /dev/mapper/fs?
denyfs -l /dev/mapper/fs?
denyfs -d fs1_new /dev/mapper/fs1

aspire 0.1.1 #
aspire 0.1.1 # denyfs -t /dev/mapper/fs?
Checking device structure ...
Nb of blocks Device Device nb Size
+ 10 /dev/mapper/fs1 1 20Mb
+ 2 /dev/mapper/fs2 2 4Mb
+ 1 /dev/mapper/fs3 3 2Mb
+ 86 < -- Total nb of free blocks
-----------
= 99 <-- Total nb of blocks
space ratio: 86% free
aspire 0.1.1 #
aspire 0.1.1 # denyfs -o /dev/mapper/fs1
Checking device structure ...
0 4096 linear /dev/mapper/fs1 331882
4096 4096 linear /dev/mapper/fs1 344170
8192 4096 linear /dev/mapper/fs1 20586
12288 4096 linear /dev/mapper/fs1 340074
16384 4096 linear /dev/mapper/fs1 352362
20480 4096 linear /dev/mapper/fs1 389226
24576 4096 linear /dev/mapper/fs1 61546
28672 4096 linear /dev/mapper/fs1 73834
32768 4096 linear /dev/mapper/fs1 262250
36864 4096 linear /dev/mapper/fs1 274538
aspire 0.1.1 #
aspire 0.1.1 # denyfs -o /dev/mapper/fs2
Checking device structure ...
0 4096 linear /dev/mapper/fs2 16490
4096 4096 linear /dev/mapper/fs2 32874
aspire 0.1.1 #
aspire 0.1.1 # denyfs -o /dev/mapper/fs3
Checking device structure ...
0 4096 linear /dev/mapper/fs3 368746
aspire 0.1.1 #
aspire 0.1.1 #

4. Now hide your data. Fill in /mnt/here1 /mnt/here2 and /mnt/here3 the last one being your secret place, here2 a data flare (supposed to be a fake secret place) and here1 just personal garbage. Let’s put 15Mb in here1 3Mb in here2 and 1Mb in here1.

aspire 0.1.1 # ls -lh sizzla*
-rwxr-xr-x 1 root root 4,0M août 23 14:56 sizzla.mp3
-rwxr-xr-x 1 root root 691K août 23 15:26 sizzla-small.mp3
-rw-r--r-- 1 root root 16M août 23 14:57 sizzlax4.mp3
aspire 0.1.1 # cp sizzlax4.mp3 /mnt/here1
aspire 0.1.1 # cp sizzla.mp3 /mnt/here2/
aspire 0.1.1 # cp sizzla-small.mp3 /mnt/here3
aspire 0.1.1 #
aspire 0.1.1 # tree -h /mnt/here?
/mnt/here1
|-- [ 12K] lost+found
`-- [ 16M] sizzlax4.mp3
/mnt/here2
|-- [ 12K] lost+found
`-- [4.0M] sizzla.mp3
/mnt/here3
|-- [ 12K] lost+found
`-- [691K] sizzla-small.mp3

3 directories, 3 files
aspire 0.1.1 #

5. Close all volumes.

aspire 0.1.1 # dfsclose -h
Usage:
/usr/sbin/dfsclose [options]

Options:
-f, --file [/path/fs] Path to your filesystem
-l, --loop [loop] Loop device
-n, --numdev [int] Number of sub devices
-h, --help This
-v, --version Print version

Example:
/usr/sbin/dfsclose -f fs -l loop0 -n 9
aspire 0.1.1 #
aspire 0.1.1 # dfsclose -f fs -l loop0 -n 3
>>> Unmounting filesystems ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping dmsetup block devices ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping cryptsetup devices ...
/dev/mapper/fs1 OK
/dev/mapper/fs2 OK
/dev/mapper/fs3 OK
>>> Unbinding /dev/loop0 ...
aspire 0.1.1 #
aspire 0.1.1 # mount | grep here
aspire 0.1.1 # ls /dev/mapper/
control root swap
aspire 0.1.1 #

6. Let’s reopen them all and check we still have the files and close again.

aspire 0.1.1 # dfsopen -f /tmp/fs -l loop0 -d 1=10,2=3,3=1 -m /mnt/here
>>> Binding to loop0 ... OK
>>> Mapping cryptsetup block devices ...
Enter passphrase:
Enter passphrase:
Enter passphrase:
>>> Sizing up block devices ...
device 1 ...
Checking device structure ...
device 2 ...
Checking device structure ...
device 3 ...
Checking device structure ...
>>> Mapping to crytpsetup block devices ...
Checking device structure ...
Checking device structure ...
Checking device structure ...
>>> Mounting filesystems ...
/mnt/here1 mounted
/mnt/here2 mounted
/mnt/here3 mounted
aspire 0.1.1 # tree -h /mnt/here?
/mnt/here1
|-- [ 12K] lost+found
`-- [ 16M] sizzlax4.mp3
/mnt/here2
|-- [ 12K] lost+found
`-- [4.0M] sizzla.mp3
/mnt/here3
|-- [ 12K] lost+found
`-- [691K] sizzla-small.mp3

3 directories, 3 files
aspire 0.1.1 # dfsclose -f fs -l loop0 -n 3
>>> Unmounting filesystems ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping dmsetup block devices ...
/dev/mapper/fs1_new OK
/dev/mapper/fs2_new OK
/dev/mapper/fs3_new OK
>>> Unmapping cryptsetup devices ...
/dev/mapper/fs1 OK
/dev/mapper/fs2 OK
/dev/mapper/fs3 OK
>>> Unbinding /dev/loop0 ...
aspire 0.1.1 #

7. Open the hidden volume only add a file to it and close it.

aspire 0.1.1 # dfsopen -f /tmp/fs -l loop0 -d 3=1 -m /mnt/here
>>> Binding to loop0 ... OK
>>> Mapping cryptsetup block devices ...
Enter passphrase:
>>> Sizing up block devices ...
device 1 ...
Checking device structure ...
>>> Mapping to crytpsetup block devices ...
Checking device structure ...
>>> Mounting filesystems ...
/mnt/here1 mounted
aspire 0.1.1 #
aspire 0.1.1 # tree -h /mnt/here?
/mnt/here1
|-- [ 12K] lost+found
`-- [691K] sizzla-small.mp3
/mnt/here2
/mnt/here3

1 directory, 2 files
aspire 0.1.1 #
aspire 0.1.1 # echo pi > /mnt/here1/secret
aspire 0.1.1 # tree -h /mnt/here?
/mnt/here1
|-- [ 12K] lost+found
|-- [ 3] secret
`-- [691K] sizzla-small.mp3
/mnt/here2
/mnt/here3

1 directory, 2 files
aspire 0.1.1 #
aspire 0.1.1 # dfsclose -f fs -l loop0 -n 1
>>> Unmounting filesystems ...
/dev/mapper/fs1_new OK
>>> Unmapping dmsetup block devices ...
/dev/mapper/fs1_new OK
>>> Unmapping cryptsetup devices ...
/dev/mapper/fs1 OK
>>> Unbinding /dev/loop0 ...
aspire 0.1.1 #

8. Open the hidden volume only with a wrong password.

aspire 0.1.1 # dfsopen -f /tmp/fs -l loop0 -d 3=1 -m /mnt/here
>>> Binding to loop0 ... OK
>>> Mapping cryptsetup block devices ...
Enter passphrase:
>>> Sizing up block devices ...
device 1 ...
Checking device structure ...
Do you intend to resize? (CTRL-C to abort) ^C
aspire 0.1.1 #
At this point you should be _very_ careful. If you do not intend to resize your volume than you must realize that your password is wrong (the password is parameter of the block mapping logic). If you do pursue you will resize the hidden volume. Although in some very lucky and special cases, if you enlarge your volume you may again access your previously hidden data, don’t assume that in general as shrinking the volume will erase it for sure (unless again you free unused blocks but you’d really be lucky and you should play Euromillion).

Finally, as long as you understand that given the password you provide a different block mapping will appear, you should be fine as a user.

To really measure the true power of denyfs you have to “feel”. You have to feel the volume size compared to one another, the free space ratio and the randomness of all your passwords. This is the human parameter to that program. Strange I know, but denyfs is a system which logic on passwords and size mapping shoudn’t be written (it is way more complex than denyfs itself) and won’t work for any given size mapping and passwords.
You are strongly advised to play around and test it (wisely choose your size mapping and passwords) before actually using it for “hurm”… production purposes.

Taking a quick nap. So much effort, it is tiring!

At that moment, you feel like you’re taking 5G!

Landing went like a charm but what you don’t see is a quick through up 20seconds afterwards hehehe, felt better then.

One of the best experience ever. I’ll do it again, solo this time

Full videos: Céline and myself

All distro specific code has been removed from the inner routines of Kicktoo. We should have a minimum amount of code for distro specific logic. Kicktoo seeds by default from a Gentoo stage. Then by design Kicktoo allows the user to rewrite the content of inner functions (what I called inner functions is the runstep sequence you can read below). This allows you to seed from “any distro” stage as long as you rewrite the code corresponding to the appropriate runstep sequence. All distro specific code should be held within the profile, period.

This way, we can reach a level a customizability that I have never seen even with the now unsupported GLI (Gentoo Linux Installer). OK, you’ll have to write some code to reflect your needs but that’s a good thing!

The “dist” variable is still available within the profile but its sole purpose is to provide a couple of ifs for the config sanity checking. It’s handy when you have many profiles to grep around too.

For years now, I’ve always used the same steps/commands to deploy my Gentoo systems. Playing around Funtoo and Exherbo one can quickly realize how much similar (by design and structure) they are. When you realize that, you become aware that altering some functions to install your Funtoo or your Exherbo is simple and straightforward.  Exherbo is a small (yet) fast growing distro. I really like what they are trying to achieve but to be fair, it does not work all the time where it should and where Gentoo or Funtoo never fails (anymore). I have in mind the inability to install syslog-ng or cron straight out from the box and the unstability of arbor (some days it’s ok some others it breaks). I’m sure their process will strengthen as Exherbo intends to be more stable than Gentoo by setting the +test flag for all packages (the Gentoo testers would know how ambitious this sounds).

Again, given the time that has passed since the first Gentoo stage (10 years now) appeared, not much has changed (if not almost nothing) concerning the structure of an installation. Look, you still have to partition, format, download the stage and the repo, untar, mount, chroot, etc… This is _always_ the same. Everybody knows it and nobody thinks of a sort of standard, a sort of unified scheme that would acknowledge _by design_ that their distro is not the only one. Keyword here is _by design_. Let the user do the work, provide a reference point (default installs Gentoo) and tools that let them adapt change and customize the default in an elegant way.

Let’s assume there is some sort of necessary steps a distro has to pass through to be built. Let’s assume there is a standard for it. Or let’s try to follow our own generic (and so gentooish) way to install and customize a Gentoo/Funtoo/Exherbo stage.

Kicktoo defines a sequenced set of functions that are all individually customizable:

1. partition
2. setup_md_raid
3. setup_lvm
4. luks_devices
5. format_devices
6. mount_local_partitions
7. mount_network_shares
8. unpack_stage_tarball
9. prepare_chroot
10. install_repo_tree
11. setup_fstab
12. install_cryptsetup
13. build_kernel
14. install_logging_daemon
15. install_cron_daemon
16. setup_network_post
17. setup_root_password
18. setup_timezone
19. setup_keymap
20. setup_host
21. install_bootloader
22. configure_bootloader
23. install_extra_packages
24. add_and_remove_services
25. run_post_install_script
26. finishing_cleanup

Within your profile you can replace a whole step sequence by skipping it using the “skip” variable and by redefining the function logic you are skipping somewhere else during the runstep sequence.

To help you locate and write your new code you can use 2 function prefix:

• pre_${one_of_the_inner_functions}
• post_${one_of_the_inner_functions}

For example, you want to use Kicktoo to install an Exherbo distribution. Then you’ll know that by default Gentoo uses genkernel to build an initramfs and a kernel. You’ll know that Funtoo is compatible too. And you’ll know that Exherbo has nothing to do with genkernel. Therefore you’ll have to rewrite the code executed by the  build_kernel function.

In your profile, this portion of code would look like that:

# rewrite build_kernel routine
post_setup_fstab() {
spawn_chroot "paludis -i ${kernel_sources}" || die "could not paludis vanilla sources"
# create /usr/src/linux link
spawn_chroot "eclectic kernel set 1" || die "could not symlink sources to /usr/src/linux"
fetch "${kernel_config_uri}" "${chroot_dir}/usr/src/linux/.config" || die "could not fetch kernel config"
# compile
spawn_chroot "cd /usr/src/linux && make oldconfig && make && make modules_install" || die "could not build the kernel"
spawn_chroot "cp /usr/src/linux/arch/${arch}/boot/bzImage /boot/kernel-genkernel-${arch}-2.6" || die "could not copy the kernel"
}
skip build_kernel


This means that you define a function called post_setup_fstab() that will run just after setup_fstab(). If you created a pre_setup_fstab() function it would run just before.

WARNING: you cannot hook up pre_ and post_ to a function you are skipping. You cannot use “skip ${function}” and “pre_${function}() { echo plop }”. The “skip” statement will prevail and pre_${function}() won’t run.

The trick is to hook up your code to another inner function, after the previous or before the next ones. It’s up to you. And finally, you understand why there is no point hooking after finishing_cleanup().

New default profiles have been updated.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Exherbo builds (as standard as the doc says ).

Gentoo and Funtoo will have the same basic user settings as allowed by profile options (refer to doc/config.txt). Be aware that to get knowledge of all variables available you’ll have to navigate within the Kicktoo sources especially the modules/install_steps.sh file. It defines all routines mentionned above. You’ll want to read them to rewrite them. This is left to your own initiative.

Exherbo uses grub2 only and does not use genkernel! Therefore don’t expect an initramfs: write your own routine.

Grub2 and Baselayout2 configuration are supported. Kicktoo detects if grub-0.xx or 1.xx is pulled; same for baselayout1 and 2. Grub is the only configuration supported for now. LiLo boot configuration is not yet supported; will do soon.

Profiles supported

doc/gentoo.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/~funtoo.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/exherbo.profile

Let’s see how gentoo.profile looks like:

dist gentoo

part sda 1 83 100M
part sda 2 82 2048M
part sda 3 83 +

format /dev/sda1 ext2
format /dev/sda2 swap
format /dev/sda3 ext3

mountfs /dev/sda1 ext2 /boot
mountfs /dev/sda2 swap
mountfs /dev/sda3 ext3 / noatime

stage_uri http://dev.funtoo.org/linux/gentoo/x86/stage3-x86-current.tar.bz2
tree_type sync
kernel_config_uri http://www.openchill.org/kconfig.2.6.30
kernel_sources gentoo-sources
timezone UTC
cron vixie-cron
rootpw a
bootloader grub
logger syslog-ng
extra_packages net-misc/dhcpcd openssh
keymap fr
hostname gentoo
net eth0 dhcp
rcadd vixie-cron default
rcadd syslog-ng default
#rcadd sshd default

post_install_repo_tree() {
cat > ${chroot_dir}/etc/make.conf <
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS="\${CFLAGS}"
USE="-X -gtk -gnome -kde -qt"
EOF
}

Let’s see how ~funtoo.profile looks like:

dist funtoo

chroot_dir /mnt/funtoo

part sda 1 83 100M
part sda 2 82 2048M
part sda 3 83 +

format /dev/sda1 ext2
format /dev/sda2 swap
format /dev/sda3 ext3

mountfs /dev/sda1 ext2 /boot
mountfs /dev/sda2 swap
mountfs /dev/sda3 ext3 / noatime

stage_uri http://dev.funtoo.org/linux/~funtoo/x86/stage3-x86-current.tar.bz2
tree_type snapshot http://dev.funtoo.org/linux/~funtoo/snapshots/portage-current.tar.bz2
kernel_config_uri http://www.openchill.org/kconfig.2.6.30
kernel_sources gentoo-sources
timezone UTC
cron vixie-cron
rootpw a
bootloader grub
logger syslog-ng
extra_packages net-misc/dhcpcd
keymap be-latin1 # fr en
hostname ~funtoo
net eth0 dhcp
rcadd vixie-cron default
rcadd syslog-ng default

skip install_repo_tree
pre_setup_fstab(){
# actual replacement code for install_repo_tree routine
fetch "${portage_snapshot_uri}" "${chroot_dir}/$(get_filename_from_uri ${portage_snapshot_uri})" || die "could not fetch portage snapshot"
spawn "tar xjf ${chroot_dir}/$(get_filename_from_uri ${portage_snapshot_uri}) -C ${chroot_dir}/usr" || die "could not unpack portage snapshot"
spawn_chroot "cd /usr/portage && git checkout funtoo.org" || die "could not checkout funtoo git repo"

# create make.conf
cat > ${chroot_dir}/etc/make.conf <
ACCEPT_KEYWORDS="~x86"
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS="\${CFLAGS}"
USE="-X -gtk -gnome -kde -qt"
EOF
}

#########################################
# shadow -pam fix http://bugs.gentoo.org/275555
#
#post_setup_fstab() {
# spawn_chroot "emerge gentoolkit" || die "gentoolkit failed"
# spawn_chroot "euse pam -D" || die "can't set USE to -pam"
# spawn_chroot "emerge shadow" || die "custom shadow compile failed"
#}


Let’s see how exherbo.profile looks like:

dist exherbo

chroot_dir /mnt/exherbo

part sda 1 82 2048M
part sda 2 83 +

format /dev/sda1 swap
format /dev/sda2 ext3

mountfs /dev/sda1 swap
mountfs /dev/sda2 ext3 / noatime

net eth0 dhcp
stage_uri http://dev.exherbo.org/stages/exherbo-x86-current.tar.xz
tree_type sync
kernel_config_uri http://www.openchill.org/kconfig.2.6.30
kernel_sources vanilla-sources
rootpw a
bootloader grub
keymap be-latin1 # fr en
hostname exherbo

skip unpack_stage_tarball
skip prepare_chroot # need to rewrite because of -o rbind
skip install_repo_tree
pre_setup_fstab(){
# rewrite unpack_stage_tarball
fetch "${stage_uri}" "${chroot_dir}/$(get_filename_from_uri ${stage_uri})" || die "Could not fetch stage tarball"
spawn "unxz -c ${chroot_dir}/$(get_filename_from_uri ${stage_uri}) | tar x -C ${chroot_dir}" || die "Could not untar stage tarball"

# rewrite prepare_chroot
spawn "cp /etc/resolv.conf ${chroot_dir}/etc/resolv.conf" || die "could not copy /etc/resolv.conf into chroot"
spawn "cat /proc/mounts > ${chroot_dir}/etc/mtab" || die "could not create "
spawn "mount -o rbind /dev ${chroot_dir}/dev/" || die "could not rbind /dev"
spawn "mount -t proc none ${chroot_dir}/proc" || die "could not mount proc"
spawn "mount -o bind /sys ${chroot_dir}/sys" || die "could not bind-mount /dev"

# rewrite install_repo_tree
spawn_chroot "paludis -i paludis" || die "could not update paludis"
spawn_chroot "paludis --sync" || die "could not sync exheres tree"
# often breaks, you might want to run/debug that after reboot
# spawn_chroot "paludis -i everything --dl-reinstall if-use-changed --dl-upgrade always" || die "could not update stage"
}

post_setup_fstab() {
spawn_chroot "paludis -i ${kernel_sources}" || die "could not paludis vanilla sources"
spawn_chroot "eclectic kernel set 1" || die "could not symlink sources to /usr/src/linux"
fetch "${kernel_config_uri}" "${chroot_dir}/usr/src/linux/.config" || die "could not fetch kernel config"
spawn_chroot "cd /usr/src/linux && make oldconfig && make && make modules_install" || die "could not build the kernel"
spawn_chroot "cp /usr/src/linux/arch/${arch}/boot/bzImage /boot/kernel-genkernel-${arch}-2.6" || die "could not copy the kernel"
# configure_bootloader() expects a kernel name created by genkernel hence the name format
# you could always rewrite configure_bootloader() to accept another kernel name format
}

skip build_kernel
skip install_logging_daemon
skip install_cron_daemon
#pre_setup_network_post() { # bugs
# spawn_chroot "paludis -i ${logging_daemon}" || die "could not paludis logging daemon"
# spawn_chroot "paludis -i ${cron_daemon}" || die "could not paludis cron daemon"
#}

skip install_bootloader
pre_configure_bootloader(){
spawn_chroot "paludis -i ${bootloader}" || die "could not install bootloader"
}

skip install_extra_packages
post_configure_bootloader(){
for p in ${extra_packages}
do
spawn_chroot "paludis -i ${p}" || die "could not install extra packages"
done
}

NOTE: you are strongly encouraged to copy/paste these profiles (and all Kicktoo code) and test them, enhance them and please please please post them back here so we can support more distros and more flavors!

It is likely that from now on the development work will take place within the profile itself. I think Kicktoo gains more value depending on the number of different profiles. The more profiles the more different ways we can customize Gentoo/Funtoo/Exherbo _and_ any other source distro that provides a stage to bootstrap from and a repo. I don’t think Sourcemage or Lunar do provide stages to build from, last time I checked a livecd was doing all the job. I’m not aware of any distro Kicktoo might support but if they provide a stage tarball and a repo tree it can technically work with the current Kicktoo version by tweaking the hell out of your profile.

Please post all Kicktoo related comments here, bugs, requests, patch or whatever as long as you post your profile too.

A quick post to point out (and remind me) that while having the same code supporting both Gentoo/Funtoo for installation is a great idea. Or more precisely a smart lazy idea (what I seek as a dev).

Then adding a few dozen lines for Exherbo sounded like  a nice and sweet idea too few months ago, but…

…Now that I have a more accurate (still not precise enough though)  feeling about Exherbo (arbor stability in general) as a common (Funtoo nerd) user, I do not think doing so much (couple of dozen lines here and there no biggy opposed to 2 lines since then for Gentoo/Funtoo) change of Kicktoo inner functions gives as much value to the software as I intend to.

So here is (for now) a better idea. Why not reverting all Exherbo change from the kicktoo code, keep it simple and stable for Gentoo/Funtoo installation and produce a tweaked out template for Exherbo using the full potential of ‘pre_’ ‘skip’ and ‘post_’  functions. We’ll hit twice with the same stone: we keep the code clean with the less changes and we produce a complex rewrite of the engine to support Exherbo stage and paludis all within a template.

Right now sounds cool, so I’ll deeply think about it and hope something comes out of it

Kicktoo now fixes a bug that prevented from installing Exherbo. Exherbo requires /dev/pts to be mounted from its boot medium.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Exherbo builds (as standard as the doc says minus the typos).

Gentoo and Funtoo will have the same basic user settings as allowed by profile options (refer to doc/config.txt).

Exherbo uses grub2 only and does not use genkernel! Therefore don’t expect an initramfs and a fine tuned grub.cfg configuration file.
When I’ll have more time, I’m willing to adapt genkernel for this purpose (exheres-0) only. This will get initramfs support for installing Exherbo.

Profiles supported

doc/gentoo.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/funtoo.profile
doc/~funtoo.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/~exherbo.profile

Functions in profile!

Sometimes you need to slightly alter the behavior of your profile. You want it to install X or not and you want this but not that.
To achieve a high level of customization, no need to do a lot of code, just a smart design should be enough. Quickstart had thought this through.

You can insert special functions inside the profile that will modify the behavior of your installation.
This will empower the user by giving him the choice and the tool to interact
with the installer in a more precise way. It is up to your own responsibility to choose how you want to interact with the Kicktoo engine.

Here are the core functions of Kicktoo in that very order (some don’t run if not defined for their purpose in the profile, like raid lvm luks):

partition
setup_md_raid (optional)
setup_lvm (optional)
luks_devices (optional)
format_devices
mount_local_partitions
mount_network_shares (optional)
unpack_stage_tarball
prepare_chroot
install_repo_tree
setup_fstab
install_cryptsetup (optional)
build_kernel
install_logging_daemon (optional)
install_cron_daemon (optional)
setup_network_post (optional)
setup_root_password (optional)
setup_timezone (optional)
setup_keymap (optional)
setup_host (optional)
install_bootloader
configure_bootloader
install_extra_packages (optional)
add_and_remove_services
run_post_install_script
finishing_cleanup

You have 2 ways of interacting with each of them.

Append a ‘pre_‘ or a ‘post_‘ before any of the functions to create a shell
function inside your profile. Then put in your ‘ubercoolcustomization’
in bash please.

A ‘pre_${func}()‘ will be called just before the actual ${func} is called.
A ‘post_${func}()’ will be called just after the actual ${func} is called.

Simply put pre_build_kernel will be called just before the real build_kernel .
post_setup_host will run just after the real setup_host.

Inside default profiles and when appropriate, you should see the ‘post_install_repo_tree’ function.
Well it simply creates your /etc/make.conf file before anything is pulled and compiled.

Finally, you can see how are numerous the ways of interaction with your profile. You could if you needed too, customize the hell out of your profile and create pre_ and post_ functions for each Kicktoo routine.
You could even rewrite the whole Kicktoo routines inside your profile by using ‘pre_${func}’ ‘post_${func}‘ with the ‘skip ${func}’ parameter.
You would write the statements like this:
pre_setup_host() {
# here is my uber code
}
skip setup_host
post_setup_host() {
# uber code again
}
NOTE: you don’t need pre_ and post_ at the same time, you redefine your function by skipping it and recoding it inside either a pre_ of a post_ function.

Of course, this works regardless of the distro you plan to install.

Kicktoo now detects when grub2 is pulled by any type of profile and supports its configuration format.
Grub2 is default on Exherbo but masked on Gentoo/Funtoo.

Livecd Medium

Kicktoo can run on any decent livecd as long as the medium has sufficient tools and kernel modules available.

Two ways to run Kicktoo:

• USB key install (usually for netbooks – aspire one, eeepc..)

To build a bootable usb system, you should use UNetbootin, especially PartedMagic (or else if you plan on using lvm)

• CDROM install (usually for laptops and desktops)

Although you could use Ubuntu, Knoppix, Gentoo or any major livecd, the Gentoo people recommend to burn a SystemRescueCd copy.
I do recommend PartedMagic if you don’t want the Kicktoo livecd.
It’s light and bundles all needed tools except lvm2 that gets buggy if I recall well.

Then boot in:
# dhcpcd eth0
# cd /tmp
# wget http://www.openchill.org/kicktoo/kicktoo-0.2.3.tar.bz2
# tar xfj kicktoo-0.2.3.tar.bz2
# vi doc/<profile>                               # choose and adapt a profile to your needs
# ./kicktoo -v doc/<profile>

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable) and its stable git’d portage
• Funtoo builds (unstable) and its unstable git’d portage version
• Exherbo builds (as standard as the doc says minus the typos).

Gentoo and Funtoo will have the same basic user settings as allowed by profile options (refer to doc/config.txt).

Exherbo uses grub2 only and does not use genkernel! Therefore don’t expect an initramfs and a fine tuned grub.cfg configuration file.
When I’ll have more time, I’m willing to adapt genkernel for this purpose (exheres-0) only. This will get initramfs support for installing Exherbo.

Profiles supported

doc/gentoo.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/funtoo.profile
doc/~funtoo.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile
doc/~exherbo.profile

Functions in profile!

Sometimes you need to slightly
alter the behavior of your profile. You want it to install X or not and
you want this but not that.
To achieve a high level of customization, no need to do a lot of code, just a smart design should be enough.
Quickstart had thought this through.

You can insert special functions inside the profile that will modify the behavior of your installation.
This
will empower the user by giving him the choice and the tool to interact
with the installer in a more precise way. It is up to your own
responsibility to choose how you want to interact with the Kicktoo
engine.

Here are the core functions of Kicktoo in that very order (some don’t run if not defined for their purpose in the profile, like raid lvm luks):

partition
setup_md_raid (optional)
setup_lvm (optional)
luks_devices (optional)
format_devices
mount_local_partitions
mount_network_shares (optional)
unpack_stage_tarball
prepare_chroot
install_repo_tree
setup_fstab
install_cryptsetup (optional)
build_kernel
install_logging_daemon (optional)
install_cron_daemon (optional)
setup_network_post (optional)
setup_root_password (optional)
setup_timezone (optional)
setup_keymap (optional)
setup_host (optional)
install_bootloader
configure_bootloader
install_extra_packages (optional)
add_and_remove_services
run_post_install_script
finishing_cleanup

You have 2 ways of interacting with each of them.

Append
a ‘pre_‘ or a ‘post_‘ before any of the functions to create a shell
function inside your profile. Then put in your ‘ubercoolcustomization’
in bash please.

A ‘pre_${func}()‘ will be called just before the actual ${func} is called.
A ‘post_${func}()’ will be called just after the actual ${func} is called.

Simply put pre_build_kernel will be called just before the real build_kernel .
post_setup_host will run just after the real setup_host.

Inside default profiles and when appropriate, you should see the ‘post_install_repo_tree’ function.
Well it simply creates your /etc/make.conf file before anything is pulled and compiled.

Finally, you can see how are numerous the ways of interaction with your profile. You could if you needed too, customize the hell out of your profile and create pre_ and post_ functions for each Kicktoo routine.
You could even rewrite the whole Kicktoo routines inside your profile by using ‘pre_${func}’ ‘post_${func}‘ with the ‘skip ${func}’ parameter.
You would write the statements like this:
pre_setup_host() {
# here is my uber code
}
skip setup_host
post_setup_host() {
# uber code again
}
NOTE: you don’t need pre_ and post_ at the same time, you redefine your function by skipping it and recoding it inside either a pre_ of a post_ function.

Of course, this works regardless of the distro you plan to install.

Livecd Medium

Kicktoo can run on any decent livecd as long as the medium has sufficient tools and kernel modules available.

Two ways to run Kicktoo:

• USB key install (usually for netbooks – acer aspire one, asus eeepc)

To build a bootable usb system, you should use UNetbootin, especially PartedMagic.

• CDROM install (usually for laptops and desktops)

Although you could use Ubuntu, Knoppix, Gentoo or any major livecd, Gentoo recommends to burn a SystemRescueCd copy.
But I do recommend PartedMagic if you don’t want the Kicktoo livecd.
It’s light and bundles all needed tools except lvm2 that gets buggy if I recall well.

Then boot in:
# dhcpcd eth0
# cd /tmp
# wget http://www.openchill.org/kicktoo/kicktoo-0.2.2.tar.bz2
# tar xfj kicktoo-0.2.2.tar.bz2
# vi doc/gentoo.profile                               # choose and adapt a profile to your needs
# ./kicktoo -v doc/gentoo.profile

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable), Funtoo builds (unstable) and its git’d portage version.

Gentoo and Funtoo will have the same basic user settings as allowed by profile options (refer to doc/config.txt).

Profiles supported

doc/gentoo.profile
doc/gentoo-lvm.profile
doc/gentoo-luks.profile
doc/gentoo-luks-noswap.profile
doc/funtoo.profile
doc/~funtoo.profile
doc/~funtoo-luks.profile
doc/~funtoo-luks-noswap.profile

However, so few bundle the required tools to install Gentoo in all its flavors.

First, we need a kernel config that will discover your HD devices as SATA devices and not ATA. I want my drives to be detected as /dev/sd and not /dev/hd.
Slax typically does this kind of nonsense although it ships the cryptsetup program.
I succeed once on installing a basic Gentoo system but it was really painful.

Basically the ultimate Gentoo liveusb needs to ship:
 - cryptsetup binary (to support the –luks genkernel install)
 - SATA drivers (we want /dev/sd)
 - xz-utils (we want unxz to decompress exherbo stages)

Seems quite easy as a requirement. Let’s use UNetbootin, there are so many distros out there that should support those. I even tried to feed the SystemRescueCD iso to Unetbootin (it has what we need) but Unetbootin screws up somehow on next boot.

Finally, after hours of testing distros from UNetbootin, let me tell you that the only liveusb distro I found that supports _all_ of the above is: PartedMagic.

And it’s only 70M! Crazy!

I tried all major liveusb and none where having the tools I need, so here is my tip!

This default setup tries as much as possible to follow the LVM2 Gentoo handbook.

New Profile

doc/gentoo-lvm.profile

dist gentoo

part sda 1 83 100M
part sda 2 82 2048M
part sda 3 83 8000M
part sda 4 8e +      # linux lvm type

lvm_volgroup vg /dev/sda4

lvm_logvol vg 10G usr
lvm_logvol vg 5G  home
lvm_logvol vg 5G  opt
lvm_logvol vg 10G var
lvm_logvol vg 2G  tmp

format /dev/sda1    ext2
format /dev/sda2    swap
format /dev/sda3    ext3
format /dev/vg/usr  ext3
format /dev/vg/home ext3
format /dev/vg/opt  ext3
format /dev/vg/var  ext3
format /dev/vg/tmp  ext3

mountfs /dev/sda1    ext2 /boot
mountfs /dev/sda2    swap
mountfs /dev/sda3    ext3 /     noatime
mountfs /dev/vg/usr  ext3 /usr  noatime
mountfs /dev/vg/home ext3 /home noatime
mountfs /dev/vg/opt  ext3 /opt  noatime
mountfs /dev/vg/var  ext3 /var  noatime
mountfs /dev/vg/tmp  ext3 /tmp  noatime

stage_uri               http://www.funtoo.org/linux/gentoo/x86/stage3-x86-current.tar.bz2
tree_type               sync
kernel_config_uri       http://www.openchill.org/kicktoo/kconfig.stable
genkernel_opts          –lvm # required
kernel_sources          gentoo-sources
timezone                      UTC
cron                             vixie-cron
rootpw                        a
bootloader                 grub
logger                             syslog-ng
extra_packages          lvm2 dhcpcd openssh
keymap                          fr
hostname                gentoo-lvm
net                               eth0 dhcp
rcadd                      vixie-cron default
rcadd                        syslog-ng  default
rcadd                      sshd       default

post_install_portage_tree() {
cat > ${chroot_dir}/etc/make.conf <<EOF
CHOST=”i686-pc-linux-gnu”
CFLAGS=”-O2 -march=i686 -pipe”
CXXFLAGS=”\${CFLAGS}”
USE=”-X -gtk -gnome -kde -qt”
EOF
}

sha1sum livecd: ef8133505332b667e48e391332bf9caa0c3e350d
Kicktoo-0.2.1-x86.iso 78.87Mb (zisofs based)

Livecd Medium

Kicktoo can run on any decent livecd as long as the medium has sufficient tools and kernel modules available.

Two ways to run Kicktoo:

• USB key install (usually for netbooks)

To build a bootable usb system, you should use UNetbootin.

• CDROM install (usually for laptops and desktops)

Although you could use Ubuntu, Knoppix, Gentoo or any major livecd, it is recommended to burn a SystemRescueCd copy if you don’t want the Kicktoo livecd.

Then boot in:
# dhcpcd eth0
# cd /tmp
# wget openchill.org/kicktoo/kicktoo-0.2.1.tar.bz2
# tar xfj kicktoo-0.2.1.tar.bz2
# vi doc/gentoo.profile                               # choose and adapt a profile to your needs
# ./kicktoo -v doc/gentoo.profile

However, since we try an attempt at building an exherbo distro, the main stage requires xz-utils to unxz it. This can be found only on the SystemRescueCd mentioned above but somehow there is an issue with kicktoo running on it (but: /boot partition reports mounted but acts as not).

So I packed a minimal livecd, that holds cryptsetup, lvm2, evms2, dmraid, xz-utils to fully enable Gentoo, Funtoo or Exherbo coming soon.

A simple livecd running a simple installer.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (stable), Funtoo builds (unstable) and its git’d portage version.

Profiles supported

doc/gentoo.profile
doc/funtoo.profile
doc/~funtoo.profile
doc/~funtoo-luks.profile

Few months ago, I even forked my own catalyst to suit my own very needs. I then finally understood than it’s a very well coded software but sadly poorly designed.
Debugging and attempting to patch is a headache and I get at least every couple of months one of those loop0-squashfs bug on startup that prevents my CD to boot.
Switching to zisofs is always my trick because I simply never found a solution. Then by some magic few months later I try the squashfs option and it works again. Until a next run make it unbootable as nothing changed.

This happened yet again this afternoon. No typical solution other than “get your kernel .config right and support squahsfs” even when you said the previous run built and ran like a charm..

So here again, I’m switching to zisofs and inherit an extra 16Mb on the CD, WTF!? I really hate catalyst, yet it does what I need, sometimes.

I’ve been playing around an interesting tool, Metro, which caught my attention. Drobbins maintains it (lucky me!) and a quick look at it shows a more comprehensive design.

The only thing it doesn’t is building livecd. So here the first item to my christmas wish list:
“Santa, please send me the livecd feature for Metro, make my life easier, let me get rid of that ugly 2 commands stage builder!”

Actually I should write it my self and commit it to drobbins; added to my TODO list as a next hobby.

md5sum livecd: f1e76c227b07d33fb27502d01a556fbe
Kicktoo-0.2-x86.iso 62.87Mb

This is the first release of Kicktoo for x86. Kicktoo uses the Quickstart-0.6 modules with a couple of features added and adjusted for this hobby.
The 0.2 kicktoo branch aims at stabilizing the merge of Quickstart and GenLUKS. The –luks genkernel parameter is the main feature in mind but who can do more can do less so installing stable Gentoo and unstable Funtoo should be as easy as changing the dist, stage_uri, tree_type and kernel_config_uri variables from the profile template.

The Kicktoo livecd does not provide any X interface (and never will). It just bumps you to bash. In a further release, we will add a kicktoo daemon service to provide network installs but this is way to experimental for now. And in a decade we’ll add an ncurse frontend to the configuration profile but that would be time traveling.

Another cool thing is that you can download Kicktoo-0.2.tar.bz2 from any livecd as long as they provide the required programs (in case the above one does not work) and then use it to install whatever profile you want. Just download it, untar it in /tmp, tweak your profile and there you go.
This is quite useful in the case of undetected network devices from the above livecd. Boot from Ubuntu or Knoppix, grab kicktoo and just bootstrap your system.

As for netbook systems which don’t have any cdrom, I strongly recommend UNetbootin. It allows you to easily bootstrap a system (Archlinux CentOS Fedora Mandriva Elive Backtrack Frugalware Slax Ubuntu and many more) onto a USB key.
Then boot your netbook from your freshly installed USB key and download kicktoo for a greater good!

NOTE: I use an Acer Aspire one ZG5 netbook to work chill and develop. Tests are made using VirutalBox-ose. Tests are time consuming given my hardware, so any real hardware tests on different architectures would be really appreciated. Give us some feedback by posting whatever your experience is.

Stages supported

• Gentoo builds (stable).
• Funtoo builds (unstable only) and its git’d portage version.

Features

• partitioning storage
• ease of profile customization
• creation of md raid arrays
• creation of lvm2 volumes
• ability to format partitions as ext2, ext3, ext4, swap, reiserfs, xfs, or jfs
• LUKS support for encrypted material
• specify local filesystems to be mounted during the install
• specify network shares to be mounted during the install
• choose your bootloader
• automatic bootloader configuration (currently grub, palo, and silo)
• choose your logger (or none)
• choose your cron daemon (or none)
• choose your root password (plain-text or pre-encrypted)
• choose your boot password if using LUKS
• specify URI for stage 3 tarball (file, http, https, ftp, or rsync)
• specify method for getting a portage tree (sync, webrsync, or snapshot)
• specify the directory that is used for the chroot
• specify extra packages to be emerged after the base system
• specify extra options passed to genkernel
• specify URI for pre-made kernel config
• choose which kernel sources package to use to build your kernel
• choose your timezone
• choose your hostname
• choose your keymap
• choose which services to add to which runlevels
• choose which services to remove from which runlevels
• specify basic networking configuration
• run custom code using pre-/post-install step hooks in the config file

Screenshot

Using Virtualbox-ose-2.1.4 as a main tool to test my builds, here is the picture of the kicktoo livecd boot (click to enlarge

Supported Architectures

• x86
• x86_64 (amd64) NOT TESTED
• pa-risc (hppa) NOT TESTED
• sparc64 NOT TESTED

Config.txt profile parameters

The following is a list of all the valid configuration options with description and
valid parameters.

==========================
part – Creates a partition

Usage:
part <drive> <minor> <type> [size]

Parameters:
drive – the drive to add this partition (such as hda, sdb, etc.)
minor – the partition number. these should be in order
type  – the partition type used in fdisk (such as 82 or 83) or “extended”
size  – the size of the partition (such as 32MB or 15GB, whole numbers
only), ‘+’ for remaining space, or ‘n%’ for percentage of remaining
(these should only be used after all specific partition sizes are
specified), leave blank for “extended”

================================
mdraid – Creates an md raid array

Usage:
mdraid <array> <arrayopts>

Parameters:
array     – name of the array (such as md0, md1, etc.)
arrayopts – arguments to ‘mdadm’ after ‘–create /dev/mdX’ (such as
‘-l 1 -n 2 /dev/sda2 /dev/sdb2′

=========================================
lvm_volgroup – Creates an LVM volume group

Usage:
lvm_volgroup <name> <devices>

Parameters:
name    – name of the volume group to create
devices – list of block devices to include in the volume group

============================================
luks – Sets and creates /dev/mapper/ encrypted devices

Usage:
luks bootpw <passwd>
luks <device> <mapping> <cipher> <hash>

Parameters:
bootpw    – defines boot password
password  – actual password
mapping   – root, swap
cipher    – aes or serpent or blowfish
hash      – sha1 or sha256

Example:
luks bootpw PASS01
luks /dev/sda2 swap aes sha256
luks /dev/sda3 root aes sha256

========================================
lvm_logvol – Create an LVM logical volume

Usage:
lvm_logvol <volgroup> <size> <name>

Parameters:
volgroup – name of a volume group created with ‘lvm_volgroup’
size     – size of logical volume to pass to ‘lvcreate’
name     – name of logical volume to pass to ‘lvcreate’

============================
format – Formats a partition

Usage:
format <device> <fs>

Parameters:
device – the device to format (such as /dev/hda2 or /dev/sdb4)
fs     – the filesystem to use (such as ext2, ext3, or swap)

=============================
mountfs – Mounts a filesystem

Usage:
mountfs <device> <type> <mountpoint> [mountopts]

Parameters:
device     – the device to mount (such as /dev/hda2 or /dev/sdb4)
type       – filesystem of device (use auto if you’re not sure)
mountpoint – the directory to mount the filesystem
mountopts  – additional options to use when mounting

======================================
netmount – Mounts a network filesystem

Usage:
netmount <export> <type> <mountpoint> [mountopts]

Parameters:
export     – path to the network filesystem (such as 1.2.3.4:/some/export)
type       – network filesystem type (such as nfs, smbfs, cifs, etc.)
mountpoint – the directory to mount the filesystem
mountopts  – additional options to use when mounting

=============================================================
bootloader – Specify the bootloader to use (defaults to grub)

Usage:
bootloader <bootloader>

Parameters:
bootloader – the name of the bootloader to use (such as grub or lilo)

==============================================================
logger – Specify the bootloader to use (defaults to syslog-ng)

Usage:
logger <logger>

Parameters:
logger – the name of the logger to use (such as metalog or syslog-ng)

==============================================================
cron – Specify the cron daemon to use (defaults to vixie-cron)

Usage:
cron <cron>

Parameters:
cron – the name of the cron daemon to use (such as vixie-cron). you can
specify ‘none’ here to skip installing a cron daemon

====================================================================
rootpw – Sets the root password (required if not using rootpw_crypt)

Usage:
rootpw <password>

Parameters:
password – the plain-text password for the root user

====================================================================
rootpw_crypt – Sets the root password (required if not using rootpw)

Usage:
rootpw_crypt <password>

Parameters:
password – the pre-hashed password for the root user

=============================================================
stage_uri – Specifies the URI to the stage tarball (required)

Usage:
stage_uri <uri>

Parameters:
uri – URI to the location of the stage tarball. protocol can be http, https,
ftp, or file

==============================================================
tree_type – Specifies the portage tree type (defaults to sync)

Usage:
tree_type <type> [uri]

Parameters:
type – the method for fetching the portage tree (sync, webrsync, or
snapshot). you can also use ‘none’ to skip this step
uri  – URI to the location of the portage snapshot if you specified
‘snapshot’ for the type

=============================================================================
bootloader_install_device – Specifies the device to install the bootloader to
(defaults to MBR of device /boot is on)

Usage:
bootloader_install_device <device>

Parameters:
device – device to install bootloader to (such as /dev/hda, /dev/hda3, etc.)

=======================================================================
chroot_dir – Specifies the directory to use for the chroot (defaults to
/mnt/gentoo)

Usage:
chroot_dir <dir>

Parameters:
dir – directory to use for the chroot

===================================================
extra_packages – Specifies extra packages to emerge

Usage:
extra_packages <pkg>

Parameters:
pkg – package (or packages, space-separated) to emerge

=============================================================
genkernel_opts – Specifies extra options to pass to genkernel

Usage:
genkernel_opts <opts>

Parameters:
opts – the extra options to pass to genkernel

===============================================================
kernel_config_uri – Specifies the URI to a custom kernel config

Usage:
kernel_config_uri <uri>

Parameters:
uri – URI to the location of the custom kernel config

=================================================================
kernel_sources – Specifies the kernel sources to use (defaults to
gentoo-sources)

Usage:
kernel_sources <source>

Parameters:
source – kernel sources to emerge

====================================================================================
bootloader_kernel_args – Specifies extra commandline arguments to pass to the kernel

Usage:
bootloader_kernel_args <args>

Parameters:
args – extra commandline arguments to pass to the kernel

=================================
timezone – Specifies the timezone

Usage:
timezone <tz>

Parameters:
tz – timezone to use (relative to /usr/share/zoneinfo/)

=================================
hostname – Specifies the hostname

Usage:
hostname <host>

Parameters:
host – hostname of the system

============================================================
rcadd – Adds the specified service to the specified runlevel

Usage:
rcadd <service> <runlevel>

Parameters:
service  – name of service to add
runlevel – runlevel to add service to

=================================================================
rcdel – Removes the specified service from the specified runlevel

Usage:
rcdel <service> <runlevel>

Parameters:
service  – name of service to remove
runlevel – runlevel to remove service from (usually not required)

========================
net – Sets up networking

Usage:
net <device> <ip/dhcp> [gateway]

Parameters:
device  – network device (such as eth0)
ip/dhcp – static IP address or “dhcp”
gateway – gateway IP if using a static IP

============================
skip – Skips an install step

Usage:
skip <install step>

Parameters:
install step – name of step to skip

====================================
server – Specify a kicktoo daemon

Usage:
server <host>[:<port>]

Parameters:
host – hostname or IP address of the kicktoo daemon
port – port server is listening on (defaults to 8899)

===============================================================================
use_linux32 – Enable the use of linux32 for doing 32ul installs on 64-bit boxes

Usage:
use_linux32

The main goal of Kicktoo is to drive everything through profiles; a
text file that gets source’d by kicktoo and tells it what to do.

So here what a simple luks Funtoo profile would look like:

===
dist funtoo

post_install_portage_tree() {
    cat > ${chroot_dir}/etc/make.conf <<EOF
ACCEPT_KEYWORDS=”~x86″
CHOST=”i686-pc-linux-gnu”
CFLAGS=”-O2 -march=i686 -pipe”
CXXFLAGS=”\${CFLAGS}”
USE=”-X -gtk -gnome -kde -qt”
EOF
}
===

First,
you define what distro you want: Gentoo or Funtoo. Then you define your
partition scheme and the space you allocate to each device.

Be aware that the stage_uri
paramter points to a stable stage3 Funtoo tarball. Changing this to
anything else might not work in the case of a Gentoo install.

Be aware that the kernel_config_uri
is provided as is by myself. There are 2 versions of this fille;
kconfig.stable and kconfig.unstable. Both should point to their
respective kernel sources state in Gentoo.
As of speaking, kconfig.stable points to a 2.6.27 kernel config and kconfig.unstable to 2.6.28.
Keep
in mind that their content aims at providing a large range of modules
(and btw any advise on more extended version of those config files are
more than welcome).
You are encouraged to use your own customized kernel config.

Check out the genkernel_opts option and notice the –luks parameter. That is required in order to create a proper initramfs.

Check out the bootloader_kernel_args option too. It should match the root device defined previously. 

To measure the extend of what kicktoo can do, you are strongly advised to read the config.txt file. It contains descriptions of all options and parameters.

So here what a simple Funtoo profile would look like:

===
dist funtoo

post_install_portage_tree() {
    cat > ${chroot_dir}/etc/make.conf <<EOF
ACCEPT_KEYWORDS=”~x86″
CHOST=”i686-pc-linux-gnu”
CFLAGS=”-O2 -march=i686 -pipe”
CXXFLAGS=”\${CFLAGS}”
USE=”-X -gtk -gnome -kde -qt”
EOF
}
===

First,
you define what distro you want: Gentoo or Funtoo. Then you define your
partition scheme and the space you allocate to each device.
Be aware that the stage_uri
paramter points to a stable stage3 Funtoo tarball. Changing this to
anything else might not work in the case of a Funtoo install.
Be aware that the kernel_config_uri
is provided as is by myself. There are 2 versions of this fille;
kconfig.stable and kconfig.unstable. Both should point to their
respective kernel sources state in Funtoo.
As of speaking, kconfig.stable points to a 2.6.27 kernel config and kconfig.unstable to 2.6.28.
Keep
in mind that their content aims at providing a large range of modules
(and btw any advise on more extended version of those config files are
more than welcome).
You are encouraged to use your own customized kernel config.

To measure the extend of what kicktoo can do, you are strongly advised to read the config.txt file. It contains descriptions of all options and parameters.

So here what a simple Gentoo profile would look like:

===
dist gentoo

post_install_portage_tree() {
    cat > ${chroot_dir}/etc/make.conf <<EOF
CHOST=”i686-pc-linux-gnu”
CFLAGS=”-O2 -march=i686 -pipe”
CXXFLAGS=”\${CFLAGS}”
USE=”-X -gtk -gnome -kde -qt”
EOF
}
===

First, you define what distro you want: Gentoo or Funtoo. Then you define your partition scheme and the space you allocate to each device.
Be aware that the stage_uri paramter points to a stable stage3 Gentoo tarball. Changing this to anything else might not work in the case of a Gentoo install.
Be aware that the kernel_config_uri is provided as is by myself. There are 2 versions of this file; kconfig.stable and kconfig.unstable. Both should point to their respective kernel sources state in Gentoo.
As of speaking, kconfig.stable points to a 2.6.27 kernel config and kconfig.unstable to 2.6.28.
Keep in mind that their content aims at providing a large range of modules (and btw any advise on more extended version of those config files are more than welcome).
You are encouraged to use your own customized kernel config.

To measure the extend of what kicktoo can do, you are strongly advised to read the config.txt file. It contains descriptions of all options and parameters.

What’s changed?

- Configuration of kernel password automated.
- From now on, the installation script runs without any user interaction except for the ncurse configuration of course.

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive.

SPECIFICATION

GenLUKS-0.1.15-x86 supports the following:

HD connectors:                 ATA, SATA
Ciphers:                           symmetric (AES, Blowfish, Serpent)
Hash:                               sha1, sha256
Keyboard:                         US, BE, FR, DE, ES, IT, RU, UK
FileSystem support:           ext2(boot partition) and ext3/ext4(root)
Gentoo profile:                  2008.0
Gentoo stage:                   stage3-x86-2009.03.01

Portage version:                2.1.6.7
Portage snapshot:             20090304

KERNEL INITRAMFS

gentoo-sources-2.6.28-r2
busybox-1.2.1

TODO

- improve default kernel config support.

It’s easy to use and stragiht forward. You provide it with your root device and it does the rest by asking your password, unlocking your box and chroot’ing within, ready to backup!

Good news is that I now work using VirtualBox-2.1.2. I emulate an x86 architecture to test installations of GenLUKS.
I was trying to make VirtualBox fully working for the past few months but without any success. Indeed there was no way I could fully boot the new encrypted device.
So I was using VMWare-workstation  for the past 2 3 years now.

A couple of days ago, VirtualBox-2.1.4 went just out. I’m currently running it and it works like a charm. GenLUKS-0.1.14 installs as expected.

So here is the tip of the day: You use Windows, you’d like to try GenLUKS (or Gentoo in general) but you don’t wanna change any of your partitions?

Then VirtualBox is meant just for you ;o)

What’s changed?

- Ext3/Ext4 filesystem menu: Ext4 set by default.
- Manual interactive password settings removed.
- Root and user passwords are not stored in clear but lively encrypted. The shadow style $1$salt$hash is only saved during configuration.
- Added $verbose option:
    – ‘genluks-install –graphic –verbose‘ will give you more output.
    – ‘dbg=”set -x” genluks-install –graphic –verbose‘ will give you insane verbosity.

Howto install Genluks

—–
EXTENDED BODY:

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive.

SPECIFICATION

HD connectors:                 ATA, SATA
Ciphers:                           symmetric (AES, Blowfish, Serpent)
Hash:                               sha1, sha256
Keyboard:                         US, BE, FR, DE, ES, IT, RU, UK
FileSystem support:           ext2(boot partition) and ext3/ext4(root)
Gentoo profile:                  2008.0
Gentoo stage:                   stage3-x86-2009.02.08

Portage version:                2.1.6.4
Portage snapshot:             20090214

KERNEL INITRAMFS

gentoo-sources-2.6.28-r1
busybox-1.2.1

TODO

- improve default kernel config support.

HDshredder is a utility that helps you securely wipe once for all your hard drives whether they are ATA, SATA or USB.

- supports up to 50 rounds for paranoïd users.
- supports hard drive I/O speed detection; provides an estimated time frame.

- updated livecd kernel (2.6.27)
- faster shredding using SATA drivers.

Have fun wiping!

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive or any USB storage device.

SPECIFICATION

HD connectors:                 ATA, SATA, USB
Keyboard:                         US, BE, FR, DE, ES, IT, UK

TODO

- improve something: not sure what yet.

What’s changed?

- Ext4 support by default for /dev/mapper/root (‘genluks-install’ updated).
  – default mount options are: dir_index,filetype,sparse_super,extents,huge_file
- be-latin1 keyboard mapping is now fixed and usable.
- openpty failed:’out of pty devices’ warning during install fixed. /dev is now entirely bound during emerges.
- de, es, it, ru, uk keyboard selections during ‘genluks-install’ fixed and usable.
- new option ‘genluks-config –fix’ to detect a sane genluks environment (currently checks for appropriate symlinks).

Howto install Genluks

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive.

SPECIFICATION

HD connectors:                 ATA, SATA
Ciphers:                           symmetric (AES, Blowfish, Serpent)
Hash:                               sha1, sha256
Keyboard:                         US, BE, FR, DE, ES, IT, RU, UK
FileSystem support:           ext2(boot partition) and ext4(root)
Gentoo profile:                  2008.0
Gentoo stage:                   stage3-x86-2009.01.21

Portage version:                2.1.6.4
Portage snapshot:             20090125

KERNEL INITRAMFS

gentoo-sources-2.6.28-r1
busybox-1.2.1

TODO

- improve default kernel config support.

2.6.28 released the first stable Ext4 implementation.

A quick note to point out that support for Ext4 file system format will soon hit the 0.1.13 release.
This should be a major step forward with a whole lot of new features like the (in)famous “defrag”.

Dui!

This is typically no big deal because it is a physical attack. Indeed the offender is required to have a direct access to the hardware.

However, it seems some folks have investigated the matter and are currently working on a workaround: store the decryption key in the CPU memory rather than in the RAM. Quite smart indeed. The typical RAM is called DRAM and the one from the CPU SDRAM.

The question is now: what if we can cold boot attack the CPU SDRAM?

I will check this out in the coming months and see if we could use any proof-of-concept for GenLUKS.

GenLUKS-0.1.12-x86.iso 289Mb

What’s changed?

- kernel gentoo-sources-2.6.28 basically updated from previous
configuration.
- portage snapshot 20090101, gentoo stage3-x86-2008.12.28 inside.

- services added to rc runlevel: gpm sshd syslog-ng

Howto install Genluks

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or

# modify it under the terms of the GNU General Public License

# as published by the Free Software Foundation; either version 2

# of the License, or (at your option) any later version.

#

# This program is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

# GNU General Public License for more details.

#

# You should have received a copy of the GNU General Public License

# along with this program; if not, write to the Free Software

# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive.

SPECIFICATION

GenLUKS-0.1.12-x86 supports the following:

HD connectors:                 ATA, SATA

Ciphers:                           symmetric (AES, Blowfish, Serpent)

Hash:                               sha1, sha256

Keyboard:                         US, FR, DE, ES, IT, RU, UK

FileSystem support:          ext2(boot partition) and ext3(root)

Gentoo profile:                  2008.0

Portage version:                2.1.6.4
Portage snapshot:             20090101

KERNEL INITRAMFS

gentoo-sources-2.6.28

busybox-1.2.1

TODO

- improve default kernel config support.

- improve keyboard mappings.

Use the liveCD to install a Gentoo LUKSyfied system encrypted from the bottom up.

Boot from GenLUKS.

*********************************************************************

Welcome to the GenLUKS installer, an encrypted Gentoo flavor^^

Use the `genluks-install’ command to install or rescue the system.

Please read the specs from http://www.openchill.org/genluks

before executing.

genluks ~ #

genluks ~ # genluks-install

Usage: /usr/sbin/genluks-install [option] [parameter]

options:

-g, –graphic    Graphical installation

-r, –rescue      Rescue me

-v, –version     Version

-h, –help          This

Extra verbose:

dbg=”set -x” /usr/sbin/genluks-install -h
genluks ~ # genluks-install –graphic

Configure and that’s it!

##############
## WARNING ##
##############

To
ensure maximum stability and due to the fact that the installer lets
you customize your CHOST (i585, i686, pentium-m or i486 stays by
default) you are _strongly_ advised to run the following after your
first reboot in the same order.

genluks ~ # emerge binutils gcc glibc
genluks ~ # emerge system -e && emerge world -e

This command will rebuild the system packages (glibc gcc etc…) and when
done with success it rebuilds all packages using your freshly built C
compiler.
Failure to at least rebuild gcc will break some packages like busybox or nvidia-drivers.

This happens because our seed contains a default i486 gcc binary and you
might have chosen i586, i686 or pentium-m during installation as CHOST.
Rebuilding the system using your chosen CHOST will greatly improve its stability.

*You are not required to do this _if_ you have let the default i486 CHOST.*

What’s changed?

- kernel gentoo-sources-2.6.28 basically updated from previous
configuration.
- portage snapshot 20090101, gentoo stage3-x86-2008.12.28 inside.
- introduction of ‘libgenluks’: a tiny shell library serving some routines for ‘genluks-config’.

- swap mount on boot fixed: /etc/init.d/localmount patched using libgenluks. The swap partition should mount encrypted and secured on boot.

Howto install Genluks

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive.

SPECIFICATION

HD connectors:                 ATA, SATA
Ciphers:                           symmetric (AES, Blowfish, Serpent)
Hash:                               sha1, sha256
Keyboard:                         US, FR, DE, ES, IT, RU, UK
FileSystem support:          ext2(boot partition) and ext3(root)
Gentoo profile:                  2008.0
Portage version:                2.1.6.4
Portage snapshot:             20090101

KERNEL INITRAMFS

gentoo-sources-2.6.28
busybox-1.2.1

TODO

- improve default kernel config support.
- improve keyboard mappings.

What’s changed?

- kernel gentoo-sources-2.6.27-r7 basically updated from previous
configuration.
- portage snapshot 20081221, gentoo stage3-x86-2008.12.14 inside.

- ‘genluks-config’ has few major bugs fixed. The ‘–rebuild default’ command should finally work as expected.

Howto install Genluks

—–
EXTENDED BODY:

LICENSE

GenLUKS is licensed under the GNU/GPL v3

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

http://www.gnu.org/licenses/licenses.html#GPL

HARDWARE REQUIREMENT

PC(desktop or laptop) and its ATA/SATA harddrive.

SPECIFICATION

HD connectors:                 ATA, SATA
Ciphers:                           symmetric (AES, Blowfish, Serpent)
Hash:                               sha1, sha256
Keyboard:                         US, FR, DE, ES, IT, RU, UK
FileSystem support:          ext2(boot partition) and ext3(root)
Gentoo profile:                  2008.0
Portage version:                2.1.4.5
Portage snapshot:             20081221

KERNEL INITRAMFS

gentoo-sources-2.6.27-r7
busybox-1.2.1

TODO

- improve default kernel config support
- improve flexibility of genluks-config

genluks ~ # genluks-config –list
Available Busybox source versions:
 1.2.1  selected

Currently running kernel version: 2.6.27-gentoo-r7
genluks ~ # emerge gentoo-sources -pv

Total: 1 package (1 in new slot), Size of downloads: 50,112 kB
genluks ~ # emerge gentoo-sources
…
…
genluks ~ # cp -r /usr/src/linux-2.6.28-gentoo /genluks/work
genluks ~ # genluks-config –list
Available Busybox source versions:
 1.2.1  selected

Currently running kernel version: 2.6.27-gentoo-r7
genluks ~ # genluks-config –change kernel 2.6.28-gentoo
 * Backing up /etc/genluks/genluks.conf …                                     
 * Updating /etc/genluks/genluks.conf kernel …                              
Kernel symlink mismatch!
lrwxrwxrwx 1 root root 33 Jan  8 23:33 /usr/src/linux -> /genluks/work/linux-2.6.27-gentoo-r7
Trying to fix it …
lrwxrwxrwx 1 root root 36 Jan  9 19:15 /usr/src/linux -> /genluks/work/linux-2.6.28-gentoo
Fixed!
genluks ~ # genluks-config –list
Available Busybox source versions:
 1.2.1  selected

Currently running kernel version: 2.6.27-gentoo-r7
genluks ~ #

Let’s copy the older config file.

genluks ~ # cp /genluks/work/linux-2.6.27-gentoo-r7/.config /usr/src/linux

Let’s update the config file to the new kernel, compile the objects.

genluks ~ # genluks-config –kernel oldconfig && genluks-config –kernel compile
…
…
genluks ~ #

Let’s rebuild the initramfs as well. You should
always ensure that you run ‘–busybox initramfs’ when upgrading to copy
your new initramfs.

genluks ~ # genluks-config –busybox clean && genluks-config –busybox compile && genluks-config –busybox initramfs
…
…
genluks ~ #

genluks ~ # genluks-config –kernel compile && genluks-config –kernel install
…
…
genluks ~ #
genluks ~ #  reboot

You should gracefully boot on your fresh new kernel.
If you face a ‘Kernel Panic’ at your next boot, then use the GenLUKS livecd and refer to HOWTO-rescue page.

You will surely need to tweak the GNU/Linux kernel to fit your hardware. The ‘genluks-config-0.1.10.1.tar.bz2‘ package has just been written for that purpose.

‘genluks-config’ easily allows you to access the busybox and kernel menu configs and rebuilds the initramfs automatically.
Do
not run on other systems than GenLUKS (not even Gentoo).

Manual Rebuild

genluks ~ # genluks-config
Usage: /usr/sbin/genluks-config [option] <parameter>

options:
-a, –approve        Approve config environment
-l, –list                List available kernel and busybox sources
-c, –change        Change settings
-b, –busybox       Busybox menu/compile/initramfs
-k, –kernel          Kernel  menu/compile/install
-r, –rebuild          Rebuild busybox and kernel the default way
-u, –update         Update genluks-config
-v, –version         Version
-h, –help             This

Extra verbose:
dbg=”set -x” /usr/sbin/genluks-config -h
genluks ~ #

It is unlikely you have to tweak the busybox but in case, issue:

genluks ~ # genluks-config –busybox menuconfig

Save it by default or add features. (do not remove the already existing!)

genluks ~ # genluks-config –busybox compile && genluks-config –busybox initramfs

In case you need to add some specific modules to the kernel build, you should use the following:

genluks ~ # genluks-config –kernel menuconfig

Then save by default (and/or elsewhere for backup) and run:

genluks ~ # genluks-config –kernel compile && genluks-config –kernel install

Then you can reboot.

Default Rebuild

The ‘–rebuild default’ function is there to help you roll
back to the default busybox and kernel configurations. It automatically
falls back to default config files and rebuilds everything from
scratch.

Simply issue:

genluks ~ # genluks-config –rebuild default

and then reboot.