System update report (last update a year ago)

I have some systems that I update more rarely than the others. Of course I highly recommend keeping up to date, especially for the security fixes. I've also written similar update reports in the past. You may want to read them and compare the experience:

Another 5-month update (December 2011)
Another report from rarely updated system (September 2012)


Let's start with a comparison of the emerge --info parts before and after the update:

Timestamp of tree: Sat, 02 Feb 2013 08:45:01 +0000 -> Wed, 01 Jan 2014 10:45:01 +0000

Portage 2.1.11.31 -> 2.2.7
kernel 3.5.7-gentoo -> 3.10.17-gentoo

ld GNU ld (GNU Binutils) 2.22 -> 2.23.2

app-shells/bash:          4.2_p37 -> 4.2_p45

dev-lang/python:          2.7.3-r2, 3.2.3 -> 2.7.5-r3, 3.2.5-r3, 3.3.2-r2

dev-util/cmake:           2.8.9 -> 2.8.11.2

dev-util/pkgconfig:       0.27.1 -> 0.28

sys-apps/baselayout:      2.1-r1 -> 2.2

sys-apps/openrc:          0.11.8 -> 0.12.4

sys-apps/sandbox:         2.5 -> 2.6-r1

sys-devel/autoconf:       2.69

sys-devel/automake:       1.11.6 -> 1.11.6, 1.12.6, 1.13.4

sys-devel/binutils:       2.22-r1 -> 2.23.2

sys-devel/gcc:            4.6.3 -> 4.7.3-r1

sys-devel/gcc-config:     1.7.3

sys-devel/libtool:        2.4-r1 -> 2.4.2

sys-devel/make:           3.82-r4

sys-kernel/linux-headers: 3.6 (virtual/os-headers) -> 3.9

sys-libs/glibc:           2.15-r3 -> 2.16.0

Pretty much everything important has received an update. Many changes at once are not always easy to handle, and in my opinion this is the #1 issue people have when updating Gentoo. 

For example, just trying to run "emerge -uDNa world" after "eix-sync" resulted in the following mess:

!!! Multiple package instances within a single package slot have been pulled

!!! into the dependency graph, resulting in a slot conflict:

virtual/libiconv:0

  (virtual/libiconv-0::gentoo, installed) pulled in by

    =virtual/libiconv-0 required by (sys-apps/grep-2.14::gentoo, installed)

    (and 5 more with the same problem)

  (virtual/libiconv-0-r1::gentoo, ebuild scheduled for merge) pulled in by

    virtual/libiconv[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (dev-libs/glib-2.36.4-r1::gentoo, ebuild scheduled for merge)

dev-lang/perl:0

  (dev-lang/perl-5.16.3::gentoo, ebuild scheduled for merge) pulled in by

    >=dev-lang/perl-5.16 required by (dev-perl/Locale-gettext-1.50.0::gentoo, installed)

    (and 5 more with the same problem)

  (dev-lang/perl-5.12.4-r1::gentoo, installed) pulled in by

    dev-lang/perl[-build] required by (net-print/cups-1.5.2-r4::gentoo, installed)

The following keyword changes are necessary to proceed:

#required by virtual/libffi-3.0.13-r1, required by dev-libs/glib-2.36.4-r1, required by x11-misc/shared-mime-info-1.2-r1

=dev-libs/libffi-3.0.13-r1 ~x86

#required by dev-lang/python-3.3.2-r2, required by app-admin/python-updater-0.11, required by dev-lang/python-2.7.5-r3, required by sys-apps/portage-2.2.7[python_targets_python2_7,-python3,-python2], required by virtual/package-manager-0, required by @system, required by @world (argument)

=virtual/libffi-3.0.13-r1 ~x86

#required by dev-libs/glib-2.36.4-r1, required by x11-misc/shared-mime-info-1.2-r1

=virtual/libiconv-0-r1 ~x86

On an otherwise fully x86-stable system, portage trying to pull unstable ~x86 versions looked very weird. I suspected there might be a stabilization in progress or maybe even a broken stabilization, but checks on my up-to-date development system disproved these possibilities. I've also tried masking (using /etc/portage/package.mask) ">dev-libs/glib-2.32.4-r1" but it didn't seem to fix all of the issues.

In fact, just like the previous updates, I should have started with updating portage as the very first thing. Anyway, to avoid sounding as if it was all super-easy and obvious to me, above is a true story. Actually trying to update portage was not that easy either:

# emerge -1av portage

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  NS    ] dev-lang/python-3.3.2-r2:3.3 [2.7.3-r2:2.7, 3.2.3:3.2] USE="gdbm hardened ncurses readline ssl threads xml -build -doc -examples -ipv6 -sqlite -tk -wininst" 11,583 kB

