If your system is still running PLD Titanium it is not a good idea to perform upgrade via poldek. It is possible but not recommended. Consider clean reinstall using following method:

1. Dump list of all installed packages to a file:

rpm -qa --qf="%{name}\n" | sort > installed_packages.txt

2. Make full backup of your system. You may simply move entire system contents to some folder, copy them somewhere with rsync or use any other backup solution of your choice.

3. Do minimal install of TLD 2013.01 via chroot.

4. Reinstall all your packages using previously generated list:

poldek -ivh $(cat installed_packages.txt)

Note: lots of packages were removed from TLD 2013.01. If you want to proceed with upgrade you must remove missing ones from your list for now and build them manually later.

5. Restore your system to some folder.

6. Adjust configuration of your new system based on your old config files. It is a good idea to edit files in /etc one by one. For some packages you may simply copy over old config files (if you know they'll work, ie. software version is same or config format hasn't changed) while for other you will need to recreate your configuration from scratch (this way is recommended for all config files).

7. Restore your other data to its original location (ie. /home, /var/log, /var/spool/cron, /var/lib/openssl etc.).

This version can be upgraded using poldek. Below are few tips on how to perform upgrade and list of known problems you may run into.

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.

If you are using PostgreSQL or MySQL databases be sure to read notes below before continuing.

You should start your upgrade by installing two core packages: mksh and cronie. They have obsoleted old and unmaintained pdksh and vixie-cron.

poldek -ivh mksh cronie

If you have already switched to cronie (it was available in TLD 2010.01) just install mksh (note: see known problems below).

poldek -ivh mksh

This will also upgrade part of your system.

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:

poldek -ev $(cat removed_packages.txt)

Now do force upgrade of libffi via poldek command line (temporarily we had to revert to older version):

> upgrade --force --nodeps libffi

Now copy your entire system configuration to some safe place. When ready perform upgrade:

poldek --upgrade-dist

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

1. Remove problematic package, use

rpm -e --nodeps pakcage

if it hauls half of your system.

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.

Last thing that must be done is updating kernel and bootloader. It is strongly recommended to uninstall all previous kernels and lilo/grub bootloaders and replace them with recent kernel of your choice and grub2 bootloader. First lets install grub2:

poldek -i grub2

It is also recommended to use initramfs instead of old initrd for booting your system. To create initramfs images you'll need dracut.

poldek -i dracut

By default both initrd and initramfs will be created during kernel install/update and initrd will be used by grub2. To start using initramfs edit /etc/sysconfig/grub and uncomment this line:

GRUB_PREFER_DRACUT="true"

Dracut will by default create image containing all possible kernel drivers to be sure it will be able to boot your system. On some systems it may lead to using ATA or generic IDE/SCSI drivers instead of proper ones which will hit your disk performance. This behavior can be changed by editing /etc/dracut.conf and uncommenting this line:

hostonly="yes"

It will tell Dracut to create initramfs specific to your system. Be sure to blacklist unwanted kernel modules in /etc/modprobe.d/blacklist.conf.

Now install grub2 on your boot device, ie.:

grub-install /dev/sda

If there were no errors you may install kernel, ie. grsecurity patched longterm 3.2 series:

poldek -i kernel-3.2-grsecurity

TLD 2010.01 was providing version 2.2 of Apache web server. Close to EOL Apache 2.4 was incorporated into test tree and this version is now default one used by TLD. If you have already migrated to Apache 2.4 using test tree of TLD 2010.01 you are ready to serve your web pages. If however you were still running Apache 2.2 during upgrade you may find your web server not working at all or at least some sites not working properly.

During 2.2 to 2.4 upgrade TLD package scripts will try to adjust your current configuration files to let Apache at least start. However these scripts will fail with more advanced configs.

Please read Upgrading to 2.4 from 2.2 for details how to make your web server up and running again. Remember that you (or your users) may also have to upgrade .htaccess files to make web pages work properly.

It is strongly recommended to reconfigure Apache from scratch using default configs provided by 2.4 version (search for *.rpmnew files in your /etc/httpd folder).

PostgreSQL database version has changed from 8.4 to 9.2. 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.3 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 8.4 and 9.2. 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.

