Note: only upgrade from TLD Linux 2013.01 is supported. If you are running TLD Linux 2010.01 or PLD Titanium you will need to reinstall from scratch.

TLD 2015.01 brings few big changes all users should be aware of before proceeding with upgrade.

1. We have completly removed systemd from TLD Linux. We think that systemd is way too immature, too unpredictable and introduces too radical changes with new releases. Therefore in our opinion it is too unstable to use on production systems. Perhaps in future it will evolve into something usefull and predictable. For now it is just big, overcomplicated and unstable replacement of well known and rock solid Linux utilities that just do their job and do it well for years.

2. We have dropped support for geninitrd. From now on only dracut is supported.

3. We've dropped support for all old bootloaders. From now on only grub2 is supported.

4. Many packages were removed. Mostly desktop and Gnome leftovers (except some libraries), unsupported or dead software, unbuildable packages, etc.

First of all update your poldek indexes:

poldek --upa

Now get rid of all *.rpmnew files from /etc to be sure you will have newest default configurations for all packages for which old one cannot be adjusted or updated.

Please backup at least entire system configuration before proceeding! If possible backup entire host or take snapshot of its current state if its virtual machine.

Warning: if you have switched to systemd in TLD Linux 2013.01 you must switch back to SysVinit before continuing! Unfortunately you are on your own here. We will not provide howto for systemd to SysVinit migration.

Since systemd was removed we must start with udev upgrade. TLD Linux now uses eudev but we kept package names unchanged to make transition as smooth as possible:

poldek -Uvh udev-libs

TLD Linux 2015.01 replaces old Samba 3.6 with current Samba 4.2. These releases are incomaptible on both package and application level. If you are using any bits of Samba be sure to read Samba notes below before upgrading!

Now you should remove all the packages that are no longer part of TLD or your upgrade may be blocked by unresolved package dependencies. Following script will create list of these packages for you:

#!/bin/sh

rpm -qa --qf="%{name}\n" > installed_packages.txt
poldek --cmd "ls --qf=%{name}\n" > dist_packages.txt
sed -i -e 's/\+/\\\+/g;' installed_packages.txt

rm -f removed_packages.txt
for pkg in $(cat installed_packages.txt); do
  if ! grep -q -E "^"$pkg"$" dist_packages.txt; then
    echo "$pkg" >> removed_packages.txt
  fi
done

rm -f installed_packages.txt dist_packages.txt

Carefully inspect contents of file removed_packages.txt created by above script to see what packages must be removed and when ready remove them with:

rpm -ev --nodeps $(cat removed_packages.txt)

Some packages cannot be updated automatically and must be removed before upgrading:

poldek -ev freetype-devel
poldek -ev db4.5-devel

Now lets perform acutal system upgrade:

poldek -v --nohold --upgrade-dist

If you'll run into some unresolved dependencies you may try following things:

1. Remove problematic package. If it hauls half of your system use

rpm -e --nodeps pakcage

2. Do forced upgrade of problematic package via poldek command line:

> upgrade --force package

Add –nodeps if necessary.

When your upgrade-dist will finish you must check/modify/recreate your system configuration. It is strongly recommended to go through all *.rpmnew files in your /etc and modify them to fit your needs. Using old configuration files may cause problems for some packages or they may not run at all.

It is also safe to remove systemd leftovers. They may be there even if you were using SysVinit.

rm -rf /etc/systemd /etc/tmpfiles.d

After double or even triple checking everything you are ready to reboot

Postfix has been updated from 2.11 to 3.0 and some settings now have different default values. To ensure that your mail server will keep running after upgrade backward compatibility mode was introduced in version 3.0.

After postfix gets updated you may see this message when restarting and in logs:

Postfix is running with backwards-compatible default settings
See http://www.postfix.org/COMPATIBILITY_README.html for details
To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"

This means that your configuration relies on default values of one or more settings which have changed in 3.0. Please visit URL mentioned in above message to see if your configuration is affected by those changes and how make it 3.0 compatible. When finished just add

compatibility_level=2

to your main.cf to make warnings go away.

PostgreSQL database version has changed from 9.3 to 9.4. As usual when major version changes it is strongly recommended to do upgrade using dump/restore method. Before upgrade dump all contents of your databases and copy them to some safe location. You can dump everything to single sql file with this command run locally on your server:

pg_dumpall -U postgres -W > sql_full_backup.sql

or dump just globals with:

pg_dumpall -g -U postgres -W > sql_globals.sql

and then each database separately with:

pg_dump -b -U postgres -W databaseX > sql_databaseX.sql

After system upgrade please move away your old database data:

mv /var/lib/pgsql /var/lib/pgsql.bak

Initialize clean PostgreSQL 9.4 database structure

service postgresql init

Follow on screen instructions to set database passwords. Later go to /var/lib/pgsql/postgresql.conf and edit database configuration to fit your needs. Restore your database contents with something like this (if you dumped everything to single file):

psql -U postgres -W < sql_full_backup.sql 1>sql_restore_log.txt 2>&1

or with something like this (if you dumped globals and each database separately):

  psql -U postgres -W < sql_globals.sql 1>sql_globals_restore_log.txt 2>&1
  psql -U postgres -W < sql_databaseX.sql 1>sql_databaseX_restore_log.txt 2>&1
  psql -U postgres -W < sql_databaseY.sql 1>sql_databaseY_restore_log.txt 2>&1
  ...

When finished check sql*_restore_log.txt files for any errors, warnings or other abnormal things. Some structures or functions may have failed to restore due to changes in PostgreSQL made between version 9.3 and 9.4. If you'll hit such problem your only solution is to manually recreate failed structures/functions later or make modification to SQL statements directly in dump files and retry restore from the beginning.

Due to huge changes between Samba 3.6 and Samba 4.2 we recommend to perform full reinstall of Samba from scratch.

Please make full backup of your configuration and remove all Samba related packages from your system before upgrading:

poldek -ev samba samba-swat samba-client samba-common samba-winbind nss_wins pam-pam_smbpass libsmbclient libsmbclient-devel libsmbclient-static samba-devel smbget cups-backend-smb samba-vfs-audit samba-vfs-cap samba-vfs-catia samba-vfs-default_quota samba-vfs-expand_msdfs samba-vfs-fake_perms samba-vfs-notify_fam samba-vfs-netatalk samba-vfs-recycle samba-vfs-readahead samba-vfs-readonly samba-vfs-scannedonly samba-vfs-shadow_copy openldap-schema-samba samba-doc-html samba-doc-pdf

Make sure nothing is left from Samba 3.6.x configuration:

rm -rf /etc/samba

Now proceed with upgrade and when its finished install Samba 4.2 packages and configure it to your needs. Be aware that you'll not be able to use old Samba 3.6 configuration directly. We recommend to rewrite entire configuration from scratch instead of updating old config files. This way you'll get clean Samba 4.2 configuration.

Warning! Be sure to test new Samba in virtual/test environment before upgrading production systems! Once Windows clients will connect with your new Samba 4 there will be no going back!