Funtoo Linux - New pages [en]

MATE Desktop

2013-05-04T04:10:30Z

Oleg:

As many of you have read recently, we have brought MATE into our main tree. Which can be added via profile mix-in. It is simple to do so:
<console>
# ##i##eselect profile list
##i##Currently available arch profiles:
[1] funtoo/1.0/linux-gnu/arch/x86-64bit *
[2] funtoo/1.0/linux-gnu/arch/x86-64bit/pure64
##i##Currently available build profiles:
[3] funtoo/1.0/linux-gnu/build/stable
[4] funtoo/1.0/linux-gnu/build/current *
[5] funtoo/1.0/linux-gnu/build/experimental
##i##Currently available flavor profiles:
[6] funtoo/1.0/linux-gnu/flavor/minimal
[7] funtoo/1.0/linux-gnu/flavor/core *
[8] funtoo/1.0/linux-gnu/flavor/desktop
[9] funtoo/1.0/linux-gnu/flavor/workstation
##i##Currently available mix-ins profiles:
[10] funtoo/1.0/linux-gnu/mix-ins/audio
[11] funtoo/1.0/linux-gnu/mix-ins/console-extras
[12] funtoo/1.0/linux-gnu/mix-ins/dvd
[13] funtoo/1.0/linux-gnu/mix-ins/gnome
[14] funtoo/1.0/linux-gnu/mix-ins/kde
[15] funtoo/1.0/linux-gnu/mix-ins/mate
[16] funtoo/1.0/linux-gnu/mix-ins/media
[17] funtoo/1.0/linux-gnu/mix-ins/print
[18] funtoo/1.0/linux-gnu/mix-ins/python3-only
[19] funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
[20] funtoo/1.0/linux-gnu/mix-ins/server-db
[21] funtoo/1.0/linux-gnu/mix-ins/server-mail
[22] funtoo/1.0/linux-gnu/mix-ins/server-web
[23] funtoo/1.0/linux-gnu/mix-ins/X
[24] funtoo/1.0/linux-gnu/mix-ins/xfce
[25] funtoo/1.0/linux-gnu/mix-ins/vmware-guest
# ##i##eselect profile add funtoo/1.0/linux-gnu/mix-ins/mate
# ##i##emerge -uDNav @world
</console>
There is a use.mask on GTK3 for libcanberra which is required for a clean merge of MATE. A quick work around would be adding this to <tt>/etc/portage/</tt>:
<console>
# ##i##install -d /etc/portage/profile/
# ##i##echo "media-libs/libcanberra -gtk3" >> /etc/portage/profile/package.use.mask
# ##i##echo "media-libs/libcanberra gtk3" >> /etc/portage/package.use
# ##i##emerge -av mate
</console>
You're good to go!

Developer Queries

2013-04-08T21:35:46Z

Drobbins:

This page documents useful queries to perform to look at recent developer activity:

== git Queries ==

=== Committers from Date ===

<console>
xdev2 funtoo-overlay # ##i##git log --stat --after '04-01-2013' | grep Author: | sort -u
Author: Alexander Reitzel <shiin@funtoo.org>
Author: Daniel Robbins <drobbins@funtoo.org>
Author: Jean-Francis Roy <jeanfrancisroy@gmail.com>
Author: Oleg Vinichenko <oleg@funtoo.org>
</console>

== JIRA PostgreSQL Queries ==

=== Top Commenters ===

<console>
jiradb=# ##i##SELECT author, count(author) as comments FROM jiraaction j WHERE UPDATED > now() - interval '30 days' group by author ORDER BY comments DESC limit 10;
author | comments -------------+----------
oleg | 55
drobbins | 29
golodhrim | 14
arithmos | 12
jeanfrancis | 11
fearedbliss | 10
overkill | 8
janzhou | 7
anak1n | 6
sputnik | 5
(10 rows)
</console>

KnuthMuller386

2013-04-03T05:55:11Z

5.9.184.11: Created page with "These days, the very first priority of just about any educationalist, educator or even lecturer is always to check for Electronic digital Projectors which often carry impressi..."

These days, the very first priority of just about any educationalist, educator or even lecturer is always to check for Electronic digital Projectors which often carry impressive image lucidity and tremendous portability. Definitely, they look out there for technically advance projectors which could catch pupil's consideration using latest technology.

Really, nothing at all can record the interest regarding pupils like a 3D projector. It is just a extraordinary resource which can jump the pupils in the world of fascination grabbing 3D program. Want to know the best part is that using 3D projectors; students often remember many get more info. Probably, Lightweight Projectors assist quite a lot throughout remembering instructions rich in visuals, graphics, animation, sound and wording for a lifetime. 3D Projectors offer extra fine image quality. Their particular remarkably stunning image good quality are able to turn regular lessons in to 3D lessons so that you can bring new magic in their classroom.

Just imagine; the level of euphoria; pupils feels; when such helpful gadget will probably be mounted into their classes. By making use of 3D ready portable projectors, the actual most complex and hard to know training may be produced simple and exciting to find out. 3D projectors assist a great deal throughout eradicating communication gap among pupils along with lecturers. Additionally, they encourage classroom participation and also improve understanding retention good great lengthen. Scholars can indulge themselves within real-time online problem solving actions and enhance their essential thinking abilities.

The largest advantage of utilizing 3D Projectors is can also add the 'wow' factor into the current curriculum as well. 3D projectors are unique but appealing into their strategy. Lecturers can use 3D projectors to carry out electronic dissections involving frog within the technology class or explore online topography to create location lessons alive and make them a lot more fascinating for your pupils. From the comfort of the particular live substantive the web to PowerPoint sales pitches, coming from music videos to be able to historical movies, coming from science research laboratory experiments to be able to mathematics courses, every thing is possible together with 3D projectors.

Mobility associated with 3D projectors may be the most significant edge. Colleges and study centers which aren't afford person projectors to be put in in each and every class room can favor 3D set lightweight projectors. Such projectors are super easy to carry from class to another classroom and that way too on their.

Viole9728

2013-04-02T16:49:09Z

188.167.80.200: Created page with "Giant pandas are carnivores, but 99% of their food comes from more than 20 kinds of bamboos that grow in the high mountains and the deep valleys of China. With the changes of ..."

Giant pandas are carnivores, but 99% of their food comes from more than 20 kinds of bamboos that grow in the high mountains and the deep valleys of China. With the changes of the seasons, the kinds of the bamboos and the diet of the giant pandas are different. They like bamboo shoots best. From spring to summer, they like to live on the bamboo shoots of the Qiong bamboo (Q.tunidinoda Hsueh et Yi), some bamboos of the madake bamboo category, the wood bamboos in Bashan, the walking stick bamboos, the Chaohua arrow bamboos (Fargesia scabrida Yi), the Huaxi arrow bamboos and the big arrow bamboos. The bamboo shoots are the new trunks of the bamboos that have no branches or leaves and grow from the underground bamboo roots. The bamboo is very small and tender, and the water content is abundant. The nutritional components include: the raw fat is 1.27%, the raw fiber is 33.62%, the crude protein is 10.32%, and the general quantity of sugar is 26.15%. The bamboo shoots are small and tender and they are succulent which taste good and therefore are easy to be digested and absorbed and they are dainty dishes for giant pandas.

NetworkManager

2013-03-16T03:38:00Z

80.252.155.28: Created page with "If you're experiencing troubles, loosing connection after a 45-second timeout with NetworkManager and dhcpcd, consider moving to dhclient (net-misc/dhcp) - NetworkManager is d..."

If you're experiencing troubles, loosing connection after a 45-second timeout with NetworkManager and dhcpcd, consider moving to dhclient (net-misc/dhcp) - NetworkManager is designed for use with dhclient and have less (~0) problems with it.

CCACHE

2013-03-10T03:45:47Z

142.255.68.198: /* Using CCACHE to compile your kernel faster */

CCACHE is an application that caches compilation results and reuses it in future compilations in order to achieve faster compile times. This short tutorial will show you how to use it on your system.

{{fancywarning|'''CCACHE can cause build failures'''. If it does, please try to compile the application without CCACHE enabled. Bug reports reported with CCACHE enabled will be closed.}}

== Installing CCACHE ==

<console>
# ##i##emerge ccache
</console>

Once it finishes emerging, we will enable it in portage. This is very easy. Just open up /etc/portage/make.conf with your favorite text editor and add the following:

<console>
# ##i##FEATURES="ccache"
</console>

That's it. If you want to check how much the cache is taking up on your disk and other info, you can run the following command:

<console>
# ##i##CCACHE_DIR="/var/tmp/ccache" ccache -s
</console>

You must pass the CCACHE_DIR option since ccache normally defaults to the user's home directory, and portage uses /var/tmp/ccache.

== Tweaking CCACHE ==

=== Disabling the CACHE limit ===

If you want to let the cache have the flexibility to grow to whatever size it needs to (unlimited size cache), just do the following:

<console>
# ##i##CCACHE_DIR="/var/tmp/ccache" ccache -M 0
</console>

This will let the cache grow to whatever size it needs to grow over time.

== Using CCACHE to compile your kernel faster ==

In order to do this you need to change a few variables, you probably only want to change these variables temporarily, but you could change them permanently if you want to. Since we just want to do this temporarily for this example, make a new file called "build.sh" and put the following inside of it:

<console>
#!/bin/bash

export CCACHE_DIR="/var/tmp/ccache"
export PATH="/usr/lib/ccache/bin:${PATH}"

cd /usr/src/linux
time make bzImage modules
</console>

Give the file execute permission:

<console>
# ##i##chmod u+x build.sh
</console>

This will temporarily export the variables neccessary, then go into the /usr/src/linux folder (whatever you declared with 'eselect kernel') and then compile the kernel.[[Category:HOWTO]]

Creating System Rescue CD ZFS Modules

2013-03-10T00:19:16Z

Fearedbliss: /* Compiling a compatible kernel */

This HOWTO will show you how to create your own zfs srm or download the prebuilt zfs srm module from my website.

== Compiling a compatible kernel ==

