Difference between pages "Linux Containers" and "Toolchain update"

From Funtoo
(Difference between pages)
Jump to: navigation, search
 
(Keywords changes for stable users)
 
Line 1: Line 1:
Linux Containers, or LXC, is a Linux feature that allows Linux to run one or more isolated virtual systems (with their own network interfaces, process namespace, user namespace, and power state) using a single Linux kernel on a single server.  
+
This guide explains how to upgrade the Funtoo toolchain to the new version available. With this toolchain update comes some other core packages bumps that were depending on the new toolchain.  
  
== Status ==
+
{{fancynote|This toolchain update affects the users of the ''current'' tree. ''Stable'' users should not update to this toolchain yet as many stable packages may not build with it. As of Monday December 5, 2011, manually unmasking the packages is no longer necessary after you sync your tree.}}
  
As of Linux kernel 3.1.5, LXC is usable for isolating your own private workloads from one another. It is not yet ready to isolate potentially malicious users from one another or the host system. For a more mature containers solution that is appropriate for hosting environments, see [[OpenVZ]].
+
== Current toolchain ==
 +
Funtoo currently provides the following core package versions:
 +
*sys-devel/gcc-4.6.4-r2
 +
*sys-devel/binutils-2.22
 +
*sys-kernel/linux-headers-3.4-r2
 +
*sys-libs/glibc-2.15-r4
 +
*sys-fs/udev-171-r8
  
LXC containers don't yet have their own system uptime, and they see everything that's in the host's <tt>dmesg</tt> output, among other things. But in general, the technology works.
+
== Toolchain update ==
 +
Those core packages will be updated to the following versions:
 +
*sys-devel/gcc-4.8.1-r2
 +
*sys-devel/binutils-2.23.1
 +
*sys-kernel/linux-headers-3.7
 +
*sys-libs/glibc-2.18
 +
*sys-fs/udev-171-r9
  
== Basic Info ==
+
== Unmasking the packages ==
  
 +
To unmask the packages, run <tt>emerge --sync</tt>. If you are using the funtoo-current, they should now be unmasked. To perform this manually (no longer necessary,) do this:
  
* Linux Containers are based on:
+
<pre>
** Kernel namespaces for resource isolation
+
# install -d /etc/portage/package.unmask
** CGroups for resource limitation and accounting
+
# echo ">=sys-devel/gcc-4.8.1" >> /etc/portage/package.unmask/toolchain
 +
# echo "=sys-devel/binutils-2.23.1" >> /etc/portage/package.unmask/toolchain
 +
# echo "=sys-kernel/linux-headers-3.7" >> /etc/portage/package.unmask/toolchain
 +
# echo "=sys-libs/glibc-2.18" >> /etc/portage/package.unmask/toolchain
 +
# echo "=sys-fs/udev-171-r9" >> /etc/portage/package.unmask/toolchain
 +
</pre>
  
{{Package|app-emulation/lxc}} is the userspace tool for Linux containers
+
Easier way is to copy <code>funtoo-toolchain</code> from /usr/portage/profiles/package.mask, assuming that /etc/portage/package.unmask is a directory:
 
+
== Control groups ==
+
 
+
* Control groups (cgroups) in kernel since 2.6.24
+
** Allows aggregation of tasks and their children
+
** Subsystems (cpuset, memory, blkio,...)
+
** accounting - to measure how much resources certain systems use
+
** resource limiting - groups can be set to not exceed a set memory limit
+
** prioritization - some groups may get a larger share of CPU
+
** control - freezing/unfreezing of cgroups, checkpointing and restarting
+
** No disk quota limitation ( -> image file, LVM, XFS, directory tree quota,...)
+
 
+
== Subsystems ==
+
<br>
+
<console>
+
###i## cat /proc/cgroups
+
subsys_name hierarchy num_cgroups enabled
+
cpuset
+
cpu
+
cpuacct
+
memory
+
devices
+
freezer
+
blkio
+
perf_event
+
hugetlb
+
</console>
+
 
