The first problem I had with upgrading is that several pieces of software just wouldn't upgrade smoothly.
Rather than using
sudo apt-get dist-upgrade only, I had to use
sudo apt-get install -f,
sudo dpkg --configure -a.
At some point php5 wouldn't upgrade because it was dependent on php5-json, which I couldn't install because php5 was already installed. I had to uninstall several packages, install php5-json, and then reinstall the removed packages.
Then came the big problem: after rebooting my on-board NIC wasn't working, and at the point in the boot process where the login screen/prompt should be displayed gdm3 got stuck in an endless crash/restart loop (making it look like there was a flashing underscore in the top left of the screen).
This is exactly the same issue I had last time, and I hoped that by now it would have been fixed. Luckily I found my backup drive and backed up before the upgrade, but right now I am booted into Ubuntu Live 14.10 and have configured my home server so that it is working as a router (so that Internet connectivity on my other devices still works).
Ubuntu Live DVD as Router
The first thing to do was to install vlan, cryptsetup, and lvm2.
Then I had to get my server working as a router so my other devices (like my iPad) had access to Google, so I need a DHCP server.
sudo apt-get install vlan cryptsetup lvm2 isc-dhcp-server cd /mnt sudo su mkdir HomeServer cryptsetup luksOpen /dev/sdg2 SSD vgchange -a y SSD mount /dev/SSD/Root HomeServer/ cd HomeServer/ cp etc/dhcp/dhcpd.conf /etc/dhcp/ service isc-dhcp-server restart cp etc/network/iptables.bak /etc/network/ iptables-restore < /etc/network/iptables.bak cd /mnt umount HomeServer nano /etc/sysctl.conf
net.ipv4.ip_forward=1 net.ipv4.conf.all.forwarding=1 net.ipv4.conf.default.forwarding=1
sysctl -p exit
I then opened up network-manager and configured eth1 and eth1.1 (VLAN) and eth1.2 (VLAN), giving them IP/netmask of 192.168.1.20/255.255.255.0, 192.168.2.20/255.255.255.0, and 192.168.3.20/255.255.255.0 respectively. I entered 184.108.40.206 as DNS server.
At this point my devices could access the Net again.
cd /mnt sudo mkdir HomeServer cd HomeServer sudo cryptsetup luksOpen /dev/sdb1 WDRED sudo cryptsetup luksOpen /dev/sdg2 SSD sudo vgchange -a y SSD sudo vgchange -a y WDRED sudo su mount /dev/SSD/Root . cd .. cd HomeServer mount /dev/sdg1 boot/ mount /dev/WDRED/Var var/ mount /dev/WDRED/Tmp tmp/ mount /dev/WDRED/RootHome root/ mount /dev/WDRED/Home home/ mount /dev/SSD/Usr usr/ mount /dev/WDRED/Opt opt/ mount --bind /dev dev/ mount --bind /dev/pts dev/pts/ mount --bind /proc proc/ mount --bind /sys sys/ mount --bind /run run/ LANG=C chroot /mnt/HomeServer
Attempting to Fix Things
First thing is to run apt-get update and apt-get dist-upgrade. Only fuse and libfuse2 were upgradeable.
Next is to edit /etc/network/interfaces because Jessie changes how MTU is calculated which prevented eth1, eth1.1 and eth1.1 from starting. Comment out all MTU-related lines.
Next is to remove the AMD Catalyst drivers. Press CTRL+Alt+F1 and then chroot again:
chroot /mnt/HomeServer/ sudo su - cd /usr/local/bin/ ./sgfxi -n
By using sgfxi, I can remove the existing driver and install the default driver.
After backing up /etc/network/ to an SD card, I exited both chroot environments, unmounted everything under /mnt/HomeServer I had mounted for the chroot envirinomnet,
vgchange -a n and
cryptsetup luksClose SSD and
cryptsetup luksClose WDRED, and then rebooted.
LVM Not Found
Instead of fixing things, I have made them worse. After a reboot I was expecting to be asked to enter the passphrases for my two LVMs and instead was met with an error that the LVMs weren't found. At this point I downloaded Debian 8.0 Live ISO and burned it to DVD.
I then booted to Debian Live.
I created a HomeServer chroot environment again, checked for updates again, and then I edited /etc/crypttab.
The reason LVM wasn't found is because things have changed: crypttab now requires that the LVM volume name be the same in crypttab.
Ergo, I had to replace sda1_crypt with WDRED, and sdb2_crypt with SSD, in /etc/crypttab.
Because an invalid crypttab results in no crypto modules being loaded at boot time, I needed to update initramfs.
sudo update-initramfs -u
There were still a few remaining issues on reboot. LVM/LUKS was working, and the boot process was now hanging at started manage install and generate color profiles.
The problem? My on-board ethernet adapter was not found. I logged on to BTWifi-with-FON from my laptop, Googled Realtek r8168, and downloaded the linux 64-bit driver (source) from www.realtek.com.tw (LINUX driver for kernel 3.x and 2.6.x and 2.4.x, updated 2015-05-14).
CTRL+ALT+F1 still worked on my home server, so I didn't need a Live DVD for the moment.
I copied the driver to an SD card, and then on my home server copied the driver to ~/. I then installed it:
tar xjf 00[tab] cd r8168[tab] sudo su - ./autorun.sh
I rebooted again, and this time it was hanging at NTP.
After CTRL+ALT+F1'ing again, I logged in, checked for updates with apt-get, and then removed ntp and installed openntpd.
sudo apt-get update sudo apt-get remove ntp sudo apt-get install openntpd
I then edited the GRUB config so that Jessie was the default (selected) boot option:
sudo nano /etc/default/grub
I then uninstalled (again) the AMD Catalyst drivers and installed the Debian open source drivers:
sudo apt-get purge fglrx* sudo rm /etc/X11/xorg.conf sudo apt-get install --reinstall xserver-xorg-core libgl1-mesa-glx:amd64 libgl1-mesa-glx:amd64 sudo dpkg-reconfigure xserver-xorg
Final Test Boot
Another reboot later, and this time the Gnome login screen appeared. A lot of things aren't starting on boot still and need starting/restarting/reloading manually.
Having said that, it may have taken a few days but my home server is now running Debian Jessie.
Hitting the same problem with Jessie Stable and Jessie Testing, I decided it would be best to persevere and get Jessie working this time otherwise my home server would gradually fall out of date software-wise.
One of the issues that has re-occurred (can't remember if I previously fixed it in Wheezy) is that logging in causes any hard disks in standby state to spin up. I am going to download my Twitter archive to see if I posted anything last June about this issue.