Table of Contents
Upgrading to TLD Linux 2015.01
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.
Release notes
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.
Getting started
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.
Preparations
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)
Upgrading
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.
Finishing
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
Notes for some packages
Postfix
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
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.
Samba
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!