Difference between pages "ZFS as Root Filesystem" and "Package:Portage (Funtoo)"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
(remove thin-manifest branch information, add info for 2.3.8)
 
Line 1: Line 1:
== Introduction ==
{{Ebuild
|Summary=This is the official package manager/ports system for Funtoo Linux.
|CatPkg=sys-apps/portage
|Maintainer=Drobbins, Mgorny, Oleg
|Repository=Funtoo Overlay
}}
=== 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.
[http://en.wikipedia.org/wiki/Portage_(software) Portage] is the official package manager of Funtoo Linux. Daniel Robbins maintains a slightly different version from upstream Gentoo Linux, with support for mini-manifests and other features.


=== Introduction to ZFS ===
=== Portage Commands ===


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:
; [[emerge]]
: high-level dependency-based package merge/unmerge tool
; [[ebuild]]
: lower-level package build tool


* 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.
;{{c|etc-update}}
;{{c|dispatch-conf}}
:tools to manage /etc/configurations


* 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.
=== Portage Specifications ===


* 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.
The latest progress and changes related to EAPI/PMS and Portage can often be found in the Gentoo Council meeting logs, which are listed on the [https://wiki.gentoo.org/wiki/Project:Council Gentoo Council page].


* ZFS has the ZFS Intent Log and SLOG devices, which accelerates small synchronous write performance.
The latest PMS specification to be approved by the Gentoo Council is available: [http://dev.gentoo.org/~ulm/pms/5/pms.pdf eapi-5-approved-2012-09-20]. The PMS specification is an attempt to codify the inner workings of Portage, and is authored by Stephen Bennett, Christian Faulhammer, Ciaran McCreesh and Ulrich Müller as a Gentoo-hosted project.


* 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.
=== Portage Profiles ===


* 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.
Portage uses [[Portage Profiles|profiles]] to define settings for various architectures and types of Funtoo/Gentoo systems. See the [[Portage Profiles]] page for detailed information on how Portage handles profiles. Look at [[Creating_Profiles]] to learn how to create them and at [[Funtoo_1.0_Profile]] to learn about the Funtoo 1.0 profile.


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


* ZFS supports data deduplication, which is a memory hog and only works well for specialized workloads. btrfs has no equivalent.
Portage's behavior can be controlled by a number of configuration settings other variables that can be defined within the ebuild itself. In addition, a number of these variables are defined for the ebuild automatically by Portage. These variables are now documented on their own page: [[Portage Variables]].
=== Multiple ABI Support ===


* ZFS datasets have a hierarchical namespace while btrfs subvolumes have a flat namespace.
Portage contains support for multiple ABIs (Application Binary Interfaces) co-existing on the same system. This functionality has been extensively documented and has been moved to its own page: [[Multiple ABI Support]].


* 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.
=== Ebuild Functions ===


The only area where btrfs is ahead of ZFS is in the area of small file
An ebuild developer has the ability to define [[Ebuild Functions]] that define steps to perform during a particular part of the ebuild lifecycle. These steps are now documented on their own page: [[Ebuild Functions]].
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).


For a quick tour of ZFS and have a big picture of its common operations you can consult the page [[ZFS Fun]].
=== Funtoo Portage Development ===


=== Disclaimers ===
The Funtoo Core Team is currently working on a general-purpose plug-in system so that the GNU info file regeneration, news update display, and scanning of files that need updating in /etc can be pulled out of the official Portage emerge code. In addition, this plug-in system will allow other types of things to be hooked into various phases of emerge. This will allow various new plug-ins to be developed and used on systems, such as periodic security checks, etc.


{{fancywarning|This guide is a work in progress. Expect some quirks.}}
=== Portage Logs ===
{{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'''!}}
Logs of portage actions can be found at <code>/var/log/emerge.log</code> & <code>/var/log/portage/elog/summary.log-(date the log is generated)</code>
== Downloading the ISO (With ZFS) ==
In order for us to install Funtoo on ZFS, you will need an environment that already provides the ZFS tools. Therefore we will download a customized version of System Rescue CD with ZFS included.  


<pre>
=== TODO ===
Name: sysresccd-4.2.0_zfs_0.6.2.iso  (545 MB)
Release Date: 2014-02-25
md5sum 01f4e6929247d54db77ab7be4d156d85
</pre>


Add support to portage, so that when an ebuild is merged, the /var/db/pkg entry contains a list of all currently-installed versions of all ebuilds upon which that ebuild RDEPENDs. This, combined with a comprehensive set of past USE settings (may need to implement this too,) can be used to detect when an ebuild needs to be rebuilt. This could help to address issues like those in [http://bugs.gentoo.org/167662 Gentoo Bug 167662] and allow easier implementation of support for things like perl-cleaner. Currently, perl-cleaner doesn't detect that vim uses perl and moving from -ithreads to ithreads causes vim to die, so it needs to be manually rebuilt.


'''[http://ftp.osuosl.org/pub/funtoo/distfiles/sysresccd/ Download System Rescue CD with ZFS]'''<br />
Add support for portage to understand which version of a particular app is the "active" version that it was built against, and record this information in /var/db/pkg. This can help to implement perl-cleaner-like support in Portage.


== Creating a bootable USB from ISO (From a Linux Environment) ==
=== Funtoo Features/Changes ===
After you download the iso, you can do the following steps to create a bootable USB:


<console>
==== In Funtoo stable/current Portage ====
Make a temporary directory
# ##i##mkdir /tmp/loop


Mount the iso
;emerge --sync from git
# ##i##mount -o ro,loop /root/sysresccd-4.2.0_zfs_0.6.2.iso /tmp/loop
:If a git-based Portage tree is already in place, <tt>emerge --sync</tt> will run "git pull" to update the underlying Portage tree. If one is not in place, the contents of the SYNC variable will be used as the remote URI from which to clone a git tree (2.2). In addition, SYNC_USER and SYNC_UMASK (defaulting to root and 022) can be used to define the user account to use for cloning/syncing, as well as the umask to use. (2.2).


Run the usb installer
;Sed Wrapper Symlink and PATH fix
# ##i##/tmp/loop/usb_inst.sh
: The Funtoo version of Portage has replaced the BSD-only sed wrapper with a symlink. This will eventually be deprecated. The sed wrapper was a way to provide BSD systems with a "sed" command that could be used inside ebuilds that worked similarly to GNU sed. A PATH fix has been applied so that /bin/sed will be detected first anyway.
</console>


That should be all you need to do to get your flash drive working.
;mini-manifest
:Funtoo's Portage supports a special mode of operation where Manifests only contain digests for distfiles and not for files in the Portage tree. This is to eliminate redundant digests since git already provides SHA1 digests. This feature is currently enabled by adding "mini-manifest" to FEATURES in /etc/make.conf but the intention is to eventually move it to a repo-specific option (note: this has now been done, as "thin-manifest" functionality has been integrated into recent versions of Portage, and is being beta tested in Funtoo.) Funtoo provides a special "mini-manifest" tree that is smaller than the full-size Portage tree, and is intended to be used with the mini-manifest feature.


== Booting the ISO ==
;preserve bindist through USE filtering
: Normally, anything not in an ebuild's IUSE is stripped from the USE passed to ebuild.sh. This patch allows "bindist" to not be stripped, so it can be used as a means to disable pre-merge sanity checks that may exist in pkg_setup() and pkg_pretend() but will not otherwise affect the resultant build. If "bindist" will affect some functionality in the package, then it should be added to an ebuild's IUSE. This patch allows pkg_setup() and pkg_pretend() to look for "bindist", which indicates that the ebuild is being built for release, typically in an automated fashion, and thus runtime sanity checks that might otherwise run can be optionally skipped. This check is used by the udev-160-r1.ebuild to see if we should fail if we are merging udev on a system where the kernel will not support it. In Metro, this is not a big deal, but on a ''real'' production system, merging the udev on an incompatible system will render the kernel inoperable.


{{fancywarning|'''When booting into the ISO, Make sure that you select the "Alternate 64 bit kernel (altker64)". The ZFS modules have been built specifically for this kernel rather than the standard kernel. If you select a different kernel, you will get a fail to load module stack error message.'''}}
;safetydance FEATURE
:A new FEATURE setting is used by Funtoo's udev ebuild called "safetydance" which can be used to manually bypass sanity checks. This is an alternative to the "bindist" approach above. udev-160 in Funtoo Linux supports both approaches and Metro sets "safetydance" by default.


== Creating partitions ==
;GLEP 55 removal
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.
:Some code to support GLEP 55 has been removed.


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.
;new metadata format (experimental)
:Some tweaks to ebuild.sh have been made so that it is easier to support new metadata formats in the future.


==== gdisk (GPT Style) ====
;xz-utils auto-dependency
:There are several ebuilds in the Gentoo Portage repository that use .xz files but do not explicitly depend on xz-utils. A workaround has been added to ebuild.sh to add this dependency to metadata automatically if a .xz file exists in SRC_URI. This change is not yet in the official Portage sources but is being used on the Funtoo side when generating our git-based Portage trees.


'''A Fresh Start''':
==== In current development version (2.3.8) ====


First lets make sure that the disk is completely wiped from any previous disk labels and partitions.
;emerge-webrsync removed
We will also assume that <tt>/dev/sda</tt> is the target drive.<br />
: Gentoo Portage supports already tree syncing method via downloading a .tar.bz2 file containing all the ebuilds. Funtoo supports git syncing only, so the relevant code is removed.


<console>
;SYNC_UMASK, SYNC_USER support
# ##i##sgdisk -Z /dev/sda
: SYNC_USER and SYNC_UMASK can be used to define the user account to use for cloning/syncing, as well as the umask to use.
</console>


{{fancywarning|This is a destructive operation and the program will not ask you for confirmation! Make sure you really don't want anything on this disk.}}
;pwconv & grpconv are run after emerge
: Portage runs pwconv & grpconv post-emerge to ensure /etc/shadow and /etc/gshadow are valid.


Now that we have a clean drive, we will create the new layout.
;preserve bindist through USE filtering
: Normally, anything not in an ebuild's IUSE is stripped from the USE passed to ebuild.sh. This patch allows "bindist" to not be stripped, so it can be used as a means to disable pre-merge sanity checks that may exist in pkg_setup() and pkg_pretend() but will not otherwise affect the resultant build. If "bindist" will affect some functionality in the package, then it should be added to an ebuild's IUSE. This patch allows pkg_setup() and pkg_pretend() to look for "bindist", which indicates that the ebuild is being built for release, typically in an automated fashion, and thus runtime sanity checks that might otherwise run can be optionally skipped. This check is used by the udev-160-r1.ebuild to see if we should fail if we are merging udev on a system where the kernel will not support it. In Metro, this is not a big deal, but on a ''real'' production system, merging the udev on an incompatible system will render the kernel inoperable.


First open up the application:
;Dynamic SLOT support re-enabled
: The ebuilds are allowed to change their SLOT value during build.


<console>
[[Category:Projects]]
# ##i##gdisk /dev/sda
[[Category:Portage]]
</console>
{{EbuildFooter}}
 
'''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>
 
'''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 partition ===
 
<console>
# ##i##mkfs.ext2 -m 1 /dev/sda1
</console>
 
=== Create the zpool ===
We will first create the pool. The pool will be named `tank` 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 tank /dev/sda3</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: <tt>/home</tt>, <tt>/var</tt>, <tt>/usr/src</tt>, and <tt>/usr/portage</tt>.
 
<console>
Create some empty containers for organization purposes, and make the dataset that will hold /
# ##i##zfs create -p tank/funtoo
# ##i##zfs create -o mountpoint=/ tank/funtoo/root
 
Optional, but recommended datasets: /home
# ##i##zfs create -o mountpoint=/home tank/funtoo/home
 
Optional datasets: /usr/src, /usr/portage/{distfiles,packages}
# ##i##zfs create -o mountpoint=/usr/src tank/funtoo/src
# ##i##zfs create -o mountpoint=/usr/portage -o compression=off tank/funtoo/portage
# ##i##zfs create -o mountpoint=/usr/portage/distfiles tank/funtoo/portage/distfiles
# ##i##zfs create -o mountpoint=/usr/portage/packages tank/funtoo/portage/packages
</console>
 
=== Create your swap zvol ===
For modern machines that have greater than 4 GB of RAM, A swap size of 2G should be enough. However if your machine doesn't have a lot of RAM, the rule of thumb is either 2x the RAM or RAM + 1 GB.
 
For this tutorial we will assume that it is a newer machine and make a 2 GB swap.
 
<console>
# ##i##zfs create -o sync=always -o primarycache=metadata -o secondarycache=none -o volblocksize=4K -V 2G tank/swap
</console>
{{fancywarning|ZFS swap is not stable and should be used with precautions.}}
 
=== Format your swap zvol ===
<console>
# ##i##mkswap -f /dev/zvol/tank/swap
# ##i##swapon /dev/zvol/tank/swap
</console>
 
Now we will continue to install funtoo.
 
== Installing Funtoo ==
 
=== Pre-Chroot ===
 
<console>
Go into the directory that you will chroot into
# ##i##cd /mnt/funtoo
 
Make a boot folder and mount your boot drive
# ##i##mkdir boot
# ##i##mount /dev/sda1 boot
</console>
 
[[Funtoo_Linux_Installation|Now download and extract the Funtoo stage3 ...]]
 
Once you've extracted the stage3, do a few more preparations and chroot into your new funtoo environment:
 
<console>
Bind the kernel related directories
# ##i##mount -t proc none proc
# ##i##mount --rbind /dev dev
# ##i##mount --rbind /sys sys
 
Copy network settings
# ##i##cp -f /etc/resolv.conf etc
 
Make the zfs folder in 'etc' and copy your zpool.cache
# ##i##mkdir etc/zfs
# ##i##cp /etc/zfs/zpool.cache etc/zfs
 
Chroot into Funtoo
# ##i##env -i HOME=/root TERM=$TERM chroot . bash -l
</console>
 
=== In Chroot ===
 
<console>
Create a symbolic link to your mountpoints
# ##i##ln -sf /proc/mounts /etc/mtab
 
Sync your tree
# ##i##emerge --sync
</console>
 
=== Add filesystems to /etc/fstab ===
 
Before we continue to compile and or install our kernel in the next step, we will edit the <tt>/etc/fstab</tt> file because if we decide to install our kernel through portage, portage will need to know where our <tt>/boot</tt> is, so that it can place the files in there.
 
Edit <tt>/etc/fstab</tt>:
 
<pre>
# <fs>                  <mountpoint>    <type>          <opts>          <dump/pass>
 
/dev/sda1              /boot          ext2            defaults        0 2
/dev/zvol/tank/swap    none            swap            sw              0 0
</pre>
 
== Kernel Configuration ==
...wip
 
== Installing the ZFS userspace tools and kernel modules ==
Emerge {{Package|sys-fs/zfs}}. This package will bring in {{Package|sys-kernel/spl}}, and {{Package|sys-fs/zfs-kmod}} as its dependencies:
 
<console>
# ##i##emerge zfs
</console>
 
Check to make sure that the zfs tools are working. The <code>zpool.cache</code> file that you copied before should be displayed.
 
<console>
# ##i##zpool status
# ##i##zfs list
</console>
 
If everything worked, continue.
 
== Create the initramfs ==
There are two ways to do this, you can use "genkernel" or "bliss-initramfs". Both will be shown.
 
=== genkernel ===
Install genkernel and run it:
<console>
# ##i##emerge genkernel
 
You only need to add --luks if you used encryption
# ##i##genkernel --zfs --luks initramfs
</console>
 
== Installing & Configuring the Bootloader ==
 
=== GRUB 2 (Optional if you are using another bootloader) ===
<console>
# ##i##emerge grub
</console>
 
You can check that grub is version 2.00 by typing the following command:
 
<console>
# ##i##grub-install --version
grub-install (GRUB) 2.00
</console>
 
Now install grub to the drive itself (not a partition):
<console>
# ##i##grub-install /dev/sda
</console>
 
You should receive the following message:
 
<console>
Installation finished. No error reported.
</console>
 
You should now see some a grub directory with some files inside your /boot folder:
 
<console>
# ##i##ls -l /boot/grub
total 2520
-rw-r--r-- 1 root root    1024 Jan  4 16:09 grubenv
drwxr-xr-x 2 root root    8192 Jan 12 14:29 i386-pc
drwxr-xr-x 2 root root    4096 Jan 12 14:28 locale
-rw-r--r-- 1 root root 2555597 Feb  4 11:50 unifont.pf2
</console>
 
=== Extlinux (Optional if you are using another bootloader) ===
To install extlinux, you can follow the guide here: [[Extlinux|Link to Extlinux Guide]].
 
=== LILO (Optional if you are using another bootloader) ===
To install lilo you can type the following:
 
<console>
# ##i##emerge lilo
</console>
 
=== boot-update ===
boot-update comes as a dependency of grub2, so if you already installed grub, it's already on your system!
 
==== Genkernel ====
If your using genkernel you must add 'real_root=ZFS=<root>' and 'dozfs' to your params.
Example entry for <tt>/etc/boot.conf</tt>:
 
<pre>
"Funtoo ZFS" {
        kernel vmlinuz[-v]
        initrd initramfs-genkernel-x86_64[-v]
        params real_root=ZFS=tank/funtoo/root
        params += dozfs=force
        # Also add 'params += crypt_root=/dev/sda3' if you used encryption
        # Adjust the above setting to your system if needed
 
        # You should also add 'root=none' to your params (not 'params +=') if you plan to use it along with boot-update
        # If root variable will not be set, boot-update will fail to generate boot.conf
        # This is right for <=sys-boot/boot-update-1.6.11 on 16.08.2014 date
}
</pre>
 
==== Bliss Initramfs Creator ====
If you used Bliss Initramfs Creator then all you need to do is add 'root=<root>' to your params.
Example entry for <tt>/etc/boot.conf</tt>:
 
<pre>
"Funtoo ZFS" {
        kernel vmlinuz[-v]
        initrd initrd[-v]
        params root=tank/funtoo/root quiet
        # If you have an encrypted device with a regular passphrase,
        # you can add the following line
        params += enc_root=/dev/sda3 enc_type=pass
}
</pre>
 
After editing /etc/boot.conf, you just need to run boot-update to update grub.cfg
 
<console>
###i## boot-update
</console>
 
=== bliss-boot ===
This is a new program that is designed to generate a simple, human-readable/editable, configuration file for a variety of bootloaders. It currently supports grub2, extlinux, and lilo.
 
You can install it via the following command:
<console>
# ##i##emerge bliss-boot
</console>
 
==== Bootloader Configuration ====
In order to generate our bootloader configuration file, we will first configure bliss-boot so that it knows what we want. The 'bliss-boot' configuration file is located in '''/etc/bliss-boot/conf.py'''. Open that file and make sure that the following variables are set appropriately:
 
<pre>
# This should be set to the bootloader you installed earlier: (grub2, extlinux, and lilo are the available options)
bootloader = "grub2"
 
# This should be set to the kernel you installed earlier
default = "3.12.13-KS.02"
</pre>
 
Scroll all the way down until you find 'kernels'. You will need to add the kernels and the options
you want for these kernels here. Below are a few configuration options depending if you are using
'''bliss-initramfs''' or '''genkernel'''.
 
===== Genkernel =====
 
<pre>
kernel = {
    '3.12.13-KS.02' : 'real_root=ZFS=tank/funtoo/root dozfs=force quiet',
}
</pre>
 
'''If you are using encryption you can add the crypt_root option:'''
 
<pre>
kernel = {
    '3.12.13-KS.02' : 'real_root=ZFS=tank/funtoo/root dozfs=force crypt_root=/dev/sda3 quiet',
}
</pre>
 
===== Bliss Initramfs Creator =====
<pre>
kernel = {
    '3.12.13-KS.02' : 'root=tank/funtoo/root quiet',
}
</pre>
 
'''If you are using encryption then you would let the initramfs know:'''
 
#"What type of encryption authentication you want to use? ('''enc_type=''')
::* pass = will ask for passphrase directly
::* key = a plain unencrypted key file
::* key_gpg = an encrypted key file
#"Where is the encrypted drive?" ('''enc_root=''')
#"Where is the root pool after it has been decrypted?" ('''root=''')
 
<pre>
kernel = {
    '3.12.13-KS.02' : 'root=tank/funtoo/root enc_root=/dev/sda3 enc_type=pass quiet',
}
</pre>
 
==== Generate the configuration ====
Now that we have configure our '''/etc/bliss-boot/conf.py''' file, we can generate our config. Simply run the following command:
 
<console>
# ##i##bliss-boot
</console>
 
This will generate a configuration file for the bootloader you specified previously in your current directory. You can check your config file before hand to make sure it doesn't have any errors. Simply open either: grub.cfg, extlinux.conf, or lilo.conf.
 
Once you have checked it for errors, place this file in the correct directory:
 
* grub2 = /boot/grub/
* extlinux = /boot/extlinux/
* lilo = /etc/lilo.conf
 
=== LILO (Optional if you are using another bootloader) ===
Now that bliss-boot generated the lilo.conf file, move that config file to its appropriate location
and install lilo to the MBR:
 
<console>
# ##i##mv lilo.conf /etc
# ##i##lilo
 
You should see the following:
 
Warning: LBA32 addressing assumed
Added Funtoo + *
One warning was issued
</console>
 
== Final configuration ==
=== Add the zfs tools to openrc ===
<console># ##i##rc-update add zfs boot</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 tarball that you downloaded earlier so it doesn't take up space.
# ##i##cd /
# ##i##rm stage3-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##umount -l proc dev sys boot
 
Turn off the swap
# ##i##swapoff /dev/zvol/tank/swap
 
Export the zpool
# ##i##cd /
# ##i##zpool export tank
 
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.
 
== After reboot ==
 
=== Forgot to reset password? ===
==== System Rescue CD ====
If you aren't using bliss-initramfs, then you can reboot back into your sysresccd and reset through there by mounting your drive, chrooting, and then typing passwd.
 
Example:
<console>
# ##i##zpool import -f -R /mnt/funtoo tank
# ##i##chroot /mnt/funtoo bash -l
# ##i##passwd
# ##i##exit
# ##i##zpool export -f tank
# ##i##reboot
</console>
 
==== Using bliss-initramfs ====
If you forgot to reset your password and are using '''bliss-initramfs''', you can add the '''su''' option to your bootloader parameters and the initramfs will throw you into the rootfs of your drive. In there you can run 'passwd' and then type 'exit'. Once you type 'exit', the initramfs will continue to boot your system as normal.
 
=== Create initial ZFS Snapshot ===
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 system, type the following:
<console># ##i##zfs snapshot -r tank@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 (This will only revert your / dataset while keeping the rest of your data intact):
<console># ##i##zfs rollback tank/funtoo/root@install</console>
 
{{fancyimportant|'''For a detailed overview, presentation of ZFS' capabilities, as well as usage examples, please refer to the [[ZFS_Fun|ZFS Fun]] page.'''}}
 
== Troubleshooting ==
 
=== Starting from scratch ===
If your installation has gotten screwed up for whatever reason and you need a fresh restart, you can do the following from sysresccd to start fresh:
 
<console>
Destroy the pool and any snapshots and datasets it has
# ##i##zpool destroy -R -f tank
 
This deletes the files from /dev/sda1 so that even after we zap, recreating the drive in the exact sector
position and size will not give us access to the old files in this partition.
# ##i##mkfs.ext2 /dev/sda1
# ##i##sgdisk -Z /dev/sda
</console>
 
Now start the guide again :).
 
[[Category:HOWTO]]
[[Category:Filesystems]]
[[Category:Featured]]
[[Category:Install]]
 
__NOTITLE__

Revision as of 09:33, February 7, 2015

Portage (Funtoo)

   Tip

We welcome improvements to this page. To edit this page, Create a Funtoo account. Then log in and then click here to edit this page. See our editing guidelines to becoming a wiki-editing pro.

Introduction

Portage is the official package manager of Funtoo Linux. Daniel Robbins maintains a slightly different version from upstream Gentoo Linux, with support for mini-manifests and other features.

Portage Commands

emerge
high-level dependency-based package merge/unmerge tool
ebuild
lower-level package build tool
etc-update
dispatch-conf
tools to manage /etc/configurations

Portage Specifications

The latest progress and changes related to EAPI/PMS and Portage can often be found in the Gentoo Council meeting logs, which are listed on the Gentoo Council page.

The latest PMS specification to be approved by the Gentoo Council is available: eapi-5-approved-2012-09-20. The PMS specification is an attempt to codify the inner workings of Portage, and is authored by Stephen Bennett, Christian Faulhammer, Ciaran McCreesh and Ulrich Müller as a Gentoo-hosted project.

Portage Profiles

Portage uses profiles to define settings for various architectures and types of Funtoo/Gentoo systems. See the Portage Profiles page for detailed information on how Portage handles profiles. Look at Creating_Profiles to learn how to create them and at Funtoo_1.0_Profile to learn about the Funtoo 1.0 profile.

Portage Variables

Portage's behavior can be controlled by a number of configuration settings other variables that can be defined within the ebuild itself. In addition, a number of these variables are defined for the ebuild automatically by Portage. These variables are now documented on their own page: Portage Variables.

Multiple ABI Support

Portage contains support for multiple ABIs (Application Binary Interfaces) co-existing on the same system. This functionality has been extensively documented and has been moved to its own page: Multiple ABI Support.

Ebuild Functions

An ebuild developer has the ability to define Ebuild Functions that define steps to perform during a particular part of the ebuild lifecycle. These steps are now documented on their own page: Ebuild Functions.

Funtoo Portage Development

The Funtoo Core Team is currently working on a general-purpose plug-in system so that the GNU info file regeneration, news update display, and scanning of files that need updating in /etc can be pulled out of the official Portage emerge code. In addition, this plug-in system will allow other types of things to be hooked into various phases of emerge. This will allow various new plug-ins to be developed and used on systems, such as periodic security checks, etc.

Portage Logs

Logs of portage actions can be found at /var/log/emerge.log & /var/log/portage/elog/summary.log-(date the log is generated)

TODO

Add support to portage, so that when an ebuild is merged, the /var/db/pkg entry contains a list of all currently-installed versions of all ebuilds upon which that ebuild RDEPENDs. This, combined with a comprehensive set of past USE settings (may need to implement this too,) can be used to detect when an ebuild needs to be rebuilt. This could help to address issues like those in Gentoo Bug 167662 and allow easier implementation of support for things like perl-cleaner. Currently, perl-cleaner doesn't detect that vim uses perl and moving from -ithreads to ithreads causes vim to die, so it needs to be manually rebuilt.

Add support for portage to understand which version of a particular app is the "active" version that it was built against, and record this information in /var/db/pkg. This can help to implement perl-cleaner-like support in Portage.

Funtoo Features/Changes

In Funtoo stable/current Portage

emerge --sync from git
If a git-based Portage tree is already in place, emerge --sync will run "git pull" to update the underlying Portage tree. If one is not in place, the contents of the SYNC variable will be used as the remote URI from which to clone a git tree (2.2). In addition, SYNC_USER and SYNC_UMASK (defaulting to root and 022) can be used to define the user account to use for cloning/syncing, as well as the umask to use. (2.2).
Sed Wrapper Symlink and PATH fix
The Funtoo version of Portage has replaced the BSD-only sed wrapper with a symlink. This will eventually be deprecated. The sed wrapper was a way to provide BSD systems with a "sed" command that could be used inside ebuilds that worked similarly to GNU sed. A PATH fix has been applied so that /bin/sed will be detected first anyway.
mini-manifest
Funtoo's Portage supports a special mode of operation where Manifests only contain digests for distfiles and not for files in the Portage tree. This is to eliminate redundant digests since git already provides SHA1 digests. This feature is currently enabled by adding "mini-manifest" to FEATURES in /etc/make.conf but the intention is to eventually move it to a repo-specific option (note: this has now been done, as "thin-manifest" functionality has been integrated into recent versions of Portage, and is being beta tested in Funtoo.) Funtoo provides a special "mini-manifest" tree that is smaller than the full-size Portage tree, and is intended to be used with the mini-manifest feature.
preserve bindist through USE filtering
Normally, anything not in an ebuild's IUSE is stripped from the USE passed to ebuild.sh. This patch allows "bindist" to not be stripped, so it can be used as a means to disable pre-merge sanity checks that may exist in pkg_setup() and pkg_pretend() but will not otherwise affect the resultant build. If "bindist" will affect some functionality in the package, then it should be added to an ebuild's IUSE. This patch allows pkg_setup() and pkg_pretend() to look for "bindist", which indicates that the ebuild is being built for release, typically in an automated fashion, and thus runtime sanity checks that might otherwise run can be optionally skipped. This check is used by the udev-160-r1.ebuild to see if we should fail if we are merging udev on a system where the kernel will not support it. In Metro, this is not a big deal, but on a real production system, merging the udev on an incompatible system will render the kernel inoperable.
safetydance FEATURE
A new FEATURE setting is used by Funtoo's udev ebuild called "safetydance" which can be used to manually bypass sanity checks. This is an alternative to the "bindist" approach above. udev-160 in Funtoo Linux supports both approaches and Metro sets "safetydance" by default.
GLEP 55 removal
Some code to support GLEP 55 has been removed.
new metadata format (experimental)
Some tweaks to ebuild.sh have been made so that it is easier to support new metadata formats in the future.
xz-utils auto-dependency
There are several ebuilds in the Gentoo Portage repository that use .xz files but do not explicitly depend on xz-utils. A workaround has been added to ebuild.sh to add this dependency to metadata automatically if a .xz file exists in SRC_URI. This change is not yet in the official Portage sources but is being used on the Funtoo side when generating our git-based Portage trees.

In current development version (2.3.8)

emerge-webrsync removed
Gentoo Portage supports already tree syncing method via downloading a .tar.bz2 file containing all the ebuilds. Funtoo supports git syncing only, so the relevant code is removed.
SYNC_UMASK, SYNC_USER support
SYNC_USER and SYNC_UMASK can be used to define the user account to use for cloning/syncing, as well as the umask to use.
pwconv & grpconv are run after emerge
Portage runs pwconv & grpconv post-emerge to ensure /etc/shadow and /etc/gshadow are valid.
preserve bindist through USE filtering
Normally, anything not in an ebuild's IUSE is stripped from the USE passed to ebuild.sh. This patch allows "bindist" to not be stripped, so it can be used as a means to disable pre-merge sanity checks that may exist in pkg_setup() and pkg_pretend() but will not otherwise affect the resultant build. If "bindist" will affect some functionality in the package, then it should be added to an ebuild's IUSE. This patch allows pkg_setup() and pkg_pretend() to look for "bindist", which indicates that the ebuild is being built for release, typically in an automated fashion, and thus runtime sanity checks that might otherwise run can be optionally skipped. This check is used by the udev-160-r1.ebuild to see if we should fail if we are merging udev on a system where the kernel will not support it. In Metro, this is not a big deal, but on a real production system, merging the udev on an incompatible system will render the kernel inoperable.
Dynamic SLOT support re-enabled
The ebuilds are allowed to change their SLOT value during build.


Retrieved from "https://www.funtoo.org/index.php?title=ZFS_as_Root_Filesystem&oldid=8958"