+
#cpuset    -> limits tasks to specific CPU/CPUs
+
#cpu        -> CPU shares
+
#cpuacct    -> CPU accounting
+
#memory    -> memory and swap limitation and accounting
+
#devices    -> device allow deny list
+
#freezer    -> suspend/resume tasks
+
#blkio      -> I/O priorization (weight, throttle, ...)
+
#perf_event -> support for per-cpu per-cgroup monitoring [http://lwn.net/Articles/421574/ perf_events]
+
#hugetlb    -> cgroup resource controller for HugeTLB pages  [http://lwn.net/Articles/499255/ hugetlb]
+
 
+
== Configuring the Funtoo Host System ==
+
 
+
=== Install LXC kernel ===
+
Any kernel beyond 3.1.5 will probably work. Personally I prefer {{Package|sys-kernel/gentoo-sources}} as these have support for all the namespaces without sacrificing the xfs, FUSE or NFS support for example. These checks were introduced later starting from kernel 3.5, this could also mean that the user namespace is not working optimally.
+
 
+
* User namespace (EXPERIMENTAL) depends on EXPERIMENTAL and on UIDGID_CONVERTED
+
** config UIDGID_CONVERTED
+
*** True if all of the selected software components are known to have uid_t and gid_t converted to kuid_t and kgid_t where appropriate and are otherwise safe to use with the user namespace.
+
**** Networking - depends on NET_9P = n
+
**** Filesystems - 9P_FS = n, AFS_FS = n, AUTOFS4_FS = n, CEPH_FS = n, CIFS = n, CODA_FS = n, FUSE_FS = n, GFS2_FS = n, NCP_FS = n, NFSD = n, NFS_FS = n, OCFS2_FS = n, XFS_FS = n
+
**** Security options - Grsecurity - GRKERNSEC = n (if applicable)
+
 
+
** As of 3.10.xx kernel, all of the above options are safe to use with User namespaces, except for XFS_FS, therefore with kernel >=3.10.xx, you should answer XFS_FS = n, if you want User namespaces support.
+
** in your kernel source directory, you should check init/Kconfig and find out what UIDGID_CONVERTED depends on
+
 
+
==== Kernel configuration ====
+
These options should be enable in your kernel to be able to take full advantage of LXC.
+
 