[ebuild     U  ] sys-apps/portage-2.2.7 [2.1.11.31] USE="(ipc) (xattr*) -build -doc -epydoc (-pypy2_0) -python2 -python3 (-selinux)" LINGUAS="-ru% (-pl%)" PYTHON_TARGETS="python2_7%* python3_3%* (-pypy2_0) -python2_6% -python3_2% (-python3_4)" 886 kB

[blocks B      ] <sys-apps/sandbox-2.6-r1 ("<sys-apps/sandbox-2.6-r1" is blocking dev-lang/python-3.3.2-r2)

Total: 2 packages (1 upgrade, 1 in new slot), Size of downloads: 12,469 kB

Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be

 * installed at the same time on the same system.

  (sys-apps/sandbox-2.5::gentoo, installed) pulled in by

    >=sys-apps/sandbox-2.2 required by (sys-apps/portage-2.2.7::gentoo, ebuild scheduled for merge)

  (dev-lang/python-3.3.2-r2::gentoo, ebuild scheduled for merge) pulled in by

    >=dev-lang/python-2.7 required by (sys-apps/portage-2.2.7::gentoo, ebuild scheduled for merge)

    >=dev-lang/python-2.7[ssl] required by (sys-apps/portage-2.2.7::gentoo, ebuild scheduled for merge)

    dev-lang/python[xml] required by (app-portage/gentoolkit-0.3.0.7::gentoo, installed)

    dev-lang/python required by (app-admin/python-updater-0.10::gentoo, installed)

    dev-lang/python:3.3 required by (sys-apps/portage-2.2.7::gentoo, ebuild scheduled for merge)

    >=dev-lang/python-3.3_pre20110902 required by (sys-apps/portage-2.2.7::gentoo, ebuild scheduled for merge)

    >=dev-lang/python-2.6[xml] required by (app-portage/gentoolkit-0.3.0.7::gentoo, installed)

    dev-lang/python required by (app-portage/gentoolkit-0.3.0.7::gentoo, installed)

It seemed as if python-3.3 is causing some trouble (and it shouldn't be needed for portage because I'm still using python2 as the main system python implementation) I decided to just mask it and explicitly request python2.7.

This can be accomplished by adding the following two lines (see Project:Python/PYTHON TARGETS for more info) to /etc/portage/make.conf (or /etc/make.conf on older systems):

PYTHON_TARGETS="python2_7"
USE_PYTHON="2.7"

And adding "dev-lang/python:3.3" to /etc/portage/package.mask . After this the command succeeded:

# emerge -1av portage

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] dev-lang/python-exec-2.0.1:2  PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (python3_3) (-pypy2_0)" 80 kB

[ebuild  N     ] dev-lang/python-exec-0.3.1  PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (python3_3) (-pypy2_0)" 73 kB

[ebuild  N     ] dev-python/python-exec-10000.2:2  PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (python3_3) (-pypy2_0)" 0 kB

[ebuild  N     ] dev-python/python-exec-10000.1  PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (python3_3) (-pypy2_0)" 0 kB

[ebuild     U  ] dev-lang/python-2.7.5-r3:2.7 [2.7.3-r2:2.7] USE="berkdb* gdbm hardened%* ncurses readline ssl threads (wide-unicode) xml -build -doc -examples -ipv6 -sqlite -tk -wininst" 10,026 kB

[ebuild  N     ] dev-python/setuptools-0.8-r1  PYTHON_TARGETS="python2_7 (-pypy2_0) -python2_6 -python3_2 -python3_3" 740 kB

[ebuild  N     ] dev-python/pyxattr-0.5.2  USE="{-test}" PYTHON_TARGETS="python2_7 (-pypy2_0) -python2_6 -python3_2 -python3_3" 25 kB

[ebuild     U  ] sys-apps/portage-2.2.7 [2.1.11.31] USE="(ipc) (xattr*) -build -doc -epydoc (-pypy2_0) -python2 -python3 (-selinux)" LINGUAS="-ru% (-pl%)" PYTHON_TARGETS="python2_7%* (-pypy2_0) -python2_6% -python3_2% -python3_3% (-python3_4)" 886 kB