TLD 2013.01 comes with MySQL 5.5. There are two options for performing MySQL upgrade. First and safe one is via full dump/restore. Similarly to PostgreSQL you can dump everything to single file:

mysqldump -u mysql -p -c --hex-blob --single-transaction --all-databases > sql_full_backup.sql

or each database separately:

mysqldump -u mysql -p -c --hex-blob --single-transaction databaseX > sql_databaseX_backup.sql

Then perform upgrade and move out old MySQL data.

mv /var/lib/mysql /var/lib/mysql.bak

Initialize clean MySQL 5.5 cluster:

service mysql init

And restore everything from your backup file(s):

mysql -u mysql -p < sql_full_backup.sql

Don't forget to edit /var/lib/mysql/mysqld.conf to fit your needs. Restart your server and you are done.

Second update method is to let the package upgrade scripts do the job (they'll try to do it anyway). Before performing update make a copy of current MySQL cluster so you'll be able to revert back to your original database in case something has failed.

cp -pR /var/lib/mysql /var/lib/mysql.bak

If you are using InnoDB storage engine it is strongly recommended to create dump files as well for all your databases.

Now do the upgrade and thats it. If at this point MySQL doesn't start see “Known problems” below. It is also a good idea to refresh mysqld.conf with recent one. To do this stop your database and move data cluster out temporarily (warning: don't overwrite your previous backup, the one created before upgrade).

mv /var/lib/mysql /var/lib/mysql.new

Initalize new, clean MySQL cluster:

service mysql init

Edit /var/lib/mysql/mysqld.conf to fit your needs and copy it out to previously created backup of your database data:

cp /var/lib/mysql/mysqld.conf /var/lib/mysql.new/mysqld.conf

Remove clean MySQL cluster and go back to your real database:

rm -rf /var/lib/mysql
mv /var/lib/mysql.new /var/lib/mysql

Finally to be sure that your database cluster is up to date you may run:

mysql_upgrade -u mysql -p

PHP in TLD no longer provides separate package php-program. It is virtual provide in php-cli package now. If your upgrade is stuck at php-program just do:

rpm -e --nodeps php-program

and try again.

Also be sure to update your PHP applications and/or web pages. There are some incompatibility issues between PHP 5.2 (default in previous version of TLD) and PHP 5.6 (default in current TLD). Check below links for more details:

PHP 5.3 backward incompatible changes

PHP 5.4 backward incompatible changes

PHP 5.5 backward incompatible changes

PHP 5.6 backward incompatible changes

There is also PHP 5.5, 5.4 and 5.3 available as php55, php54 and php53. You may choose it over 5.6 or run in parallel, ie. as CGI or FCGI.

On some systems after installation of mksh file /etc/shells may be wiped out. Be sure to check if it contains all shells valid for your system before executing upgrade or rebooting your machine.

On some system MySQL upgrade may fail. We've encountered following problems:

1. Database doesn't start at all and in /var/log/mysql/mysqld.log you see errors like:

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes

That means that one of the following files got corrupted during upgrade:

/var/lib/mysql/mysqldb/db/ib_logfile*

Just delete them and try starting your server again.

The other error you may see is something like this:

InnoDB: Assertion failure in thread 140292774348576 in file buf/buf0buf.c line 2759

This may mean that one of the following files got corrupted:

/var/lib/mysql/mysqldb/db/ibdata*

If you are not using InnoDB storage enginge just delete these files and MySQL should start just fine and recreate them. However if you are using InnoDB storage for some databases you are in serious trouble. Please follow this procedure to get your InnoDB databases working again (from MySQL documentation):

1. Remove all the existing tablespace files, including the ibdata and ib_log files. If you want to keep a backup copy of the information, then copy all the ib* files to another location before removing the files in your MySQL installation.

2. Remove any .frm files for InnoDB tables.

3. Restart the server.

4. Import the dump files.

You have dump files, right?

Due to version change from 2.0.x to 3.4.x syslog-ng will throw bunch of errors during upgrade and will not start. Don't worry, its nothing serious. All you have to do is to move away your old syslog-ng.conf from /etc/syslog-ng and recreate it from scratch using sample configuration provided by syslog-ng 3.4.x package which should be available as syslog-ng.conf.rpmnew. If it is not available do following via poldek command line after moving out your old syslog-ng.conf:

> upgrade --force syslog-ng