The first thing you need to do is decide for which version of System Rescue CD you will be building for. Each System Rescue CD version has a different set of kernels. Specifically each version has a Stable kernel and an Alternate Kernel. The stable kernels get minor version increments every release (Sometimes major ones but usually doesn't happen too quickly), the Alternate kernels tend to move up much faster. For example System Rescue CD had the following stable/alternate kernels:

{| class="wikitable"
|-
! Version !! Stable !! Alternate
|-
| 3.5.0 || 3.4.37 || 3.8.4
|-
| 3.4.2 || 3.4.35 || 3.7.10
|-
| 3.4.1 || 3.4.32 || 3.7.9
|-
| 3.4.0 || 3.4.30 || 3.7.8
|-
| 3.3.0 || 3.4.27 || 3.7.4
|}

Once you decide which version you want to use, you can go to http://kernel.sysresccd.org/ and pick the version you want. After you do this, download all the stuff in that directory and put them in their own folder (a work directory). The files that are named std-sources are the patches for the regular stable kernel, the patches named alt-sources are the patches for the alternate kernel. Once you have the patches, go to kernel.org and also download the initial release of the kernel sources you want. For example, if you want to build an srm for 3.4.2 which uses the 3.4.35 kernel, just download the 3.4 (3.4.0) kernel. You just need to download the initial release because one of the patches you downloaded earlier is the patch to update the 3.4.0 to 3.4.35.

Once you download the kernel you want, let's extract and patch it.

<console>
# ##i##tar xf linux-3.4.tar.bz2
# ##i##mv linux-3.4 linux-3.4.35-std342-amd64
# ##i##bzcat std-sources-3.4-01-stable-3.4.35.patch.bz2 | patch -p1 -d linux-3.4.35-std342-amd64
# ##i##bzcat std-sources-3.4-02-fc16.patch.bz2 | patch -p1 -d linux-3.4.35-std342-amd64
# ##i##bzcat std-sources-3.4-03-aufs.patch.bz2 | patch -p1 -d linux-3.4.35-std342-amd64
</console>

Once that is complete, you will need to get the kernel sources specifically for the kernel and architecture you want. The easiest way I found to do this was to download the System Rescue CD you want, and then boot it inside a VM. Once you are inside the VM, go to the /root directory, and it will be a file named kernel-<version>.conf. Copy this file over SSH and put it in a safe location. Also copy it over into the linux kernel directory and rename it to .config.

Once you copy the kernel config over, do a make menuconfig to begin. You will only need to change two settings inside the config, add the proper kernel name, and remove the old initramfs source files directory. This directory doesn't exist locally. This is a remnant of upstream's build process.

Follow the below tree structure, and make it equal to what is below:

<console>
General Setup ->
(-std342-amd64) Local version - append to kernel release

[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support () Initramfs source file(s)
</console>

The Local version above will end up making the kernel modules directory be 3.4.35-std342-amd64. The reason the kernel modules directory has to be equal to this is because our directory will be merged into the System Rescue CD later on, so the names need to be exactly the same so that the System Rescue CD system can find our kernel modules.

Now save and exit, and continue to build your kernel.

<console>
# ##i##make bzImage modules
# ##i##make modules_install
</console>

{{fancynote|If you have multiple cores, do a make -j<# of processors+1> to build faster. Example: '''make -j9''' for an 8 core machine.}}

Once the kernel is installed, now you need to make the SRM.

== Creating the SRM ==

Now it's time to gather the files and pack them in order to be an SRM. An SRM is nothing more than directory that has been compressed with squashfs. Thankfully I've (FearedBliss) written a script that will build it for you.

You will need to install sys-fs/squashfs-tools and have squashfs support compiled in your kernel.

These are the required settings in the kernel to work with squashfs stuff.

<console>
File Systems ->
Miscellaneous Filesystems ->
<*> SquashFS 4.0 - Squashed file system support
[*] Squashfs XATTR support
[*] Include support for ZLIB compressed file systems
[*] Include support for LZO compressed file systems
[*] Include support for XZ compressed file systems
[ ] Use 4K device block size?
[ ] Additional option for memory-constrained systems
</console>

Once all that is settled, clone my Bliss Initramfs Creator:

<console>
# ##i##git clone git://github.com/fearedbliss/Bliss-Initramfs-Creator.git
</console>

You should have the following directory layout inside the "Bliss-Initramfs-Creator" folder:

<console>
octopus initrd # ls -l
total 61
-rw-r--r-- 1 root root 4603 Mar 4 00:49 CHANGES
-rw-r--r-- 1 root root 176 Dec 28 12:46 CREDITS
-rw-r--r-- 1 root root 16726 Dec 28 12:46 LICENSE
-rw-r--r-- 1 root root 1842 Mar 4 00:49 README
-rw-r--r-- 1 root root 2367 Feb 3 19:07 USAGE
-rwxr-xr-x 1 root root 1794 Mar 4 00:49 createInit
drwxr-xr-x 3 root root 5 Mar 4 00:49 files
drwxr-xr-x 3 root root 6 Mar 4 00:49 hooks
drwxr-xr-x 2 root root 5 Mar 4 00:49 resources
</console>

Then run it and follow the instructions for the kernel you want to make the srm for (In this case it's 3.4.35-std342-amd64):

<console>
-----------------------------------
| Bliss Initramfs Creator - v1.6.7
| Author: Jonathan Vasquez <jvasquez1011@gmail.com>
| Distributed under the MPLv2
-----------------------------------
>>> Which initramfs would you like to generate:
>> 1. ZFS
>> 2. Encrypted ZFS (LUKS + ZFS)
>> 3. More Options
>> 4. Exit Program

>>> Current choice [1]: ##i##3

>>> More Options:

>> 1. ZFS - System Rescue Module
>> 2. Back
>> 3. Exit Program

>>> Current choice [1]: ##i##↵

>>> Creating a ZFS System Rescue Module!
>>> Do you want to use the current kernel: 3.8.1-ALL? [Y/n]: ##i##n
>>> Please enter the kernel name: ##i##3.4.32-std341-amd64

>>> Detected 64 bit platform
>>> Checking to see if modules directory exists for 3.4.32-std341-amd64...
>>> Creating ZFS System Rescue Module for 3.4.32-std341-amd64...
>>> Creating directory structure for initramfs...
>>> Checking preliminary binaries...
>>> Checking binaries...
>>> Using ZFS
>>> Checking modules...
>>> Copying binaries...
>>> Copying modules...
>>> Copying documentation...
>>> Copying udev rules...
>>> Compressing kernel modules...
>>> Getting dependencies...
>>> Copying dependencies...
>>> Configuring files...
>>> Creating and Packing SRM...
>>> Complete :)
</console>

Now you should have two new files:

<console>
-rw-r--r-- 1 root root 78 Mar 9 22:04 zfs-3.4.32-std341-amd64.md5
-rw-r--r-- 1 root root 2584576 Mar 9 22:04 zfs-3.4.32-std341-amd64.srm
</console>

Now all you need to do is put those two files in the root of your USB directory.

== Using the prebuilt srm ==

=== Download the SRM ===

We will use version 3.3.0 as an example. For version 3.3.0, you will be downloading the 3.4.27 srm.

[http://ftp.osuosl.org/pub/funtoo/distfiles/sysrescuecd/ Click to view and download the list of System Rescue CD versions and available modules.]

Extract the file you just downloaded by doing:

Create an empty directory, download the file, then extract it:
<console>
# ##i##mkdir temp && cd temp
# ##i##wget http://ftp.osuosl.org/pub/funtoo/distfiles/sysrescuecd/zfs-3.4.27-std330-amd64.tar.bz2
# ##i##tar xvf zfs-3.4.27-std330-amd64.tar.bz2
</console>

Extracting it should give you a directory layout that looks like this:
<console>
# ##i##ls -lh
total 2.5M
drwxr-xr-x 2 jon jon 2 Jan 12 20:41 iso
-rwxr--r-- 1 jon jon 1.5K Jan 12 20:31 make_iso.sh
drwxr-xr-x 2 jon jon 4 Jan 12 19:44 srm
-rwxr--r-- 1 jon jon 1.3K Jan 12 20:33 usb_inst.sh
-rwxr--r-- 1 jon jon 294 Jan 12 20:05 vars.sh
-rw-r--r-- 1 root root 2.4M Jan 25 21:38 zfs-3.4.27-std330-amd64.tar.bz2
</console>

The layout is as follows:
* iso - directory to place your system rescue cd iso in
* make_iso.sh - A script to automatically recreate the system rescue cd iso with the zfs stuff included
* srm - directory that has the srms
* usb_inst.sh - Creates a new flash drive for you with system rescue cd and puts the srms in it
* vars.sh - Variables (You don't need to worry about this).

=== Installing the SRM ===
There are a few ways to do this, you can either use one of the scripts, or you can do it manually.

==== Generating a new iso ====
If you just want to remake a new iso so that you can burn onto a cd or use in a virtual machine, just copy your iso over to the iso directory, and run the iso script. The new iso will be located in the iso directory as well with a -zfs ending.

If you don't have the iso generating tools installed, the script will stop and tell you what to install.

==== Creating a fresh usb ====
If you want to have zfs on a usb with system rescue cd, then put the iso in your iso dir, and then run the usb script. It will ask you what usb you want to format (This will delete everything), and then install system rescue cd onto it. Once that is done it will copy the zfs stuff over.

==== Manual installation onto a usb ====
Assuming that your installing to a flash drive and that the flash drive is mounted in /mnt

1. Mount your usb drive

<console>
# ##i##mount /dev/sdX# /mnt/usbstick
</console>

'''Where X# is the letter and number of your device. Immediately after you plug your usb in, type `dmesg | tail` in the console and you should see it.'''

2. Copy the zfs .srm and .md5 to /mnt/usbstick

<console>
# ##i##cp zfs-3.4.27-std330-amd64.srm zfs-3.4.27-std330-amd64.md5 /mnt/usbstick
</console>

{{fancyimportant|If there are multiple kernel srms available for a System Rescue CD release, Only copy the srm for the kernel you will be booting.}}

3. List your /mnt directory and you should see something similar to the following in your /mnt

<console>
funtoo tmp # ls -lh /mnt
total 263M
drwxr-xr-x 3 root root 4.0K Jan 8 02:39 boot
drwxr-xr-x 2 root root 4.0K Jan 8 02:39 bootdisk
drwxr-xr-x 2 root root 4.0K Jan 8 02:39 bootprog
drwxr-xr-x 3 root root 4.0K Jan 8 02:39 efi
drwxr-xr-x 2 root root 4.0K Jan 8 02:39 ntpasswd
drwxr-xr-x 3 root root 4.0K Jan 8 02:40 syslinux
drwxr-xr-x 2 root root 4.0K Jan 8 02:49 sysrcd
-rwxr-xr-x 1 root root 260M Jan 8 02:39 sysrcd.dat
-rwxr-xr-x 1 root root 45 Jan 8 02:39 sysrcd.md5
drwxr-xr-x 2 root root 4.0K Jan 8 02:39 usb_inst
-rwxr-xr-x 1 root root 16K Jan 8 02:39 usb_inst.sh
-rwxr-xr-x 1 root root 877 Jan 8 02:39 usbstick.htm
-rwxr-xr-x 1 root root 6 Jan 8 02:39 version
-rwxr-xr-x 1 root root 62 Jan 8 02:50 zfs-3.4.27-std330-amd64.md5
-rwxr-xr-x 1 root root 2.4M Jan 8 02:50 zfs-3.4.27-std330-amd64.srm
</console>

Now unmount the and boot it into the machine that you want to use ZFS on.

<console>
# ##i##umount /mnt/usbstick
</console>

== Booting into the correct kernel ==
'''If you are using the standard srm:'''
<console>
C) Standard 64bit kernel (rescue64) with more choice... >
1. SystemRescueCd with default options
</console>

'''If you are using the alternative srm:'''
<console>
E) Alternative 64bit kernel (altker64) with more choice... >
1. SystemRescueCd with default options
</console>

3. Run 'depmod' so that the new modules can be seen by the kernel.
4. Run 'modprobe -v zfs to load the modules.

<console>
# ##i##depmod
# ##i##modprobe -v zfs
</console>

{{fancywarning|You must run '''depmod'''. If you don't, then you will get failed to load the ZFS stack error! And after modprobe you can check with 'lsmod' if the 6 modules where loaded.}}

5. Use ZFS as usual. If you type zpool status and then type `dmesg | tail`,

you should see something that says:

<console>
ZFS: Loaded module v0.6.0-rc13, ZFS pool version 28, ZFS filesystem version 5
</console>

If you see the above, then the modules loaded successfully!

Enjoy System Rescue CD with ZFS :)

== Extra ==

=== A more accurate kernel build setup ===
If you want to have a more accurate setup to upstream, you can check out the git repo he has for the target release. Example: [http://sourceforge.net/p/systemrescuecd/code/ci/74e7a9712a019958fbe099386c9fb6bd7813d907/tree/ Upstream Git Repo]

If you navigate to portage-overlay/sys-kernel/std-sources, you can see the ebuild there and the files directory with the patches for the std-sources kernel.
[[Category:HOWTO]]

Whenjobs

2013-02-01T22:10:45Z

Golodhrim: update warning about shellscript and #-sign

== What are whenjobs ==

{{fancywarning|This document is a work in progress, as we are still investigating whenjobs for funtoo usage. For information about it see Funtoo tickets about [http://bugs.funtoo.org/browse/FL-316 whenjobs], [http://bugs.funtoo.org/browse/FL-337 initscript], [http://bugs.funtoo.org/browse/FL-338 User Feedback] and [http://bugs.funtoo.org/browse/FL-351 this document].}}

Whenjobs are written by Richard Jones from [http://www.redhat.com RedHat Linux]. They are designed to be a cron daemon replacement with some improvements over normal cron-jobs. Further more we from Funtoo Linux added some improvements to them already. Whenjobs give users a simpler syntax for jobs to run and with funtoo improvements a good way of user-management for whenjobs, that way we fixed the default behaviour of whenjobs to not been able to run as root and let us execute the daemon on a userbasis by default.

=== Question for help and testing ===

With this tutorial we like to ask users to help us and test whenjobs. We would like to get your feedback to [http://bugs.funtoo.org/browse/FL-338 FL-338]. So please test and report there what you think and what you think should be improved.

== How to install whenjobs ==

The installation of whenjobs is really easy, just merge them and you would get all that is needed for a first testrun and later perhaps also a production usage.

<console>
# ##i##emerge -avt whenjobs
</console>

That's what is needed for installing whenjobs, nothing big so far.

== How to get started ==

As mentioned above we added a user-management and whenjobs has a changed syntax compared to normal cronjobs so we will discuss all these parts now. :)

=== user management ===

The user management for whenjobs is done with a single file located at '''/etc/whenjobs.users.conf''' just add a user to that file by a commaseperated list like

<pre>
root,user1,user2,user3
</pre>

where user1-user3 have to be system-usernames as they are checked. please do not add any other lines to that file, as there is atm now way for comments in the file and adding other lines will break so far the usage and you won't be able to start the daemon later. ATM there is no initscript, but we are working on one and that initscript will then use that file in the same way. :)

=== whenjobs commands ===

There are some basic commands for whenjobs you should be aware of before we get to explain the script syntax for whenjobs. this part will explain them.

To edit/list a job script use

<console>
# ##i##whenjobs -e | --edit
# ##i##whenjobs -l | --list
</console>

in the above case we added both the short and long version in one line so please use either the '''-e''' or the '''--edit''' version as there is no piping done at that part. We will use the same syntax for further examples if there are multiple ways of calling the function we need.

Another import part is to set or get variables we want to set or set in whenjobs, that can be done with:

<console>
to get a variable:
# ##i##whenjobs --get variable
to set a variable or multiple varibles:
# ##i##whenjobs --set variable=value [variable=value ...]
and to display all set variables:
# ##i##whenjobs --variables
</console>

Another important function in whenjobs is the way to start, stop and request the status of the per-user daemon.

<console>
# ##i##whenjobs --daemon-start
# ##i##whenjobs --daemon-stop
# ##i##whenjobs --daemon-status
# ##i##whenjobs --daemon-restart
</console>

Finally we have the ability to inspect running jobs:

<console>
# ##i##whenjobs --jobs
# ##i##whenjobs --cancel serial
# ##i##whenjobs --start "name"
# ##i##whenjobs --tail serial
</console>

=== How to get started with whenjobs now ===

First edit the above mentioned '''whenjobs.users.conf''' file if not already done and start a daemon on a per-user basis with

<console>
# ##i##whenjobs --daemon-start
</console>

Thats all for starting whenjobs and now we have time to write some whenjobs-scripts. We will use here some basic examples nothing for real time usage but it should be able to give you the impression on how to write your own scripts and use the variables in the later process. First we need to edit our whenjobs-script. This can be done by two ways:

<console>
Version A) (manual way, not recommended)
# ##i##EDITOR ~/.whenjobs/jobs.ml
Edit the file with the scripts you want to use and save it, but after that you need to upload it so that whenjobs knows about it
# ##i##whenjobs --upload
Version B) (automatically by whenjobs, recommended)
# ##i##whenjobs -e | --edit
just save your script now and whenjobs will upload it automatically for you.
</console>

So far we are now fine with getting to the scripts, next let us add some basics. We will now start with a periodic call, like if we would like to check out load everyage every 10 minutes we would do it like this:

{{fancywarning|A note aside, the scripts are real shell scripts, so parts beginning with a '''#''' are comments and parts without are the shell script commands that are executed!}}

<source lang="ocaml">
every 10 minutes :
<<
# Get the current load average.
load=`awk '{print $1}' /proc/loadavg`
whenjobs --set --type float load=$load
>>
</source>

The power of whenjobs comes in game when you would like to base on a variable you set somewhere else:

<source lang="ocaml">
when load >= 6 :
<<
mail -s "ALERT: high load average: $load" MAILADDRESS < /dev/null
>>
</source>

That part will notify a user via email when his load average is greater or equal to 6, as when statements are "edge-triggered".

The '''--type''' switch above for setting a variable can be one of '''bool, int, float, string or unit'''

==== Periodic expressions ====

For periodic expressions you have to use the following syntax

<source lang="ocaml">
every <period> :
<<
# shell script
>>
</source>

where '''<period>''' is one of the following period expressions:

{| class="wikitable"
! <period>
! Description
!
! Special <period>
! Description
|-
| second
| runs every second
|
| X seconds
| runs every X seconds
|-
| minute
| runs every minute
|
| X minutes
| runs every X minutes
|-
| hour
| runs every hour
|
| X hours
| runs every X hours
|-
| day
| runs every day, at midnight UTC
|
| X days
| runs every X days, at midnight UTC
|-
| week
| runs every week, on a Thursday at midnight UTC
|
| X weeks
| runs every X weeks, on a Thursday at midnight UTC
|-
| month
| runs every month, on the 1st at midnight UTC
|
| X months
| runs every X month, on the 1st at midnight UTC
|-
| year
| runs every year, on the 1/1 at midnight UTC
|
| X years
| runs every X years, on the 1/1 at midnight UTC
|-
| decade
| runs every 10 years
|
| X decades
| runs every X decades
|-
| century
| runs every 100 years
|
| X centuries
| runs every X centuries
|-
| millenium
| runs every 1000 years
|
| X millenia
| runs every X mellenia
|}

==== When expressions ====

For dependent jobs you need to use the when-statements with the following syntax:

<source lang="ocaml">
when <expr> :
<<
# shell script
>>
</source>

where '''<expr>''' is a when expression. But don't forget the colon between periods expression or when expression and the shell script.

All in all you can say, that a when-expression is a job which runs, when the described conditions become true.

{| class="wikitable"
! <expr>
! meaning
!
! <expr>
! meaning
|-
| expr && expr
| boolean "and" of the two sub-expressions
|
| ! expr
| boolean negative of expr
|-
| expr <nowiki>||</nowiki> expr
| boolean "or" of the two sub-expressions
|
| expr + expr
| for numeric sub-expression, this performs addition, for strings it performs string concatenation, else it returns an error.
|-
| expr < expr
| evaluates sub-expressions and compares them with the operator
|
| expr - expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error
|-
| expr <= expr
| evaluates sub-expressions and compares them with the operator
|
| expr * expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error
|-
| expr == expr
| evaluates sub-expressions and compares them with the operator
|
| expr / expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error
|-
| expr >= expr
| evaluates sub-expressions and compares them with the operator
|
| expr mod expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error (infix operator)
|-
| expr > expr
| evaluates sub-expressions and compares them with the operator
|
| len expr
| returns the length of the string in expr
|-
| variable
| returns the value of named variable
|
| prev variable
| returns previous value of named variable
|-
| changes variable
| same as !(prev variabel == variable)
|
| increases variable
| same as prev variable < variable
|-
| decreases variable
| prev variable > variable
|
| reloaded ()
| do not use it, it does not what you want (manpage warning)
|-
| false
| constant equals always false
|
| true
| constant equals always true
|-
| "any string"
| empty string in boolean = false, else equals true
|
| N
| any integer, boolean 0=false, non-zero=true
|-
| N. | .N | N.N | N.NeN
| and floating point number, boolean 0=false, non-zero=true
|
|
|
|}

==== shell scripts ====

The code between '''<< ... >>''' is a simple shell script and is executed using $SHELL. If $SHELL is not set, it is executed with '''/bin/sh'''

{| class="wikitable"
! available variable
! Description
|-
| $JOBNAME
| The name of the job. If the job has been named explicitly, then that name is available through this variable, else it will be some implicit name like '''job$1'''.
|-
| $JOBSERIAL
| The serial number of the job. This is simply a variable that increments each time a job is run, and is unique to that run of the job.
|-
| $HOME, $LOGNAME etc
| these are available as normal
|}

The shell scripts run with its current directory set to an temporary directory, that is cleaned up automacically after the job exists. So you don't have to worry about cleaning them up later. If you would like to store some values permanently, save the files to a well-known directory, eg. $HOME, '''/var''' etc.

All shell scripts are executed as the ordinary user. They have no special privileges.

==== Job names ====

If you like to give a job a unique name use the following syntax:

<source lang="ocaml">
job "JOBNAME"
every <period> :
<<
# shell script
>>
</source>

==== OCAML expressions ====

You can also use OCAML expressions in the code. they are useful for factoring common code or strings, for example:

<source lang="ocaml">
let prefix = "daily_"

job (prefix ^ "virus_scan")
every day :
<<
# shell script
>>

job (prefix ^ "disk_check")
every day :
<<
# shell script
>>
</source>

===== initial value of variables =====

Variables are empty until they first get set, you can set a default starting value for a variable if you like with the following code

<source lang="ocaml">
let () =
Whentools.set_variable "variable" "value";
Whentools.set_variable_int "counter" 0
</source>

===== Pre functions =====

You can let arrange to run a '''pre''' function before a job runs. This function may decide to not run the job. One possible usage for that is the that you only want to have one job at time from the same job to run:

<source lang="ocaml">
job "only one"
pre (Whentools.one ())
every <period> :
<<
# shell script
>>
</source>

===== Post functions =====

The same is for stuff after a job has run. This is handled by the '''post''' function.

<source lang="ocaml">
job "talk to me after finished"
post (Whentools.mailto "you@example.com")
every <period> :
<<
# shell script
>>
</source>

===== Basic available Whentools functions =====

{| class="wikitable"
! function
! Description
|-
| style="vertical-align:top;"| whentools.mailto [~only_on_failure:true] [~from:from_address] email_address result
| This built-in post function sends the result of the script by email to the given email address.

If the optional "~only_on_failure:true" flag is set, then it is only sent out if the script failed.

If the optional "~from" flag is set, then the from address is set accordingly. This is sometimes needed when sending mail.

Note the "result" parameter is passed implicitly by the daemon. You do not need to add it.

Here are some examples of using the mailto function:

<source lang="ocaml">
job "ex.1"
post (Whentools.mailto "you@example.com")
every 10 seconds :
<<
# shell script 1
>>

job "ex.2"
post (Whentools.mailto ~only_on_failure:true "you@example.com")
every 10 seconds :
<<
# shell script 2
>>

let from = "me@example.com"
let to_addr = "you@example.com"

job "ex.3"
post (Whentools.mailto ~from to_addr)
every 10 seconds :
<<
# shell script 3
>>
</source>
|-
| style="vertical-align:top;"| Whentools.max n
| This built-in pre function ensures that a maximum of n instances of the job are running.

It checks the list of running jobs, and if n or more instances are already running, then it returns "false", which ensures that the new job is not started.
|-
| style="vertical-align:top;"| Whentools.one ()
| This built-in pre function ensures that only one instance of the job is running. It is the same as calling: Whentools.max 1

|-
| style="vertical-align:top;"| Whentools.set_variable name string
| Set variable name to the string
|-
| Whentools.set_variable_bool name b
| Set variable name to the boolean value b
|-
| style="vertical-align:top;"| Whentools.set_variable_int name i
| Set variable name to the integer value i
|-
| style="vertical-align:top;"| Whentools.set_variable_string name s
| Set variable name to the string value <s>. This is the same as Whentools.set_variable
|-
| style="vertical-align:top;"| Whentools.set_variable_float name f
| Set variable name to the floating point value f
|}

For the preinfo passed to the pre functions and results for the post functions have a view in the manpage.

== Examples ==

Finally here are some examples to which questions came up, hope you find them helpful for your first own tries... :)

<source lang="ocaml">
every 1 minute :
<<
testtime=`date +%H%M`
whenjobs --set --type int test=${testtime}
whenjobs --set --type int runtime=0016
>>

when test == 0017 :
<<
echo `date` >\> ~/test.log
>>

when test == runtime
<<
whenjobs --get runtime >\> ~/test.log
>>
</source>

The above whenjobs have the need to run each day at a specific time, so we show you here two ways of doing it.

First we define a variable test for whenjobs based on the date with the HHMM output what would for example result in 0017 for 12:17am and 1428 for 2:28pm. then in the first when expression we test if our variable equals 0017 and if yes it runs, the second version is to define a second variable called runtime and then do like the second test does a test for it based on comparing both variables.

But now enough with that long doc, happy whenjobing for all of you... :)

[[Category:HOWTO]]
[[Category:Labs]]
[[Category:Featured]]

Funtoo Events

2013-01-29T21:29:28Z

Golodhrim:

{{Event Calendar Item
|event=Start of Funtoo Events Calendar
|start=2013/01/29
|type=Meeting
}}

This site is a WIP for events the Funtoo Community is invited to join and get a meet and greet with devs and other entusiast of Funtoo Linux. :)

{{#ask:[[Has event::+]][[Has event start::+]]
|?Has event=title
|?Has event start
|?Has event end
|?Has event description=Description
|?Has event icon=icon
|?Has event color=color
|?Has event location
|format=eventcalendar
|start=earliest
|defaultview=month
|limit=
|link=subject
|legend=pane
|firstday=Sunday
|dayview=yes
|headers=show
|theme=vector}}

{{#formlink:popup|form=Event Calendar Item|link text=Create event|link type=button}}

Boot Methods

2013-01-22T00:28:34Z

D2 racing: /* Pure UEFI */

This page describes the various methods that can be used to set up a disk to boot Funtoo Linux. If you have more than one disk, choose a single disk to serve as your boot disk.

=== Pure MBR + GRUB ===

This option is the "classic" way to boot Funtoo Linux and uses traditional MBR partitions, which have existed since the origin of the PC. Here is the typical disk layout:

* MBR at beginning of boot disk
* MBR partition 1, <tt>/dev/sda1</tt> is the <tt>/boot</tt> filesystem (typically ext2)
* MBR partition 2, <tt>/dev/sda2</tt> is ''swap''.
* MBR partition 3, <tt>/dev/sda3</tt> is the <tt>/</tt> (root) filesystem.

Here's how the boot process works:

# The system BIOS loads the MBR from your boot disk (containing stage1 of the GRUB boot loader) and runs it.
# Extra boot-related code is loaded by the GRUB stage1 from the <tt>/boot</tt> filesystem on the disk.

Now, the boot loader is able to run and load the Linux kernel and initramfs, and start Funtoo Linux.

=== GPT + GRUB ===

This is a more modern way to boot Linux. It uses MBR for booting but uses the more modern GPT partition scheme. Here's the disk layout:

* ''no MBR is installed or required''
* GPT partition 1, <tt>/dev/sda1</tt> is the <tt>/boot</tt> filesystem (typically ext2)
* GPT partition 2 type 0xEF02, <tt>/dev/sda2</tt> is the ''boot loader partition'' (this contains a fake MBR).
* GPT partition 3, <tt>/dev/sda3</tt> is ''swap''.
* GPT partition 4, <tt>/dev/sda4</tt> is the <tt>/</tt> (root) filesystem.

Here's how this hybrid scheme works:

# The system BIOS loads the fake MBR from your boot disk(/dev/sda2) (containing stage1 of the GRUB boot loader) and runs it.
# Extra boot-related code is loaded by the GRUB stage1 from a small (a few MB) GPT partition on the disk.

Now, the boot loader is able to run and load the Linux kernel and initramfs, and start Funtoo Linux.

=== UEFI + GRUB ===

UEFI is a new-style firmware that is used for booting. It is generally available on all new PCs (2012 and newer) and may be available on older systems as well. Here's the disk layout:

* ''no MBR is installed or required''
* GPT partition 1, <tt>/dev/sda1</tt> is the <tt>/boot</tt> filesystem (<tt>vfat</tt> aka "FAT32").
* GPT partition 2, <tt>/dev/sda2</tt> is ''swap''.
* GPT partition 3, <tt>/dev/sda3</tt> is the <tt>/</tt> (root) filesystem.

Here's how this boot scheme works:

# UEFI (contained in your motherboard's firmware) loads the Bootmanager entry from the RW NVRAM inside your motherboard.
# If there's a valid entry that contains Grub, then the GRUB boot loader code from your <tt>/boot</tt> filesystem will be loaded.
# UEFI can read from <tt>vfat</tt> partitions directly, which is why we use <tt>vfat</tt> instead of the normal <tt>ext2</tt> for <tt>/boot</tt>.

Now, the boot loader is able to run and load the Linux kernel and initramfs from the <tt>vfat</tt> <tt>/boot</tt> filesystem, and start Funtoo Linux.

=== Pure UEFI ===

A Pure UEFI boot is also possible. The partitioning scheme is the same as the UEFI + GRUB scheme, above.

Here's how this boot scheme works:

# UEFI (contained in your motherboard's firmware) loads the Bootmanager entry from the RW NVRAM inside your motherboard.
# UEFI loads the Linux kernel STUB and initramfs directly, and runs the Linux kernel to start Funtoo Linux.

Forking An Ebuild

2013-01-21T03:40:15Z

Palica:

Often, a Funtoo developer needs to fork an upstream ebuild. This is necessary when we want to apply fixes to it. This page will explain the concepts of forking and how this works in the context of Funtoo.

== Portage Tree Generation ==

Funtoo Linux generates its Portage tree using a special script that essentially takes a Gentoo tree as its starting point, and then applies various modifications to it. The modifications involve adding packages from various overlays, including our [[Overlay:Funtoo-overlay]]. Some packages added are brand new, while other packages are our special forked versions that replace existing packages.

In the vast majority of cases, when we fork a package, we take full responsibility for all ebuilds associated with that package, meaning that we have a full copy of the <tt>sys-foo/bar</tt> directory in one of our overlays.

If you're interested in seeing the actual script that does all these things, take a look at the following files:

; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/current-update.sh: cronned script that calls <tt>merge.py</tt>.
;http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge.py: python script that does the heavy lifting of combining Gentoo tree with various overlays, including our flora and funtoo-overlay. When we want to change what overlays we merge, what packages we exclude as a matter of policy (such as stale packages in some overlays), we make changes to this file.
; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge_utils.py: python module that contains classes and methods that implement the merging functionality.

== Forking an Ebuild ==

In general, we fork ebuilds from Gentoo that we want to modify in some way. Before you fork an ebuild, it's important to understand that in general we fork entire packages, not just a single ebuild. This means that if you want to make some changes to <tt>sys-foo/bar</tt>, you are going to fork all <tt>sys-foo/bar</tt> ebuilds, and then Funtoo will be responsible for continuing to maintain these ebuilds until the package is unforked. Here are the steps we would use to fork <tt>sys-foo/bar</tt>:

# Find <tt>sys-foo/bar</tt> in you regular Portage tree. Make sure you have run <tt>emerge --sync</tt> recently to ensure it is up-to-date. If you want to fork from very recent changes that are not yet in our tree, you may need to grab the most recent Gentoo Portage tree to serve as your source for <tt>sys-foo/bar</tt> (this typically isn't necessary.)
# Copy the <tt>sys-foo/bar</tt> directory in its entirety to <tt>funtoo-overlay/sys-foo/bar</tt>.
# Make any necessary modifications to <tt>funtoo-overlay/sys-foo/bar</tt>.
# Perform some funtoo-ification steps prior to commit.
# Add and commit the changes to funtoo-overlay.
# Push changes to funtoo-overlay.

At this point, the forked <tt>sys-foo/bar</tt> package will be part of funtoo-overlay. The next time our unified Portage tree is generated by <tt>merge.py</tt> (the one that users have in their <tt>/usr/portage</tt> and is updated via <tt>emerge --sync</tt>), your forked ebuild will be used in place of the Gentoo ebuild. Why is this? It is because our <tt>merge.py</tt> script has been defined with a policy that any ebuilds in funtoo-overlay will replace any existing Gentoo ebuilds if they exist. The mechanism of replacement is that our <tt>sys-foo/bar</tt> directory will be used in place of Gentoo's <tt>sys-foo/bar</tt> directory. So this is how the forking process works.

== Funtoo-ification ==

When we fork a package from Gentoo, we perform the following tweaks to the package directory before committing:

# Removal of <tt>ChangeLog</tt>.
# Run <tt>ebuild foo-1.0.ebuild digest</tt> before committing. This will cause the <tt>Manifest</tt> file to be regenerated. Gentoo has a lot more entries in this file than we do, since we use mini-Manfiests that only include DIST listings (for distfiles only.) We want to commit our mini-Manifest (still called <tt>Manifest</tt>, just with less entries in it) rather than the one that came from Gentoo.
# Edit the top of each ebuild, and remove all <tt>Copyright</tt> and <tt>$Header:</tt> lines at the top of the file. We have a LICENSE.txt and COPYRIGHT.txt file in the root of our Portage tree, which is easier to maintain than keeping all the years up-to-date in each ebuild. Also, the <tt>$Header:</tt> line is there for the CVS version control system in Gentoo which Funtoo does not use. ''The only comment that should remain on the top of the ebuild is the one stating that it is distributed under the GPLv2.''.

Here are a few additional changes that you are allowed to make to any forked ebuilds:

# Line length greater than 80 characters. Gentoo enforces an 80-character line length limit. We don't.
# <tt>KEYWORDS</tt> of <tt>*</tt> and <tt>~*</tt>. Gentoo does not allow these shortcuts. We do. They allow you to say "all arches" and "all unstable arches" in a concise way. Gentoo doesn't allow these shortcuts because it's Gentoo's policy to have each arch team manually approve each package. We do not have this policy so we can use the shortcuts.
# Use of <tt>4-python</tt> EAPI. We allow the use of this EAPI for enhanced python functionality.

[[Category:Development]]

ODROID U2

2013-01-14T01:20:55Z

Jeanfrancis: /* Kernel and modules */

The [http://www.hardkernel.com/renewal_2011/products/prdt_info.php| ODROID U2 ] is an ARM development board, featuring a 1.7 GHz quad-core CPU (ARMv7a). This document contains notes about installing Funtoo Linux on this device.

== Cross-compiler installation ==

To compile a suitable Linux kernel and bootloader for the ODROID U2, you need to install an ARMv7a hardfloat toolchain on your system.

<console>
# ##i##emerge crossdev
# ##i##crossdev -v -t armv7a-hardfloat-linux-gnueabi
</console>

{{fancywarning|In the following sections, replace /dev/sdX with the actual device node of your SD card.}}

== U-boot bootloader ==

The ODROID-U2 needs U-boot as a bootloader. The ODROID U2 vendor provides a git repository with all what is needed to build and install U-boot on the SD-card that will be used to boot the device.

<console>
# ##i##mkdir ~/odroid_u2
# ##i##cd ~/odroid_u2
# ##i##git clone https://github.com/hardkernel/u-boot.git
# ##i##cd u-boot
# ##i##make smdk4412_config
# ##i##make ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi-
</console>

If U-boot does not build with your ARM toolchain, see the troubleshooting section. It may happen that U-boot does not build with a recent toolchain.

Now, the following will install U-boot on the beginning sectors of your SD card.

<console>
# ##i##cd sd_fuse
# ##i##./sd_fusing.sh /dev/sdX
</console>

== Partitionning ==

{{fancywarning|The bootloader takes a bit more space than usual. You must keep about 5 MB (10240 sectors for example) of free space before the first partition.}}

You may now partition your SD card to fit your needs. However, U-boot expects to find a FAT32 boot partition (first or second). Also, U-boot needs free space before the first partition.

<pre>
Partition Table for /dev/sdX

First Last
# Type Sector Sector Offset Length Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
Pri/Log 0 10239* 0# 10240*Free Space None
1 Primary 10240* 215039* 0 204800*W95 FAT32 (0B) None
2 Primary 215040* 2214599* 0 1999560*Linux swap / So (82) None
3 Primary 2214600* 15269887* 0 13055288*Linux (83) None
</pre>

Now, format your partitions, e.g.

<console>
# ##i##mkfs.vfat /dev/sdX1
# ##i##mkswap /dev/sdX2
# ##i##mkfs.ext4 /dev/sdX3
</console>

== Funtoo Linux Installation ==
Follow the guide from [[Funtoo Linux Installation on ARM]] to begin the installation of Funtoo on the root filesystem. Note that once you are finished, you will not be able to boot the ODROID U2 until you complete the next sections.

=== Kernel and modules ===

The ODROID U2 vendor provides kernel sources and default .config files for the ODROID U2. In this example, we clone the git repository, use the default branch, and build the default ubuntu kernel config. Note that other branches exist, some of them provide default configurations for the U2, others not.

{{fancywarning|As in [[Funtoo Linux Installation on ARM]], we consider that the root partition is mounted in /mnt/SD_root. Also, we consider that the boot partition is /dev/sdX1.}}

<console>
# ##i##cd ~/odroid_u2
# ##i##git clone https://github.com/hardkernel/linux.git
# ##i##cd linux
# ##i##ARCH=arm make odroidu2_ubuntu_defconfig
# ##i##ARCH=arm CROSS_COMPILE=/usr/bin/armv7a-hardfloat-linux-gnueabi- make -j8 (adapt depending on the number of cores available on the build machine)
# ##i##mount /dev/sdX1 /mnt/SD_root/boot
# ##i##ARCH=arm CROSS_COMPILE=/usr/bin/armv7a-hardfloat-linux-gnueabi- make modules_install INSTALL_MOD_PATH=/mnt/SD_root
# ##i##cp arch/arm/boot/zImage /mnt/SD_root/boot
</console>

== Boot partition setup ==
You now have a kernel in /mnt/SD_root/boot. The only missing part is a file named ''boot.scr'', which will be read by U-boot.

First, create a ''boot.txt'' file on the boot partition.

<console>
# ##i##cd /mnt/SD_root/boot
# ##i##touch boot.txt
</console>

Modify this file to contain the following :

<pre>
setenv initrd_high "0xffffffff"
setenv fdt_high "0xffffffff"
setenv fb_x_res "1920"
setenv fb_y_res "1080"
setenv hdmi_phy_res "1080"
setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; bootm 0x40008000"
setenv bootargs "console=tty1 console=ttySAC1,115200n8 fb_x_res=${fb_x_res} fb_y_res=${fb_y_res} hdmi_phy_res=${hdmi_phy_res} root=/dev/mmcblk0p3 rootwait ro mem=2047M"
boot
</pre>

{{fancywarning|Modify the screen resolution to fit your needs. Also, modify ''/dev/mmcblk0p3'' for the correct device of your root partition. ''/dev/mmcblk0p3'' is the third partition of the SD-card. Modify the last digit to fit your partitioning scheme.}}

Now, install u-boot-tools that provides ''mkimage'' and create ''boot.scr''.

<console>
# ##i##emerge u-boot-tools
# ##i##mkimage -A arm -T script -C none -n "Boot.scr for odroid-u2" -d boot.txt boot.scr
</console>

== Further configuration ==

=== fstab ===
<pre>
/dev/mmcblk0p1 /boot vfat noauto,noatime 1 2
/dev/mmcblk0p2 none swap sw 0 0
/dev/mmcblk0p3 / ext4 noatime 0 0
</pre>

Note: We disable fsck checking of some devices as it may fail because of the missing hardware clock on the device.

=== inittab ===

If you have USB/UART debugging hardware, you may want to change /etc/inittab the following way :

<pre>
# SERIAL CONSOLESs0:12345:respawn:/sbin/agetty 115200 ttySAC1 vt100
</pre>

== Troubleshooting ==

=== Error: selected processor does not support ARM mode `smc 0' ===
<pre>--- board/samsung/smdk4212/smc.c.orig 2013-04-30 17:34:16.556093458 -0400
+++ board/samsung/smdk4212/smc.c 2013-04-30 17:34:50.422095103 -0400
@@ -90,6 +90,7 @@
register u32 reg3 __asm__("r3") = arg3;

__asm__ volatile (
+ ".arch_extension sec\n"
"smc 0\n"
: "+r"(reg0), "+r"(reg1), "+r"(reg2), "+r"(reg3)

@@ -104,6 +105,7 @@
register u32 reg1 __asm__("r1") = 0;
__asm__ volatile (
+ ".arch_extension sec\n" "smc 0\n"
: "+r"(reg0), "+r"(reg1)
</pre>

Source :http://forum.insignal.co.kr/viewtopic.php?f=10&t=118

=== armv7a-hardfloat-linux-gnueabi-ld: error: /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not ===

<pre>
--- arch/arm/cpu/armv7/config.mk.orig 2013-04-30 17:40:20.842111160 -0400
+++ arch/arm/cpu/armv7/config.mk 2013-04-30 17:40:52.368112692 -0400
@@ -20,7 +20,7 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -mfloat-abi=hard -mfpu=vfpv3

# Make ARMv5 to allow more compilers to work, even though its v7a.
PLATFORM_CPPFLAGS += -march=armv7-a
</pre>

Source :
https://code.google.com/p/chromium/issues/detail?id=213120

Raspberry Pi

2013-01-08T19:02:49Z

Drobbins: /* Installation */

The [http://raspberrypi.org Raspberry Pi] is an ARM device (BCM2835, ARMv6).

This document contains notes about getting Funtoo Linux up-and-running on the Raspberry Pi. Most information is already available on other documents, so this document mostly explains how to get the information needed to perform the installation.

Please read [[Funtoo Linux Installation on ARM]] for general information about installing Funtoo Linux on ARM architecture.

== Installation ==

Gentoo Linux's wiki already provide a complete installation manual for Gentoo Linux. To avoid duplicating information, only parts that are different for Funtoo Linux will be highlighted here.

[http://wiki.gentoo.org/wiki/Raspberry_Pi_Quick_Install_Guide Gentoo's Raspberry Pi Quick Install Guide]

=== Stage 3 ===

Funtoo Linux Stage 3 tarballs for Raspberry Pi can be found on [http://ftp.osuosl.org/pub/funtoo/funtoo-current/arm-32bit/armv6j_hardfp/].

Extracting the tarball is done using <tt>tar xf</tt> instead of <tt>tar xjf</tt>.

=== Portage ===

Funtoo Linux Portage tarballs can be found on [http://ftp.osuosl.org/pub/funtoo/funtoo-current/snapshots/].

Extracting the tarball is done using <tt>tar xf</tt> instead of <tt>tar xjf</tt>.

=== Enabling networking on boot ===

Please consult [[Funtoo Linux Networking]] for information regarding network configuration.

=== Select profile ===

Funtoo Linux has a different profile than Gentoo. Correct ''arch'' and ''build'' will be already set. It is possible to change ''flavor'' or add ''mix-ins'' using eselect.

More information can be found on [[Funtoo 1.0 Profile]].

<console>
# ##i##eselect profile list
Currently available arch profiles:
[1] funtoo/1.0/linux-gnu/arch/arm-32bit/armv7a_hardfp
[2] funtoo/1.0/linux-gnu/arch/arm-32bit/armv6j_hardfp *
Currently available build profiles:
[3] funtoo/1.0/linux-gnu/build/stable
[4] funtoo/1.0/linux-gnu/build/current *
[5] funtoo/1.0/linux-gnu/build/experimental
Currently available flavor profiles:
[6] funtoo/1.0/linux-gnu/flavor/minimal
[7] funtoo/1.0/linux-gnu/flavor/core *
[8] funtoo/1.0/linux-gnu/flavor/desktop
[9] funtoo/1.0/linux-gnu/flavor/workstation
Currently available mix-ins profiles:
[10] funtoo/1.0/linux-gnu/mix-ins/audio
[11] funtoo/1.0/linux-gnu/mix-ins/console-extras
[12] funtoo/1.0/linux-gnu/mix-ins/dvd
[13] funtoo/1.0/linux-gnu/mix-ins/gnome
[14] funtoo/1.0/linux-gnu/mix-ins/kde
[15] funtoo/1.0/linux-gnu/mix-ins/media
[16] funtoo/1.0/linux-gnu/mix-ins/print
[17] funtoo/1.0/linux-gnu/mix-ins/python3-only
[18] funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
[19] funtoo/1.0/linux-gnu/mix-ins/server-db
[20] funtoo/1.0/linux-gnu/mix-ins/server-mail
[21] funtoo/1.0/linux-gnu/mix-ins/server-web
[22] funtoo/1.0/linux-gnu/mix-ins/X
[23] funtoo/1.0/linux-gnu/mix-ins/xfce
</console>

Squid

2013-01-07T16:54:09Z

77.109.107.46:

== The Squid Proxy Server ==

'''This is a quick and dirty howto about getting Squid up und running in 5min...'''

What benefits one may get from using an anonymous proxy server? Well, I would say many things but the most important one is that you can browse the web anonymously without exposing your IP, location etc.. out there. Anyhow, even though I usually use OpenVPN or PPTP for safe browsing and such things, having a private anonymous proxy server in your toolbox is a nice thing.
Furthermore, a cache is speeding up you daily internet connection with repeating objects getting out of the cache instead of downloading it again. Advanced filtering technics (Antivirus, Content, Ad-Blocks, etc) are also possible.

Please start always by refreshing your portage tree, like:

# emerge --sync
then I’ve searched the portage tree for ‘squid’ using my pkgfile function and got this:
<pre>
# pkgfile squid
=> net-analyzer/squid-graph
=> net-analyzer/squidsites
=> net-analyzer/squidview
=> net-proxy/squid
=> net-proxy/squidclamav
=> net-proxy/squidguard
=> sec-policy/selinux-squid
</pre>

ok, then emerged ‘net-proxy/squid’ using:
# emerge -av net-proxy/squid

once it got installed, since this squid proxy setup will be using authentication to authenticate users via the ‘ncsa_auth‘ helper, we need to know the location of this helper so we can use it in our squid.confconfiguration file. To find this I’ll be using a tool named as ‘qfile‘ which is shipped in ‘app-portage/portage-utils‘.

# qfile ncsa_auth
net-proxy/squid (/usr/libexec/squid/ncsa_auth)

ok, so the auth helper is located in ‘/usr/libexec/squid/ncsa_auth’ so let’s setup Squid’s configuration file (/etc/squid/squid.conf). Make sure you change ‘XXX.XX.XX.XXX’ with your actual server’s IP address and edit anything else you want to suit your needs.

<pre># cp /etc/squid/squid.conf{,_orig} && \cat > /etc/squid/squid.conf <<EOF
auth_param basic program /usr/libexec/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm please login?
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 10.0.0.0/8
# RFC 1918 possible internal network
acl localnet src 172.16.0.0/12
# RFC 1918 possible internal network
acl localnet src 192.168.0.0/16
# RFC 1918 possible internal network
acl localnet src fc00::/7
# RFC 4193 local private network range
acl localnet src fe80::/10
# RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow localhost
http_access deny all
http_port 2222
coredump_dir /var/cache/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
icp_access allow localnet
icp_access deny all
acl ip1 myip XXX.XX.XX.XXX
tcp_outgoing_address XXX.XX.XX.XXX ip1
cache_mgr mail@maiwald.tk
cache_mem 128 MB
visible_hostname ViruSzZ
maximum_object_size 20 MB
cache_dir ufs /var/cache/squid 512 32 512

forwarded_for off
request_header_access Allow allow all
request_header_access Authorization allow all
request_header_access WWW-Authenticate allow all
request_header_access Proxy-Authorization allow all
request_header_access Proxy-Authenticate allow all
request_header_access Cache-Control allow all
request_header_access Content-Encoding allow all
request_header_access Content-Length allow all
request_header_access Content-Type allow all
request_header_access Date allow all
request_header_access Expires allow all
request_header_access Host allow all
request_header_access If-Modified-Since allow all
request_header_access Last-Modified allow all
request_header_access Location allow all
request_header_access Pragma allow all
request_header_access Accept allow all
request_header_access Accept-Charset allow all
request_header_access Accept-Encoding allow all
request_header_access Accept-Language allow all
request_header_access Content-Language allow all
request_header_access Mime-Version allow all
request_header_access Retry-After allow all
request_header_access Title allow all
request_header_access Connection allow all
request_header_access Proxy-Connection allow all
request_header_access User-Agent allow all
request_header_access Cookie allow all
request_header_access All deny all
shutdown_lifetime 3 seconds
EOF
</pre>

proceed with creating the ‘/etc/squid/passwd’ file and adding your user by executing:
# htpasswd -c /etc/squid/passwd your_user
(note that you need to omit the ‘-c’ switch when adding another user to the file)

then do a <code># squid -z</code> to create the cache direcory.
Finally, restart your squid server and check if it’s actually listening using:
# /etc/init.d/squid restart
# netstat -tunlp | grep 2222
tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 482/(squid)
if you like it to start on your system’s start-up, then you can execute:
# rc-update add squid default
To test it, for example I use Opera for this so I just go to ‘Settings → Preferences → Advanced → Network → Proxy Servers’ and set the browser to use the proxy server we just created.

[[Category:HOWTO]]

ZFS rootfs over encrypted container

2013-01-03T08:08:54Z

Golodhrim:

This tutorial will show you how to install Funtoo on ZFS (rootfs) over an encrypted container.

This tutorial is meant to be an "overlay" over the [[Funtoo_Linux_Installation|Regular Funtoo Installation]]. Follow the normal installation and only use this guide for steps 2, 3, and 8.

{{fancyimportant|'''Since ZFS was really designed for 64 bit systems, we are only recommending and supporting 64 bit platforms and installations. We will not be supporting 32 bit platforms'''!}}

== Setting up your environment ==
In order for us to install Funtoo on ZFS, you will need an environment that provides the ZFS userspace tools. We will be downloading two things, System Rescue CD 3.1.2, and the ZFS SRM (System Rescue Module). This is just a file that when combined with System Rescue CD, gives you ZFS functionality.

[https://sourceforge.net/projects/systemrescuecd/files/sysresccd-x86/3.1.2/systemrescuecd-x86-3.1.2.iso/download Download System Rescue CD 3.1.2]

[http://jonathanvasquez.com/files/sysresccd/ Download the ZFS System Rescue Module]

<pre>
Name: SystemRescueCd-x86-3.1.2 (350 MiB)
Release Date: 2012-12-05

md5sum 3c1ddfe5f26bb2f979a2ed9dfb504ee3
sha1sum 217cf7a81380d894b2433c59451787c16bc0af2f
sha256sum ec0a995875e64ff9816a043737e5cbbb689b7f596b48679116f0a779f3dce673
</pre>

Once you place the ISO on your USB flash drive, extract the modules from the tarball, and place the .srm and .md5 at the root of your USB filesystem. Further instructions can be found [[Creating_System_Rescue_CD_Modules#Using_the_prebuilt_srm|here]].

We will now start to partition the system. Open up a terminal, and type in the following (We will assume it's a fresh drive for simplicity).

== Creating partitions ==
We will be creating two partitions, /boot, and the remaining disk space will be for ZFS.

(All commands will be ran as root).

=== fdisk (MBR Style) ===
'''Create Partition 1''' (boot):

<console>
Command: ##i##n ↵
Partition type: ##i##↵
Partition number: ##i##↵
First sector: ##i##↵
Last sector: ##i##+250M ↵
</console>

'''Create Partition 2''' (ZFS over encrypted container):
<console>
Command: ##i##n ↵
Partition type: ##i##↵
Partition number: ##i##↵
First sector: ##i##↵
Last sector: ##i##↵
Command: ##i##t ↵
Partition number: ##i##2 ↵
Hex code (type L to list codes): ##i##bf ↵
Command: ##i##p ↵
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x3e954df7
Device Boot Start End Blocks Id System
/dev/sda1 2048 514047 256000 83 Linux
/dev/sda2 514048 1953525167 976505560 bf Solaris
</console>

=== gdisk (GPT Style) ===
'''Create Partition 1''' (boot):
<console>
Command: ##i##n ↵
Partition Number: ##i##↵
First sector: ##i##↵
Last sector: ##i##+250M ↵
Hex Code: ##i##↵
</console>

'''Create Partition 2''' (BIOS Boot Partition):
<console>
Command: ##i##n ↵
Partition Number: ##i##↵
First sector: ##i##↵
Last sector: ##i##+32M ↵
Hex Code: ##i##EF02 ↵
</console>

{{fancyimportant|Only make the above BIOS Boot Partition if you are using GRUB 2 on GPT. If you are using the extlinux bootloader, this partition is not necessary. The below instructions continue as if you did not create this partition and assumes you are using extlinux as the bootloader.}}

'''Create Partition 2(/3)''' (ZFS over encrypted container):
<console>
Command: ##i##n ↵
Partition Number: ##i##↵
First sector: ##i##↵
Last sector: ##i##↵
Hex Code: ##i##bf01 ↵
Command: ##i##p ↵
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): C0C1E56A-B24F-492F-95DB-2E227676F228
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 514047 250.0 MiB 8300 Linux filesystem
2 514048 1953525134 931.3 GiB BF01 Solaris /usr & Mac ZFS
</console>

=== Format your boot volume ===
<console>
# ##i##mkfs.ext2 /dev/sda1
</console>

=== Create the crypto container ===
Be aware that this step will take a lot of time, 1-2 days might be possible depending on your disksize. The bs part in the next commands is important, so that you don't know about the actual disksize and the disk get's filled up to the end with data for the cryptocontainer.

<console>
# ##i##dd if=/dev/zero of=/dev/sda2 bs=100M
# ##i##dd if=/dev/urandom of=/dev/sda2 bs=100M
</console>

Next we will create the cryptocontainer in the before prepared partition and mount the container after that:

<console>
# ##i##cryptsetup -c aes-xts-plain64 luksFormat /dev/sda2
# ##i##cryptsetup luksOpen /dev/sda2 enc-root
</console>

This opens the cryptocontainer in '''/dev/mapper/enc-root''', what will from now on the device for our ZFS pool.

=== Create the zpool ===
We will first create the pool. The pool will be named `rpool` and the disk will be aligned to 4096 (using ashift=12)

<console>
# ##i##zpool create -f -o ashift=12 -o cachefile= -O compression=on -m none -R /mnt/funtoo rpool /dev/mapper/enc-root
</console>

=== Create the zfs datasets ===
We will now create some datasets. For this installation, we will create a small but future proof amount of datasets. We will have a dataset for the OS (/), and your swap. We will also show you how to create some optional datasets: /home, /var, /usr/src, and /usr/portage.

<console>
Create some empty containers for organization purposes, and make the dataset that will hold /
# ##i##zfs create -o mountpoint=none rpool/ROOT
# ##i##zfs create -o mountpoint=/ rpool/ROOT/funtoo

Optional, but recommended datasets: /home, /root
# ##i##zfs create -o mountpoint=/home rpool/HOME
# ##i##zfs create -o mountpoint=/root rpool/HOME/root

Optional datasets: /usr/src, /var
# ##i##zfs create -o mountpoint=none rpool/FUNTOO
# ##i##zfs create -o mountpoint=/usr/src rpool/FUNTOO/src
# ##i##zfs create -o mountpoint=/var rpool/FUNTOO/var
</console>

==== Creating a separate portage dataset (optional) ====
Creating a separate portage dataset could be useful if you would like to keep your portage tree, distfiles (source code files), and packages (your compiled binaries if you have FEATURES="buildpkg" enabled) in a safe place (or if you want to back up this directory up easily).

This requires a few extra steps because we can't just do a regular emerge --sync when we initially chroot. We will need to download a portage snapshot tarball and extract it into the directory.

The required steps for getting and extracting the snapshot will be shown later on in the guide once you chroot into the environment. For now just create the datasets:

<console>
# ##i##zfs create -o mountpoint=/usr/portage -o compression=off rpool/FUNTOO/portage
# ##i##zfs create -o mountpoint=/usr/portage/distfiles -o compression=off rpool/FUNTOO/distfiles
</console>

=== Create your swap dataset ===

'''Make your swap +1G greater than your RAM. An 8G machine would have 9G of RAM (This is kinda big though).'''

<console>
# ##i##zfs create -o sync=always -o primarycache=metadata -o secondarycache=none -V 9G rpool/swap
</console>

=== Format your swap dataset ===

<console>
# ##i##mkswap -f /dev/zvol/rpool/swap
# ##i##swapon /dev/zvol/rpool/swap
</console>

Alright that finishes the creation of the zpool and zfs datasets. Check to make sure everything appears fine:

<console>
# ##i##zpool status
# ##i##zfs list
</console>

Copy the zpool.cache file to your new environment.

<console>
# ##i##mkdir -p /mnt/funtoo/etc/zfs
# ##i##cp /etc/zfs/zpool.cache /mnt/funtoo/etc/zfs
You might also need to copy your zdev.conf file:
# ##i##cp /etc/zfs/zdev.conf /mnt/funtoo/etc/zfs
</console>

Make an empty mtab file

<console>
# ##i##touch /mnt/funtoo/etc/mtab
</console>

Now we will continue to install funtoo.

== Installing Funtoo ==
[[Funtoo_Linux_Installation|Download and install the Funtoo stage3 and continue installation as normal.]]

Then chroot into your new funtoo environment:

<console>
# ##i##cd /mnt/funtoo

Mount your boot drive
# ##i##mount /dev/sda1 /mnt/funtoo/boot

Bind the kernel related directories
# ##i##for i in proc dev sys; do mount --bind /$i ./$i; done

Copy network settings
# ##i##cp /etc/resolv.conf etc/

chroot into your new funtoo environment
# ##i##env -i HOME=/root TERM=$TERM chroot . bash -l
</console>

=== Syncing your portage tree ===
==== If you didn't create a separate portage dataset, then just sync your portage tree as normal. ====

<console>
# ##i##emerge --sync
</console>

==== If you did create a separate portage dataset, let's now get the portage snapshot set up. ====

<console>
Change into your /usr directory
# ##i##cd /usr

Download and extract the portage snapshot
# ##i##wget http://ftp.osuosl.org/pub/funtoo/funtoo-current/snapshots/portage-latest.tar.xz
# ##i##tar xf portage-latest.tar.xz

Change into your portage directory and checkout the funtoo branch
# ##i##cd portage
# ##i##git checkout funtoo.org

Now sync your portage tree
# ##i##emerge --sync
</console>

== Kernel Configuration ==
Tested with kernel 2.6.32, 3.2.34, 3.6.9, 3.7.1.

When you get up to the kernel, make sure that you disable the CFQ scheduler, and turnon No-op (It's the default one once you disable all schedulers). The reason for this is because ZFS has itsown scheduler and the CFQ one conflicts with it.

Go to your kernel config, and make sure you have the following: (there should be a /usr/src/linux symlink as well)
<pre>
ZLIB_INFLATE/DEFLATE must be compiled into the kernel (not as a module).
> ZLIB_INFLATE [=y], ZLIB_DEFLATE [=y]

General setup --->
> [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
> () Initramfs source file(s)
[*] Enable loadable module support --->
[*] Module unloadingEnable the block layer --->
IO Schedulers --->
< > Deadline I/O scheduler
< > CFQ I/O schedulerDefault I/O scheduler (No-op)
Device Drivers --->
> Generic Driver Options --->
>> [*] Maintain a devtmpfs filesystem to mount at /dev
>> [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs

Cryptographic API --->
> <*> XTS support
> -*- AES cipher algorithms

* All other drivers required to see your PATA/SATA drives must be compiled in.
</pre>

Continue and compile/install your kernel:

<console>
# ##i##make bzImage
# ##i##make modules_install
# ##i##cp arch/x86_64/boot/bzImage /boot/bzImage-<Kernel-version>
</console>

== Installing the ZFS userspace tools ==

<console>
# ##i##emerge -av zfs
</console>

Check to make sure that the zfs tools are working, the zpool.cache file that you copied before should be displayed.

<console>
# ##i##zpool status
# ##i##zfs list
</console>

If everything worked, continue.

== Bliss Initramfs Creator ==
Make sure you compile sys-apps/busybox and sys-fs/cryptsetup with the static flag.

<console>
# ##i##echo "sys-apps/busybox static" >> /etc/portage/package.use/busybox
# ##i##echo "sys-fs/cryptsetup static" >> /etc/portage/package.use/cryptsetup
# ##i##echo "sys-libs/e2fsprogs-libs static-libs" >> /etc/portage/package.use/e2fsprogs-libs
# ##i##echo "dev-libs/popt static-libs" >> /etc/portage/package.use/popt
# ##i##echo "sys-apps/util-linux static-libs" >> /etc/portage/package.use/util-linux
# ##i##emerge -avt sys-apps/busybox sys-fs/cryptsetup
</console>

Clone my creator which is located at: git://github.com/fearedbliss/Bliss-Initramfs-Creator.git

<console>
# ##i##git clone git://github.com/fearedbliss/Bliss-Initramfs-Creator.git
# ##i##cd Bliss-Initramfs-Creator
</console>

Then run the script as root, and place the initrd into /boot

<console>
# ##i##./createInit
Choose Option 2 ZFS+LUKS
# ##i##mv initrd-<kernel_name>.img /boot
</console>

'''<kernel_name>''' is the name of what you selected in the initramfs creator, and the name of the outputted file.

Once you do this just go to your bootloader config, and add it in there.

Example:
kernel name is: bzImage-3.7.1-ALL
initramfs name is: initrd-3.7.1-ALL.img
pool root is: rpool/ROOT/funtoo
encrypted root is: /dev/sda2

== Installing Extlinux ==
To install extlinux first merge syslinux

<console>
# ##i##emerge -avt syslinux
</console>

next prepare your /boot folder

<console>
# ##i##install -d /boot/extlinux
# ##i##extlinux --install /boot/extlinux
# ##i##cd /boot
# ##i##ln -s . boot
</console>

Finally install Extlinux for your Boot Record

=== MBR ===
<console>
# ##i##dd bs=440 conv=notrunc count=1 if=/usr/share/syslinux/mbr.bin of=/dev/sda
# ##i##cp /usr/share/syslinux/menu.c32 /boot/extlinux/
# ##i##touch /boot/extlinux/extlinux.conf
</console>

=== GPT ===
<console>
# ##i##sgdisk /dev/sda --attributes=1:set:2
# ##i##sgdisk /dev/sda --attributes=1:show
1:2:1 (legacy BIOS bootable)
# ##i##dd bs=440 conv=notrunc count=1 if=/usr/share/syslinux/gptmbr.bin of=/dev/sda
# ##i##cp /usr/share/syslinux/menu.c32 /boot/extlinux/
# ##i##touch /boot/extlinux/extlinux.conf
</console>

=== Config Extlinux ===
Open '''/boot/extlinux/extlinux.conf''' with your favorite editor and add the following to it:

<console>
TIMEOUT 30
UI menu.c32

MENU TITLE Funtoo Boot Menu
MENU COLOR title 1;37;40
MENU COLOR border 30;40
MENU COLOR unsel 37;40

LABEL funtoo bzImage-<Kernel-Version>
MENU LABEL Funtoo Linux bzImage-<Kernel-Version>
KERNEL /bzImage-<Kernel-Version>
INITRD /initrd-<Kernel-Version>.img
APPEND enc_root=/dev/sda2 pool_root=rpool/ROOT/funtoo
</console>

== Final configuration ==
=== Add the zfs tools to openrc ===
<console>
# ##i##rc-update add zfs boot
# ##i##rc-update add zfs-shutdown shutdown
</console>

=== Add filesystems to /etc/fstab ===
<console>
# ##i##nano /etc/fstab
# <fs> <mountpoint> <type> <opts> <dump/pass>
/dev/sda1 /boot ext2 defaults 1 2
/dev/zvol/rpool/swap none swap sw 0 0
</console>

=== Clean up and reboot ===
We are almost done, we are just going to clean up and unmount whatever we mounted and get out.
<console>
Delete the stage3/portage tarballs you downloaded earlier so they don't take up space.
# ##i##cd /
# ##i##rm stage3-latest.tar.xz
# ##i##rm /usr/portage-latest.tar.xz

Set your root password
# ##i##passwd
>> Enter your password, you won't see what you are writing (for security reasons), but it is there!

Get out of the chroot environment
# ##i##exit

Unmount all the kernel filesystem stuff and boot
# ##i##cd /mnt/funtoo
# ##i##umount proc dev sys boot

Turn off the swap
# ##i##swapoff /dev/zvol/rpool/swap

Export the zpool
# ##i##cd /
# ##i##zpool export -f rpool

Reboot
# ##i##reboot
</console>

and that should be enough to get your system to boot on ZFS.

== Extra: After reboot ==
After you restart your machine and your inside your desktop, continue to set up anything you need in terms of /etc configurations. Once you have everything the way you like it, take a snapshot of your system. You will be using this snapshot to revert back to this state if anything ever happens to your system down the road. The snapshots are cheap, and almost instant. To take the snapshot of your rootfs, type the following:

<console>
# ##i##zfs snapshot rpool/ROOT/funtoo@install
</console>

To see if your snapshot was taken, type:

<console>
# ##i##zfs list -t snapshot
</console>

If your machine ever fails and you need to get back to this state, just type:

<console>
# ##i##zfs rollback rpool/ROOT/funtoo@install
</console>

Enjoy your new install on ZFS :)

== Getting back into your ZFS pool in case of emergency ==
If you ever need to get back into your ZFS pool in case of an emergency (missing rebuild of modules, unable to boot, etc) reboot your box with the System Rescue USB you created earlier, then issue the following commands:

<console>
# ##i##depmod
# ##i##cryptsetup luksOpen /dev/sda2 enc-root
# ##i##zpool import -f -o cachefile= -R /mnt/funtoo rpool
</console>

Now you should be able to mount the system like we did earlier in this Guide [[ZFS_rootfs_over_encrypted_container#Installing_Funtoo|(chroot instructions)]], fix your problem and enjoy.

[[Category:HOWTO]]
[[Category:Filesystems]]

[[Category:Featured]]

Developer Guide

2012-12-26T05:34:35Z

Drobbins:

This page is intended to be a developer guide for Funtoo Linux.

== Learn About Ebuilds ==

* [[Portage Variables]] -- learn about all those variables inside an ebuild, and in <tt>make.conf</tt>.
* [[Forking An Ebuild]] -- explains how to take an ebuild from Gentoo and fork it, so you can make local changes.
* [[Ebuild Functions]] -- <tt>src_unpack</tt>, <tt>src_compile</tt> -- these are ebuild functions. There are others. See all of them and learn how they work.

== Funtoo Internals ==

* [[Multiple ABI Support]] -- learn how the <tt>gcc</tt> wrapper and <tt>multilib.eclass</tt> work in Gentoo and Funtoo.

== Portage ==

* [[Portage (Funtoo)]] -- learn about Funtoo changes to Portage (needs updating).
* [[Portage Dynamic Slot]] - dynamic SLOT functionality now in Portage.

== Metro ==

* [[Metro Quick Start Tutorial]] -- learn how to use Metro, our automated build tool.
* [[Metro]] - a full index of Metro-related documentation.

== Working With Git ==

Also check out:

* [[Git Merging Guide]]

Learning how to help squash out bugs can be a difficult thing to do, especially since sometimes JIRA looks a little overwhelming and confusing. A thank you to Daniel for making some videos (see below) on explaining this better, but there were a couple things left out. So I will take you through that. (With picture reference).

The first thing you're going to want to do is make an account, which is simple as clicking on the 'Log in' button on the top right, then clicking 'Sign up'.
[[File:Signupjira.png|720px|center]]

After you've made your account, the best way to watch bugs is to click on the 'Agile' drop-down menu, and choose 'Classic'.
[[File:Agileclassic.png|720px|center]]

Now, we're going to want to change a couple things even with this. By default, the 'Classic' mode takes you to 'Classic Planning Board', you want to change this to 'Classic Task Board'. This makes things much easier to read.
I also recommend going to the '''Views''' eyeball icon to the right and selecting the '''List''' issue view, and the '''Compact (Kanban)''' task board mode. This will give you a top-level overview of all our bugs and their statuses, and JIRA will remember your view preferences the next time you log in.

[[File:Classicview.png|720px|center]]

After that, we're almost ready to rock and roll. We need to also make sure that you're not set to any version or we'll only see a few bugs. So in case it says '1.1' or '1.0' change it to 'Unscheduled'.
[[File:Jiraversion.png|720px|center]]

And after all that, you can view and look at bugs that are in queue, To-do, or testing, which Daniel's videos are very great at explaining. Thanks for helping Funtoo Linux better and better.

<center>{{#widget:YouTube|id=JCg5DWjy6Ro|width=720}}

{{#widget:YouTube|id=tuFE9ZgVOpY|width=720}}

[[Category:Development]]

ZFS Install Guide

2012-12-24T23:44:25Z

Touri: /* genkernel */

== Introduction ==

This tutorial will show you how to install Funtoo on ZFS (rootfs). This tutorial is meant to be an "overlay" over the [[Funtoo_Linux_Installation|Regular Funtoo Installation]]. Follow the normal installation and only use this guide for steps 2, 3, and 8.

=== Introduction to ZFS ===

Since ZFS is a new technology for Linux, it can be helpful to understand some of its benefits, particularly in comparison to BTRFS, another popular next-generation Linux filesystem:

* On Linux, the ZFS code can be updated independently of the kernel to obtain the latest fixes. btrfs is exclusive to Linux and you need to build the latest kernel sources to get the latest fixes.

* ZFS is supported on multiple platforms. The platforms with the best support are Solaris, FreeBSD and Linux. Other platforms with varying degrees of support are NetBSD, Mac OS X and Windows. btrfs is exclusive to Linux.

* ZFS has the Adaptive Replacement Cache replacement algorithm while btrfs uses the linux kernel's Last Recently Used replacement algorithm. The former often has an overwhelmingly superior hit rate, which means fewer disk accesses.

* ZFS has the ZFS Intent Log and SLOG devices, which accelerates small synchronous write performance.

* ZFS handles internal fragmentation gracefully, such that you can fill it until 100%. Internal fragmentation in btrfs can make btrfs think it is full at 10%. Btrfs has no automatic rebalancing code, so it requires a manual rebalance to correct it.

* ZFS has raidz, which is like RAID 5/6 (or a hypothetical RAID 7 that supports 3 parity disks), except it does not suffer from the RAID write hole issue thanks to its use of CoW and a variable stripe size. btrfs gained integrated RAID 5/6 functionality in Linux 3.9. However, its implementation uses a stripe cache that can only partially mitigate the effect of the RAID write hole.

* ZFS send/receive implementation supports incremental update when doing backups. btrfs' send/receive implementation requires sending the entire snapshot.

* ZFS supports data deduplication, which is a memory hog and only works well for specialized workloads. btrfs has no equivalent.

* ZFS datasets have a hierarchical namespace while btrfs subvolumes have a flat namespace.

* ZFS has the ability to create virtual block devices called zvols in its namespace. btrfs has no equivalent and must rely on the loop device for this functionality, which is cumbersome.

The only area where btrfs is ahead of ZFS is in the area of small file
efficiency. btrfs supports a feature called block suballocation, which
enables it to store small files far more efficiently than ZFS. It is
possible to use another filesystem (e.g. reiserfs) on top of a ZFS zvol
to obtain similar benefits (with arguably better data integrity) when
dealing with many small files (e.g. the portage tree).

=== Disclaimers ===

{{fancywarning|This guide is a work in progress. Expect some quirks.}}
{{fancyimportant|'''Since ZFS was really designed for 64 bit systems, we are only recommending and supporting 64 bit platforms and installations. We will not be supporting 32 bit platforms'''!}}

== Video Tutorial ==

As a companion to the install instructions below, a YouTube video ZFS install tutorial is now available:

{{#widget:YouTube|id=MXyBamArues|width=640|height=360}}

== Setting up your environment ==
In order for us to install Funtoo on ZFS, you will need an environment that provides the ZFS tools. We will be downloading two things:

# System Rescue CD,
# ZFS System Rescue Module (SRM)

This is just a file that when combined with System Rescue CD, gives you those tools.
<pre>
Name: SystemRescueCd-x86-3.5.0 (390 MiB)
Release Date: 2013-03-25
md5sum 48552b9e905872bd5061eb112b73ea20
</pre>

Funtoo now has mirrored copies of System Rescue CD and the ZFS SRM at the links below.

[http://ftp.osuosl.org/pub/funtoo/distfiles/sysrescuecd/systemrescuecd-x86-3.5.0.iso Download System Rescue CD 3.5.0]<br />
[http://ftp.osuosl.org/pub/funtoo/distfiles/sysrescuecd/zfs-3.4.37-std350-amd64_0.6.1.tar.xz Download the ZFS System Rescue Module]

[[Creating_System_Rescue_CD_ZFS_Modules|Follow the instructions here to download and place the srm into your flash drive]].

== Creating partitions ==
There are two ways to partition your disk: You can use your entire drive and let ZFS automatically partition it for you, or you can do it manually.

We will be showing you how to partition it '''manually''' because if you partition it manually you get to create your own layout, you get to have your own separate /boot partition (Which is nice since not every bootloader supports booting from ZFS pools), and you get to boot into RAID10, RAID5 (RAIDZ) pools and any other layouts due to you having a separate /boot partition.

==== fdisk (MBR Style) ====

'''A Fresh Start''':

First lets make sure that the disk is completely wiped from any previous disk labels and partitions.
We will also assume that <tt>/dev/sda</tt> is the target drive.<br />

<console>
Command (m for help): ##i##o ↵
Building a new DOS disklabel with disk identifier 0xbeead864.
</console>

{{fancywarning|This is a destructive operation. Make sure you really don't want anything on this disk.}}

Now that we have a clean drive, we will create the new layout.

'''Create Partition 1''' (boot):
<console>
Command: ##i##n ↵
Partition type: ##i##↵
Partition number: ##i##↵
First sector: ##i##↵
Last sector: ##i##+250M ↵
</console>

'''Create Partition 2''' (ZFS):
<console>
Command: ##i##n ↵
Partition type: ##i##↵
Partition number: ##i##↵
First sector: ##i##↵
Last sector: ##i##↵

Command: ##i##t ↵
Partition number: ##i##2 ↵
Hex code: ##i##bf ↵

Command: ##i##p ↵

Device Boot Start End Blocks Id System
/dev/sda1 2048 514047 256000 83 Linux
/dev/sda2 514048 1953525167 976505560 bf Solaris
</console>

==== gdisk (GPT Style) ====

'''A Fresh Start''':

First lets make sure that the disk is completely wiped from any previous disk labels and partitions.
We will also assume that <tt>/dev/sda</tt> is the target drive.<br />

<console>
# ##i##gdisk /dev/sda

Command: ##i##x ↵
Expert command: ##i##z ↵
About to wipe out GPT on /dev/sda. Proceed?: ##i##y ↵
GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.
Blank out MBR?: ##i##y ↵
</console>

{{fancywarning|This is a destructive operation. Make sure you really don't want anything on this disk.}}

Now that we have a clean drive, we will create the new layout.

'''Create Partition 1''' (boot):
<console>
Command: ##i##n ↵
Partition Number: ##i##↵
First sector: ##i##↵
Last sector: ##i##+250M ↵
Hex Code: ##i##↵
</console>

'''Create Partition 2''' (BIOS Boot Partition):
<console>Command: ##i##n ↵
Partition Number: ##i##↵
First sector: ##i##↵
Last sector: ##i##+32M ↵
Hex Code: ##i##EF02 ↵
</console>
{{fancyimportant|Only make the above BIOS Boot Partition if you are using GRUB 2 on GPT. If you are using the extlinux bootloader, this partition is not necessary.}}

'''Create Partition 3''' (ZFS):
<console>Command: ##i##n ↵
Partition Number: ##i##↵
First sector: ##i##↵
Last sector: ##i##↵
Hex Code: ##i##bf00 ↵

Command: ##i##p ↵

Number Start (sector) End (sector) Size Code Name
1 2048 514047 250.0 MiB 8300 Linux filesystem
2 514048 579583 32.0 MiB EF02 BIOS boot partition
3 579584 1953525134 931.2 GiB BF00 Solaris root

Command: ##i##w ↵
</console>

=== Format your boot volume ===
Format your separate /boot partition:
<console># ##i##mkfs.ext2 /dev/sda1</console>

=== Create the zpool ===
We will first create the pool. The pool will be named `rpool` and the disk will be aligned to 4096 (using ashift=12)

<console># ##i##zpool create -f -o ashift=12 -o cachefile= -O compression=on -m none -R /mnt/funtoo rpool /dev/sda2</console>
{{fancyimportant|If you followed the manual GPT partitioning instructions, you should change /dev/sda2 to /dev/sda3.}}{{fancynote|If you have a previous pool that you would like to import, you can do a: '''zpool import -f -R /mnt/funtoo <pool_name>'''}}

=== Create the zfs datasets ===
We will now create some datasets. For this installation, we will create a small but future proof amount of datasets. We will have a dataset for the OS (/), and your swap. We will also show you how to create some optional datasets: /home, /var, /usr/src, and /usr/portage.

<console>
Create some empty containers for organization purposes, and make the dataset that will hold /
# ##i##zfs create -o mountpoint=none rpool/ROOT
# ##i##zfs create -o mountpoint=/ rpool/ROOT/funtoo

Optional, but recommended datasets: /home, /root
# ##i##zfs create -o mountpoint=/home rpool/HOME
# ##i##zfs create -o mountpoint=/root rpool/HOME/root

Optional datasets: /usr/src, /var
# ##i##zfs create -o mountpoint=none rpool/FUNTOO
# ##i##zfs create -o mountpoint=/usr/src rpool/FUNTOO/src
# ##i##zfs create -o mountpoint=/var rpool/FUNTOO/var
</console>

==== Creating a separate portage dataset (optional) ====
Creating a separate portage dataset could be useful if you would like to keep your portage tree, distfiles (source code files), and packages (your compiled binaries if you have FEATURES="buildpkg" enabled) in a safe place (or if you want to back up this directory up easily). This requires a few extra steps because we can't just do a regular emerge --sync when we initially chroot. We will need to download a portage snapshot tarball and extract it into the directory. The required steps for getting and extracting the snapshot will be shown later on in the guide once you chroot into the environment.

For now just create the datasets:
<console>
# ##i##zfs create -o mountpoint=/usr/portage -o compression=off rpool/FUNTOO/portage
# ##i##zfs create -o mountpoint=/usr/portage/distfiles -o compression=off rpool/FUNTOO/distfiles
</console>

=== Create your swap zvol ===
'''Make your swap +1G greater than your RAM. An 8G machine would have 9G of SWAP (This is kinda big though).'''
<console>
# ##i##zfs create -o sync=always -o primarycache=metadata -o secondarycache=none -o volblocksize=4K -V 9G rpool/swap
</console>

=== Format your swap zvol ===
<console>
# ##i##mkswap -f /dev/zvol/rpool/swap
# ##i##swapon /dev/zvol/rpool/swap
</console>

=== Last minute checks and touches ===
Check to make sure everything appears fine:
<console>
# ##i##zpool status
# ##i##zfs list
</console>

Copy the '''zpool.cache''' file to your new environment.
<console>
# ##i##mkdir -p /mnt/funtoo/etc/zfs
# ##i##cp /etc/zfs/zpool.cache /mnt/funtoo/etc/zfs
</console>

Make an empty mtab file
<console># ##i##touch /mnt/funtoo/etc/mtab</console>

Now we will continue to install funtoo.

== Installing Funtoo ==
[[Funtoo_Linux_Installation|Download and install the Funtoo stage3 and continue installation as normal.]]

Then chroot into your new funtoo environment:
<console>
# ##i##cd /mnt/funtoo

Mount your boot drive
# ##i##mount /dev/sda1 /mnt/funtoo/boot

Bind the kernel related directories
# ##i##mount --rbind /proc proc
# ##i##mount --rbind /dev dev
# ##i##mount --rbind /sys sys

Copy network settings
# ##i##cp /etc/resolv.conf etc/
chroot into your new funtoo environment
# ##i##env -i HOME=/root TERM=$TERM chroot . /bin/bash -l
</console>

=== Syncing your portage tree ===
==== If you didn't create a separate portage dataset, then just sync your portage tree as normal. ====
<console># ##i##emerge --sync</console>

==== If you did create a separate portage dataset, let's now get the portage snapshot set up. ====
<console>
Change into your /usr directory
# ##i##cd /usr

Download and extract the portage snapshot
# ##i##wget http://ftp.osuosl.org/pub/funtoo/funtoo-current/snapshots/portage-latest.tar.xz
# ##i##tar xf portage-latest.tar.xz

Change into your portage directory and checkout the funtoo branch
# ##i##cd portage
# ##i##git checkout funtoo.org

Now sync your portage tree
# ##i##emerge --sync
</console>

== Kernel Configuration ==
{{fancynote|The below configurations are the requirements for "Bliss Initramfs Creator". Some of these might not be needed for genkernel.}}

Tested with kernel 2.6.32, 3.2.34, 3.6.X, 3.7.X, 3.8.X.

When you get up to the kernel, make sure that you disable the CFQ scheduler, and turn on No-op (It's the default one once you disable all schedulers). The reason for this is because ZFS has its own scheduler and the CFQ one conflicts with it. Go to your kernel config, and make sure you have the following: (there should be a /usr/src/linux symlink as well)

<pre>ZLIB_INFLATE/DEFLATE must be compiled into the kernel (not as a module).
> ZLIB_INFLATE [=y], ZLIB_DEFLATE [=y]

General setup --->
> [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
> () Initramfs source file(s)

[*] Enable loadable module support --->
[*] Module unloading

Device Drivers --->
> Generic Driver Options --->
>> [*] Maintain a devtmpfs filesystem to mount at /dev

Cryptographic API --->
<*> Deflate compression algorithm
<*> Zlib compression algorithm

* All other drivers required to see your PATA/SATA drives must be compiled in.</pre>

Continue and compile/install your kernel:
<console>
# ##i##make bzImage modules
# ##i##make install
# ##i##make modules_install
</console>

== Installing the ZFS userspace tools ==

<console># ##i##emerge -av zfs</console>

Check to make sure that the zfs tools are working, the zpool.cache file that you copied before should be displayed.<console>
# ##i##zpool status
# ##i##zfs list
</console>

If everything worked, continue.

== Install the bootloader ==

=== GRUB 2 ===
Before you do this, make sure this checklist is followed:
* Installed kernel and kernel modules
* Installed zfs package from the tree
* /dev, /proc, /sys are mounted in the chroot environment

Once all this is checked, let's install grub2. First we need to enable the "libzfs" use flag so zfs support is compiled for grub2.

<console># ##i##echo "sys-boot/grub libzfs" >> /etc/portage/package.use</console>

Then we will compile grub2:
{{fancyimportant|GRUB should be _at least_ version 2.0.0 since 2.0.0 added zfs support. 1.99,.98 will not work.}}
<console># ##i##emerge -av grub</console>

Once this is done, you can check that grub is version 2.00 by doing the following command:
<console>
# ##i##grub-install --version
grub-install (GRUB) 2.00
</console>

Now try to install grub2:
<console># ##i##grub-install --no-floppy /dev/sda</console>

You should receive the following message
<console>Installation finished. No error reported.</console>

If not, then go back to the above checklist.
=== Extlinux ===
There are four things we need to do for extlinux:

# Install extlinux bootloader
# Write the .bin to the front of the target disk
# Toggle BIOS partition flag
# Write a extlinux configuration file

First emerge extlinux:
<console># ##i##emerge -av syslinux</console>

Then create a /boot/extlinux directory:
<console>
# ##i##cd /boot
# ##i##mkdir /boot/extlinux
</console>

Change into the extlinux dir and install the bootloader:
<console>
# ##i##cd /boot/extlinux
# ##i##extlinux --install .
</console>

==== MBR ====
<console>
# ##i##fdisk /dev/sda

Command: ##i##a ↵
Partition number: ##i##1 ↵
Command: ##i##w ↵
</console>

Printing the <tt>fdisk</tt> partition layout should show a star next to <tt>/dev/sda1</tt>:
<console>/dev/sda * 2048 514047 256000 83 Linux</console>

Flash the .bin to the front of the disk:
<console># ##i##dd conv=notrunc bs=440 count=1 if=/usr/share/syslinux/mbr.bin of=/dev/sda</console>

=== GPT ===
<console># ##i##sgdisk /dev/sda --attributes=1:set:2</console>

Flash the .bin to the front of the disk:
<console># ##i##dd conv=notrunc bs=440 count=1 if=/usr/share/syslinux/gptmbr.bin of=/dev/sda</console>

We will write the extlinux/grub configuration file in the next section.

=== Create a boot symlink ===
We will create a boot symlink so that we can have "consistent" boot configurations without any errors.

<console>
# ##i##cd /boot
# ##i##ln -s . boot
</console>

You should now have a symlink called 'boot' inside /boot that points to /boot :).

== Create the initramfs ==
There are two ways to do this, you can use genkernel, or you can use my bliss initramfs creator. I will show you both.

=== genkernel ===
<console>
# ##i##emerge -av sys-kernel/genkernel
# ##i##genkernel --zfs initramfs
</console>

<pre>
Example: kernel name is: vmlinuz-3.8.5-ALL
initramfs name is: initramfs-genkernel-x86_64-3.8.5-ALL
/boot partition is: /dev/sda1 (on GPT)
pool name is: rpool
</pre>

'''genkernel entries need verification'''
'''grub.cfg''':
<console>
set timeout=3
set default=0

# Funtoo
menuentry "Funtoo - 3.8.5" {
insmod part_gpt
insmod ext2

set root=(hd0,gpt1)

linux /boot/vmlinuz-3.8.5-ALL real_root=ZFS=rpool/ROOT/funtoo dozfs=force
initrd /boot/initramfs-genkernel-x86_64-3.8.5-ALL
}
</console>

If you followed the way to set up a separate partition to boot of (/dev/sda1 in this guid) you need to modify the entries in your grub.cfg, since grub will now not search inside zfs:
<console>
set timeout=3
set default=0

# Funtoo
menuentry "Funtoo - 3.8.5" {
insmod zfs
linux /vmlinuz-3.8.5-ALL root=rpool/ROOT/funtoo quiet
initrd /initramfs-genkernel-x86_64-3.8.5-ALL
}
</console>

'''extlinux.conf''':
<console>
LABEL funtoo
MENU LABEL Funtoo 3.8.5-ALL
KERNEL /boot/vmlinuz-3.8.5-ALL
INITRD /boot/initramfs-genkernel-x86_64-3.8.5-ALL
APPEND real_root=ZFS=rpool/ROOT/funtoo dozfs=force
</console>

=== Bliss Initramfs Creator ===
Clone my creator which is located at: git://github.com/fearedbliss/Bliss-Initramfs-Creator.git

<console># ##i##git clone git://github.com/fearedbliss/Bliss-Initramfs-Creator.git</console>

Then go into this new directory, run the script as root, and place it into /boot:
<console># ##i##cd Bliss-Initramfs-Creator
# ##i##./createInit
# ##i##mv initrd-<kernel_name>.img /boot
</console>

'''<kernel_name>''' is the name of what you selected in the initramfs creator, and the name of the outputted file. Once you do this just go to your bootloader config, and add it in there.

<pre>
Example: Kernel name is: vmlinuz-3.8.5-ALL
initramfs name is: initrd-3.8.5-ALL.img
/boot partition is: /dev/sda1 (on GPT)
Pool root is: rpool/ROOT/funtoo
</pre>

'''grub.cfg''':
<console>
set timeout=3
set default=0

# Funtoo
menuentry "Funtoo - 3.8.5" {
insmod part_gpt
insmod ext2

set root=(hd0,gpt1)

linux /boot/vmlinuz-3.8.5-ALL root=rpool/ROOT/funtoo quiet
initrd /boot/initrd-3.8.5-ALL.img
}
</console>

'''extlinux.conf:'''
<console>
LABEL funtoo
MENU LABEL Funtoo 3.8.5-ALL
KERNEL /boot/vmlinuz-3.8.5-ALL
INITRD /boot/initrd-3.8.5-ALL.img
APPEND root=rpool/ROOT/funtoo quiet
</console>

== Final configuration ==
=== Add the zfs tools to openrc ===
<console># ##i##rc-update add zfs boot</console>

=== Add filesystems to /etc/fstab ===
<console>
# ##i##nano /etc/fstab

# <fs> <mountpoint> <type> <opts> <dump/pass>
# Do not add the /boot line below if you are using whole-disk zfs
/dev/sda1 /boot ext2 defaults 0 2
/dev/zvol/rpool/swap none swap sw 0 0
</console>

=== Clean up and reboot ===
We are almost done, we are just going to clean up, '''set our root password''', and unmount whatever we mounted and get out.

<console>
Delete the stage3/portage tarballs you downloaded earlier so they don't take up space.
# ##i##cd /
# ##i##rm stage3-latest.tar.xz
# ##i##rm /usr/portage-latest.tar.xz

Set your root password
# ##i##passwd
>> Enter your password, you won't see what you are writing (for security reasons), but it is there!

Get out of the chroot environment
# ##i##exit

Unmount all the kernel filesystem stuff and boot (if you have a separate /boot)
# ##i##cd /mnt/funtoo
# ##i##umount -l proc dev sys boot

Turn off the swap
# ##i##swapoff /dev/zvol/rpool/swap

Export the zpool
# ##i##cd /
# ##i##zpool export -f rpool

Reboot
# ##i##reboot
</console>

{{fancyimportant|'''Don't forget to set your root password as stated above before exiting chroot and rebooting. If you don't set the root password, you won't be able to log into your new system.'''}}

and that should be enough to get your system to boot on ZFS.

== Extra: After reboot ==
After you restart your machine and your inside your desktop, continue to set up anything you need in terms of /etc configurations. Once you have everything the way you like it, take a snapshot of your system. You will be using this snapshot to revert back to this state if anything ever happens to your system down the road. The snapshots are cheap, and almost instant.

To take the snapshot of your rootfs, type the following:
<console># ##i##zfs snapshot rpool/ROOT/funtoo@install</console>

To see if your snapshot was taken, type:
<console># ##i##zfs list -t snapshot</console>

If your machine ever fails and you need to get back to this state, just type:
<console># ##i##zfs rollback rpool/ROOT/funtoo@install</console>

=== Recovery Environment ===
On ZFS it is extremely easy to create a recovery environment using an already working snapshot. So that's what we will be doing. Create a clone of the @install snapshot which you will use for recovery purposes. If something happens to your main install, you can boot into this clone and fix the main one. One of the differences (maybe the only difference) between a clone and a snapshot is that a clone is rewritable while a snapshot is only read-only.

<console># ##i##zfs clone rpool/ROOT/funtoo@install rpool/ROOT/recovery</console>

==== Add the clone to your grub.cfg ====

<console>
set timeout=3
set default=0

# Funtoo Recovery
menuentry "Funtoo Recovery - 3.7.3" {
insmod zfs
linux /ROOT/funtoo/@/boot/vmlinuz-3.7.3-ALL root=rpool/ROOT/recovery quiet
initrd /ROOT/funtoo/@/boot/initrd-3.7.3-ALL.img
}
</console>

==== Add the clone to your extlinux.conf ====
<console>
LABEL funtoo-recovery
MENU LABEL Funtoo Recovery
KERNEL /boot/vmlinuz-3.7.3-ALL
INITRD /boot/initrd-3.7.3-ALL.img
APPEND root=rpool/ROOT/recovery
</console>

==== Things to watch out for ====
Since your recovery clone will tend to get old as you use your main system, and since your recovery and other stuff are on the same pool, we don't want the new pool stuff to be mounted when we launch recovery. We also don't want video drivers to be conflicting.
# Make sure that nvidia/nouveau stuff are blacklisted.
# Make sure that your /boot and /lib/modules for the kernel in your 'recovery' are matching.
# Disable the zfs openrc script so that nothing else gets automatically mounted. Only your rootfs.

You can do the above stuff by mounting your copy and chrooting into it.

<console>
Mount the recovery clone
# ##i##mkdir /mnt/recovery
# ##i##mount -t zfs -o zfsutil rpool/ROOT/recovery /mnt/recovery
# ##i##cd /mnt/recovery

Mount the kernel devices
# ##i##mount --rbind /proc ./proc
# ##i##mount --rbind /dev ./dev
# ##i##mount --rbind /sys ./sys

Copy zpool.cache
# ##i##cp /etc/zfs/zpool.cache etc/zfs

Chroot into the new environment
# ##i##env -i HOME=/root TERM=$TERM chroot . bash --login

Disable zfs/zfs-shutdown openrc scripts
# ##i##rc-config delete zfs boot

Blacklist nouveau/nvidia drivers
# ##i##echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
# ##i##echo "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf
</console>

Once you are done doing your changes, just umount and exit the chroot:

<console>
# ##i##cd /
# ##i##umount -l proc dev sys
# ##i##exit
</console>

==== Getting into the recovery ====
Just start your machine and pick the '''Funtoo Recovery''' option from the Boot Menu.

Enjoy your new install on ZFS :)

[[Category:HOWTO]]
[[Category:Filesystems]]
[[Category:Featured]]

__NOTOC__
__NOTITLE__