As the next step I decided to continue updating in smaller chunks. Here's what happened:

# emerge -uDNa system

WARNING: One or more updates have been skipped due to a dependency conflict:

dev-lang/perl:0

  (dev-lang/perl-5.16.3::gentoo, ebuild scheduled for merge) conflicts with

    dev-lang/perl[-build] required by (net-print/cups-1.5.2-r4::gentoo, installed)

This was also not very obvious, but since it's just a warning I let portage continue at this point. In fact, after that "emerge -uDNa world" completed without problems. Looks like portage-2.2's support for preserving libraries helps a lot - last time I needed to do several rounds of revdep-rebuild during such a big update.

Another important thing to keep in mind for updates are news items. You can read the new ones using "eselect news read new", and get back to old ones using "eselect news list" and "eselect news read <number>", where number comes from "eselect news list". Here are news items that appeared during this update:

2013-03-29-udev-upgrade

2013-06-30-cups16

2013-08-23-emerge-language

2013-09-27-initramfs-required

2013-10-14-grub2-migration

2013-06-07-portage-preserve-libs-default

2013-11-07-python-exec-package-move

GRUB2 migration went very smoothly - it worked well on my development system, and there were no problems here either. Make sure to read the following docs on Gentoo Wiki:

http://wiki.gentoo.org/wiki/GRUB2
http://wiki.gentoo.org/wiki/GRUB2_Quick_Start
http://wiki.gentoo.org/wiki/GRUB2_Migration

Also note how you can chainload the new GRUB2 while your current Grub Legacy continues to be the main bootloader for testing. I highly recommend doing that before completely replacing the previous bootloader with GRUB2, and it makes the process safer.

Another interesting one was udev upgrade. This machine has two network cards, so I added "/etc/udev/rules.d/99-local-persistent-net.rules" file with the following contents:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:02:44:81:55:8b", NAME="wan0"

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1d:60:f8:4a:cd", NAME="lan0"

One way to test is using udevadm. See how contents of ID_NET_NAME_MAC correspond to ATTR{address} above:

udevadm test-builtin net_id /sys/class/net/eth0

calling: test-builtin

=== trie on-disk ===

tool version:          208

file size:         5860871 bytes

header size             80 bytes

strings            1295087 bytes

nodes              4565704 bytes

ID_NET_NAME_MAC=enx00024481558b

ID_OUI_FROM_DATABASE=SURECOM Technology Co.

ID_NET_NAME_PATH=enp3s6

Don't forget to update /etc/conf.d/net and iptables config (editing /var/lib/iptables/rules-save and reloading iptables is my favorite way).

After the new config is ready it's time for cleanups:

rm /etc/udev/rules.d/70-persistent-net.rules

rm /etc/udev/rules.d/80-net-name-slot.rules

ln -s net.lo /etc/init.d/net.wan0

ln -s net.lo /etc/init.d/net.lan0

rc-update delete net.eth0 default && rc-update add net.wan0 default

rc-update delete net.eth1 default && rc-update add net.lan0 default

For the cups-1.6 update I needed to re-export the printers to samba. I've used the web interface for that and it worked just fine. After any change like that I also test everything that changed (on a freshly booted system to ensure next reboot won't break it), which in this case meant printing test pages from connected Linux, Mac and Windows systems. Everything worked.

Finally, at least as of squid-3.3.8 (the actual change probably happened earlier), /etc/squid/squid.conf is now minimal. If you've had trouble with merging new config file after every update, I highly recommend just starting from scratch with the minimal file (/etc/squid/squid.conf.default). The old-style big commented config is installed as /etc/squid/squid.conf.documented.

During the upgrade I received the following error messages from squid (mostly in case it helps someone find this using e.g. Google Search):

squid: Bungled /etc/squid/squid.conf line 581: acl manager proto cache_object

/etc/init.d/squid[2391]: ERROR: squid failed to start

squid[2672]: Squid Parent: (squid-1) process 2675 exited due to signal 6 with status 0

/etc/init.d/squid[2973]: Squid shutdown failed, probably service is already down.

This is actually what prompted me to check out the smaller config file (/etc/squid.conf.default), and I highly recommend it.

I hope this can help you with your own updates. I think it was actually faster than starting from scratch - note that some config changes were needed anyway, and with portage-2.2 big updates are much smoother thanks to preserved libs feature. Feel free to leave your comments or questions below.