+
* General setup
+
** CONFIG_NAMESPACES
+
*** CONFIG_UTS_NS
+
*** CONFIG_IPC_NS
+
*** CONFIG_PID_NS
+
*** CONFIG_NET_NS
+
*** CONFIG_USER_NS
+
** CONFIG_CGROUPS
+
*** CONFIG_CGROUP_DEVICE
+
*** CONFIG_CGROUP_SCHED
+
*** CONFIG_CGROUP_CPUACCT
+
*** CONFIG_CGROUP_MEM_RES_CTLR (in 3.6+ kernels it's called CONFIG_MEMCG)
+
*** CONFIG_CGROUP_MEM_RES_CTLR_SWAP (in 3.6+ kernels it's called CONFIG_MEMCG_SWAP)
+
*** CONFIG_CPUSETS (on multiprocessor hosts)
+
* Networking support
+
** Networking options
+
*** CONFIG_VLAN_8021Q
+
* Device Drivers
+
** Character devices
+
*** Unix98 PTY support
+
**** CONFIG_DEVPTS_MULTIPLE_INSTANCES
+
** Network device support
+
*** Network core driver support
+
**** CONFIG_VETH
+
**** CONFIG_MACVLAN
+
 
+
Once you have lxc installed, you can then check your kernel config with:
+
<console>
+
# ##i##CONFIG=/path/to/config /usr/sbin/lxc-checkconfig
+
</console>
+
 
+
=== Emerge lxc ===
+
<console>
+
# ##i##emerge app-emulation/lxc
+
</console>
+
 
+
=== Configure Networking For Container ===
+
 
+
Typically, one uses a bridge to allow containers to connect to the network. This is how to do it under Funtoo Linux:
+
 
+
# create a bridge using the Funtoo network configuration scripts. Name the bridge something like <tt>brwan</tt> (using <tt>/etc/init.d/netif.brwan</tt>). Configure your bridge to have an IP address.
+
# Make your physical interface, such as <tt>eth0</tt>, an interface with no IP address (use the Funtoo <tt>interface-noip</tt> template.)
+
# Make <tt>netif.eth0</tt> a slave of <tt>netif.brwan</tt> in <tt>/etc/conf.d/netif.brwan</tt>.
+
# Enable your new bridged network and make sure it is functioning properly on the host.
+
 
+
You will now be able to configure LXC to automatically add your container's virtual ethernet interface to the bridge when it starts, which will connect it to your network.
+
 
+
== Setting up a Funtoo Linux LXC Container ==
+
 
+
Here are the steps required to get Funtoo Linux running <i>inside</i> a container. The steps below show you how to set up a container using an existing Funtoo Linux OpenVZ template. It is now also possible to use [[Metro]] to build an lxc container tarball directly, which will save you manual configuration steps and will provide an <tt>/etc/fstab.lxc</tt> file that you can use for your host container config. See [[Metro Recipes]] for info on how to use Metro to generate an lxc container.
+
 
+
=== Create and Configure Container Filesystem ===
+
 
+
# Start with a Funtoo LXC template, and unpack it to a directory such as <tt>/lxc/funtoo0/rootfs/</tt>
+
# Create an empty <tt>/lxc/funtoo0/fstab</tt> file
+
# Ensure <tt>c1</tt> line is uncommented (enabled) and <tt>c2</tt> through <tt>c6</tt> lines are disabled in <tt>/lxc/funtoo0/rootfs/etc/inittab</tt>
+
 
+
That's almost all you need to get the container filesystem ready to start.
+
 
+
=== Create Container Configuration Files ===
+
 
+
Create the following files:
+
 
+
==== <tt>/lxc/funtoo0/config</tt> ====
+
 
+
 
+
and also create symlink from
+
==== <tt> /lxc/funtoo0/config to /etc/lxc/funtoo0.conf </tt> ====
+
<console>
+
###i## ln -s /lxc/funtoo0/config /etc/lxc/funtoo0.conf
+
</console>
+
 
+
{{Fancynote| Daniel Robbins needs to update this config to be more in line with http://wiki.progress-linux.org/software/lxc/ -- this config appears to have nice, refined device node permissions and other goodies. // note by Havis to Daniel, this config is already superior.}}
+
 
+
 
+
Read "man 5 lxc.conf" , to get more information about linux container configuration file.
+
 
<pre>
 
<pre>
## Container
+
# cp /usr/portage/profiles/package.mask/funtoo-toolchain /etc/portage/package.unmask
lxc.utsname                            = funtoo0
+
lxc.rootfs                              = /lxc/funtoo0/rootfs/
+
lxc.arch                                = x86_64
+
#lxc.console                            = /var/log/lxc/funtoo0.console  # uncomment if you want to log containers console
+
lxc.tty                                = 6  # if you plan to use container with physical terminals (eg F1..F6)
+
#lxc.tty                                = 0  # set to 0 if you dont plan to use the container with physical terminal, also comment out in your containers /etc/inittab  c1 to c6 respawns (e.g. c1:12345:respawn:/sbin/agetty 38400 tty1 linux)
+
lxc.pts                                = 1024
+
 
+
 
+
## Capabilities
+
lxc.cap.drop                            = audit_control
+
lxc.cap.drop                            = audit_write
+
lxc.cap.drop                            = mac_admin
+
lxc.cap.drop                            = mac_override
+
lxc.cap.drop                            = mknod
+
lxc.cap.drop                            = setfcap
+
lxc.cap.drop                            = setpcap
+
lxc.cap.drop                            = sys_admin
+
lxc.cap.drop                            = sys_boot
+
#lxc.cap.drop                            = sys_chroot # required by SSH
+
lxc.cap.drop                            = sys_module
+
#lxc.cap.drop                            = sys_nice
+
lxc.cap.drop                            = sys_pacct
+
lxc.cap.drop                            = sys_rawio
+
lxc.cap.drop                            = sys_resource
+
lxc.cap.drop                            = sys_time
+
#lxc.cap.drop                            = sys_tty_config # required by getty
+
 
+
## Devices
+
#lxc.cgroup.devices.allow              = a # Allow access to all devices
+
lxc.cgroup.devices.deny                = a # Deny access to all devices
+
 
+
# Allow to mknod all devices (but not using them)
+
lxc.cgroup.devices.allow                = c *:* m
+
lxc.cgroup.devices.allow                = b *:* m
+
 
+
lxc.cgroup.devices.allow                = c 1:3 rwm # /dev/null
+
lxc.cgroup.devices.allow                = c 1:5 rwm # /dev/zero
+
lxc.cgroup.devices.allow                = c 1:8 rwm # /dev/random
+
lxc.cgroup.devices.allow                = c 1:9 rwm # /dev/urandom
+
#lxc.cgroup.devices.allow                = c 4:0 rwm # /dev/tty0 ttys not required if you have lxc.tty = 0
+
#lxc.cgroup.devices.allow                = c 4:1 rwm # /dev/tty1 devices with major number 4 are "real" tty devices
+
#lxc.cgroup.devices.allow                = c 4:2 rwm # /dev/tty2
+
#lxc.cgroup.devices.allow                = c 4:3 rwm # /dev/tty3
+
lxc.cgroup.devices.allow                = c 5:0 rwm # /dev/tty
+
lxc.cgroup.devices.allow                = c 5:1 rwm # /dev/console
+
lxc.cgroup.devices.allow                = c 5:2 rwm # /dev/ptmx
+
lxc.cgroup.devices.allow                = c 10:229 rwm # /dev/fuse
+
lxc.cgroup.devices.allow                = c 136:* rwm # /dev/pts/* devices with major number 136 are pts
+
lxc.cgroup.devices.allow                = c 254:0 rwm # /dev/rtc0
+
 
+
## Limits#
+
lxc.cgroup.cpu.shares                  = 1024
+
lxc.cgroup.cpuset.cpus                = 0        # limits container to CPU0
+
lxc.cgroup.memory.limit_in_bytes      = 512M
+
lxc.cgroup.memory.memsw.limit_in_bytes = 1G
+
#lxc.cgroup.blkio.weight                = 500      # requires cfq block scheduler
+
 
+
## Filesystem
+
#containers fstab should be outside it's rootfs dir (e.g. /lxc/funtoo0/fstab is ok, but /lxc/funtoo0/rootfs/etc/fstab is wrong!!!)
+
#lxc.mount                              = /lxc/funtoo0/fstab     
+
 
+
#lxc.mount.entry is prefered, because it supports relative paths
+
lxc.mount.entry                        = proc proc proc nosuid,nodev,noexec  0 0
+
lxc.mount.entry                        = sysfs sys sysfs nosuid,nodev,noexec,ro 0 0
+
lxc.mount.entry                        = devpts dev/pts devpts nosuid,noexec,mode=0620,ptmxmode=000,newinstance 0 0
+
lxc.mount.entry                        = tmpfs dev/shm tmpfs nosuid,nodev,mode=1777 0 0
+
lxc.mount.entry                        = tmpfs run tmpfs nosuid,nodev,noexec,mode=0755,size=128m 0 0
+
lxc.mount.entry                        = tmpfs tmp tmpfs nosuid,nodev,noexec,mode=1777,size=1g 0 0
+
 
+
##Example of having /var/tmp/portage as tmpfs in container
+
#lxc.mount.entry                        = tmpfs var/tmp/portage tmpfs defaults,size=8g,uid=250,gid=250,mode=0775 0 0
+
##Example of bind mount
+
#lxc.mount.entry                        = /srv/funtoo0 /lxc/funtoo0/rootfs/srv/funtoo0 none defaults,bind 0 0
+
 
+
## Network
+
lxc.network.type                        = veth
+
lxc.network.flags                      = up
+
lxc.network.hwaddr                      = #put your MAC address here, otherwise you will get a random one
+
lxc.network.link                        = br0
+
lxc.network.name                        = eth0
+
#lxc.network.veth.pair                  = veth-example
+
 
</pre>
 
</pre>
  
Read "man 7 capabilities" to get more information aboout Linux capabilities.
+
== Keywords changes for ''stable'' users ==
 
+
If ''Stable'' users are not afraid to upgrade their toolchain, they must add the correct keywords too:
Above, use the following command to generate a random MAC for <tt>lxc.network.hwaddr</tt>:
+
 
+
<console>
+
###i## openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'
+
</console>
+
 
+
It is a very good idea to assign a static MAC address to your container using <tt>lxc.network.hwaddr</tt>. If you don't, LXC will auto-generate a new random MAC every time your container starts, which may confuse network equipment that expects MAC addresses to remain constant.
+
 
+
It might happen from case to case that you aren't able to start your LXC Container with the above generated MAC address so for all these who run into that problem here is a little script that connects your IP for the container with the MAC address. Just save the following code as <tt>/etc/lxc/hwaddr.sh</tt>, make it executable and run it like <tt>/etc/lxc/hwaddr.sh xxx.xxx.xxx.xxx</tt> where xxx.xxx.xxx.xxx represents your Container IP. <br><tt>/etc/lxc/hwaddr.sh</tt>:
+
 
+
 
<pre>
 
<pre>
#!/bin/sh
+
# install -d /etc/portage/package.keywords
IP=$*
+
# echo ">=sys-devel/gcc-4.8.1 **" >> /etc/portage/package.keywords/toolchain
HA=`printf "02:00:%x:%x:%x:%x" ${IP//./ }`
+
# echo "=sys-devel/binutils-2.23.1 **" >> /etc/portage/package.keywords/toolchain
echo $HA
+
# echo "=sys-kernel/linux-headers-3.7 **" >> /etc/portage/package.keywords/toolchain
 +
# echo "=sys-libs/glibc-2.18 **" >> /etc/portage/package.keywords/toolchain
 +
# echo "=sys-fs/udev-171-r9 **" >> /etc/portage/package.keywords/toolchain
 
</pre>
 
</pre>
  
==== <tt>/lxc/funtoo0/fstab</tt> ====
+
== Upgrading to the new toolchain ==
{{fancynote| It is now preferable to have mount entries directly in config file instead of separate fstab:}}
+
As the dependencies have been adjusted so the packages are built in the right order, no user manipulation is required. Updating everything should work out of the box, but to ensure that no unwanted package is updated between the toolchain parts, proceed as following:
Edit the file <tt>/lxc/funtoo0/fstab</tt>:
+
 
<pre>
 
<pre>
none /lxc/funtoo0/dev/pts devpts defaults 0 0
+
# emerge --sync
none /lxc/funtoo0/proc proc defaults 0 0
+
# emerge -1 glibc
none /lxc/funtoo0/sys sysfs defaults 0 0
+
# emerge -uNDav @world
none /lxc/funtoo0/dev/shm tmpfs nodev,nosuid,noexec,mode=1777,rw 0 0
+
 
</pre>
 
</pre>
  
== LXC Networking ==
+
Done!
*veth - Virtual Ethernet (bridge)
+
*vlan - vlan interface (requires device able to do vlan tagging)
+
*macvlan (mac-address based virtual lan tagging) has 3 modes:
+
**private
+
**vepa (Virtual Ethernet Port Aggregator)
+
**bridge
+
*phys - dedicated host NIC
+
[https://blog.flameeyes.eu/2010/09/linux-containers-and-networking Linux Containers and Networking]
+
  
Enable routing on the host:
+
== What about libtool? ==
By default Linux workstations and servers have IPv4 forwarding disabled.
+
libtool is automatically rebuilt during the update process. This avoids any manual steps to be executed after the update.
<console>
+
###i## echo "1" > /proc/sys/net/ipv4/ip_forward
+
###i## cat /proc/sys/net/ipv4/ip_forward
+
# 1
+
</console>
+
  
== Initializing and Starting the Container ==
+
== Rebuilding the whole system? ==
 +
Some people argue that this is necessary to rebuild the whole system (even twice) after a toolchain upgrade. This is never necessary, but users who changed their CFLAGS or CXXFLAGS due to a new available arch or optimization flag are welcome to do so, if they want. However, remember that this is never necessary.
  
You will probably need to set the root password for the container before you can log in. You can use chroot to do this quickly:
+
== Case of depclean ==
 +
After switching to new gcc, it can be cleaned (accidentally) by emerge ---depclean, it is recommended to save older gcc for failover
 +
<pre>
 +
# emerge -av --depclean --exclude sys-devel/gcc
 +
</pre>
  
<console>
+
== Troubleshooting ==
###i## chroot /lxc/funtoo0/rootfs
+
After the update, if any package fails to start with a shared library missing problem, try to run:
(chroot) ###i## passwd
+
<pre>
New password: XXXXXXXX
+
# revdep-rebuild
Retype new password: XXXXXXXX
+
</pre>
passwd: password updated successfully
+
(chroot) ###i## exit
+
</console>
+
 
+
Now that the root password is set, run:
+
 
+
<console>
+
###i## lxc-start -n funtoo0 -d
+
</console>
+
 
+
The <tt>-d</tt> option will cause it to run in the background.
+
 
+
To attach to the console:
+
 
+
<console>
+
###i## lxc-console -n funtoo0
+
</console>
+
 
+
You should now be able to log in and use the container. In addition, the container should now be accessible on the network.
+
 
+
To directly attach to container:
+
 
+
<console>
+
###i## lxc-attach -n funtoo0
+
</console>
+
 
+
To stop the container:
+
 
+
<console>
+
###i## lxc-stop -n funtoo0
+
</console>
+
 
+
Ensure that networking is working from within the container while it is running, and you're good to go!
+
 
+
== Starting LXC container during host boot ==
+
 
+
# You need to create symlink in <tt>/etc/init.d/</tt> to <tt>/etc/init.d/lxc</tt> so that it reflects your container.
+
# <tt>ln -s /etc/init.d/lxc /etc/init.d/lxc.funtoo0</tt>
+
# now you can add <tt>lxc.funtoo0</tt> to default runlevel
+
# <tt>rc-update add lxc.funtoo0 default</tt>
+
<console>
+
###i## rc
+
* Starting funtoo0 ...                  [ ok ]
+
</console>
+
 
+
== LXC Bugs/Missing Features ==
+
 
+
This section is devoted to documenting issues with the current implementation of LXC and its associated tools. We will be gradually expanding this section with detailed descriptions of problems, their status, and proposed solutions.
+
 
+
=== reboot ===
+
 
+
By default, lxc does not support rebooting a container from within. It will simply stop and the host will not know to start it.
+
 
+
=== PID namespaces ===
+
 
+
Process ID namespaces are functional, but the container can still see the CPU utilization of the host via the system load (ie. in <tt>top</tt>).
+
 
+
=== /dev/pts newinstance ===
+
 
+
* Some changes may be required to the host to properly implement "newinstance" <tt>/dev/pts</tt>. See [https://bugzilla.redhat.com/show_bug.cgi?id=501718 This Red Hat bug].
+
 
+
=== lxc-create and lxc-destroy ===
+
 
+
* LXC's shell scripts are badly designed and are sure way to destruction, avoid using lxc-create and lxc-destroy.
+
 
+
=== network initialization and cleanup ===
+
 
+
* If used network.type = phys after lxc-stop the interface will be renamed to value from lxc.network.link. It supposed to be fixed in 0.7.4, happens still on 0.7.5 - http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg01760.html
+
 
+
* Re-starting a container can result in a failure as network resource are tied up from the already-defunct instance: [http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg00824.html]
+
 
+
=== lxc-halt ===
+
 
+
* Missing tool to graceful shutdown container. 'lxc-halt' should be written and be posix sh-compatible, using lxc-execute to run halt in container.
+
 
+
=== funtoo ===
+
 
+
* Our udev should be updated to contain <tt>-lxc</tt> in scripts. (This has been done as of 02-Nov-2011, so should be resolved. But not fixed in our openvz templates, so need to regen them in a few days.)
+
* Our openrc should be patched to handle the case where it cannot mount tmpfs, and gracefully handle this situation somehow. (Work-around in our docs above, which is to mount tmpfs to <tt>/libexec/rc/init.d</tt> using the container-specific <tt>fstab</tt> file (on the host.)
+
* Emerging udev within a container can/will fail when realdev is run, if a device node cannot be created (such as /dev/console) if there are no mknod capabilities within the container. This should be fixed.
+
 
+
== References ==
+
 
+
* <tt>man 7 capabilities</tt>
+
* <tt>man 5 lxc.conf</tt>
+
 
+
== Links ==
+
 
+
* There are a number of additional lxc features that can be enabled via patches: [http://lxc.sourceforge.net/patches/linux/3.0.0/3.0.0-lxc1/]
+
* [https://wiki.ubuntu.com/UserNamespace Ubuntu User Namespaces page]
+
* lxc-gentoo setup script [https://github.com/globalcitizen/lxc-gentoo on GitHub]
+
 
+
* '''IBM developerWorks'''
+
** [http://www.ibm.com/developerworks/linux/library/l-lxc-containers/index.html LXC: Linux Container Tools]
+
** [http://www.ibm.com/developerworks/linux/library/l-lxc-security/ Secure Linux Containers Cookbook]
+
 
+
* '''Linux Weekly News'''
+
** [http://lwn.net/Articles/244531/ Smack for simplified access control]
+
  
[[Category:Labs]]
+
[[Category:Portage]]
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
[[Category:Virtualization]]
 

Revision as of 18:21, 21 September 2013

This guide explains how to upgrade the Funtoo toolchain to the new version available. With this toolchain update comes some other core packages bumps that were depending on the new toolchain.

Note: This toolchain update affects the users of the current tree. Stable users should not update to this toolchain yet as many stable packages may not build with it. As of Monday December 5, 2011, manually unmasking the packages is no longer necessary after you sync your tree.

Current toolchain

Funtoo currently provides the following core package versions:

  • sys-devel/gcc-4.6.4-r2
  • sys-devel/binutils-2.22
  • sys-kernel/linux-headers-3.4-r2
  • sys-libs/glibc-2.15-r4
  • sys-fs/udev-171-r8

Toolchain update

Those core packages will be updated to the following versions:

  • sys-devel/gcc-4.8.1-r2
  • sys-devel/binutils-2.23.1
  • sys-kernel/linux-headers-3.7
  • sys-libs/glibc-2.18
  • sys-fs/udev-171-r9

Unmasking the packages

To unmask the packages, run emerge --sync. If you are using the funtoo-current, they should now be unmasked. To perform this manually (no longer necessary,) do this:

# install -d /etc/portage/package.unmask
# echo ">=sys-devel/gcc-4.8.1" >> /etc/portage/package.unmask/toolchain
# echo "=sys-devel/binutils-2.23.1" >> /etc/portage/package.unmask/toolchain
# echo "=sys-kernel/linux-headers-3.7" >> /etc/portage/package.unmask/toolchain
# echo "=sys-libs/glibc-2.18" >> /etc/portage/package.unmask/toolchain
# echo "=sys-fs/udev-171-r9" >> /etc/portage/package.unmask/toolchain

Easier way is to copy funtoo-toolchain from /usr/portage/profiles/package.mask, assuming that /etc/portage/package.unmask is a directory:

# cp /usr/portage/profiles/package.mask/funtoo-toolchain /etc/portage/package.unmask

Keywords changes for stable users

If Stable users are not afraid to upgrade their toolchain, they must add the correct keywords too:

# install -d /etc/portage/package.keywords
# echo ">=sys-devel/gcc-4.8.1 **" >> /etc/portage/package.keywords/toolchain
# echo "=sys-devel/binutils-2.23.1 **" >> /etc/portage/package.keywords/toolchain
# echo "=sys-kernel/linux-headers-3.7 **" >> /etc/portage/package.keywords/toolchain
# echo "=sys-libs/glibc-2.18 **" >> /etc/portage/package.keywords/toolchain
# echo "=sys-fs/udev-171-r9 **" >> /etc/portage/package.keywords/toolchain

Upgrading to the new toolchain

As the dependencies have been adjusted so the packages are built in the right order, no user manipulation is required. Updating everything should work out of the box, but to ensure that no unwanted package is updated between the toolchain parts, proceed as following:

# emerge --sync
# emerge -1 glibc
# emerge -uNDav @world

Done!

What about libtool?

libtool is automatically rebuilt during the update process. This avoids any manual steps to be executed after the update.

Rebuilding the whole system?

Some people argue that this is necessary to rebuild the whole system (even twice) after a toolchain upgrade. This is never necessary, but users who changed their CFLAGS or CXXFLAGS due to a new available arch or optimization flag are welcome to do so, if they want. However, remember that this is never necessary.

Case of depclean

After switching to new gcc, it can be cleaned (accidentally) by emerge ---depclean, it is recommended to save older gcc for failover

# emerge -av --depclean --exclude sys-devel/gcc

Troubleshooting

After the update, if any package fails to start with a shared library missing problem, try to run:

# revdep-rebuild