-
Notifications
You must be signed in to change notification settings - Fork 0
/
ubuntu-dist-upgrade-aftermath.html
1 lines (1 loc) · 4.02 KB
/
ubuntu-dist-upgrade-aftermath.html
1
<!doctype html><meta charset=utf-8><title>make</title><meta content="Thomas Duboucher" name=author><meta content="Thomas Duboucher, Serianox,blog" name=keywords><meta content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no" name=viewport><link href=style.css rel=stylesheet><h1 id=ubuntu-dist-upgrade-aftermath>Ubuntu <code>dist-upgrade</code> aftermath</h1><p>I wanted to upgrade my laptop from <em>Ubuntu Zeisty Zapus</em> (17.04) to <em>Ubuntu Artful Aardvak</em> (17.10). The process is usually pretty straightforward, and I am now lazy enough to do it from the gui. I started the upgrade and locked my computer as I left.<h2 id=first-mistake>First mistake</h2><p>I quickly noticed that the lock screen was not working properly. One <code>Ctrl + F1</code> and <code>ps auxf</code> later confirmed my thought, as I saw that the dist upgrade process was running a task every 30s to prevent the lock screen from appearing.<p>A few minutes later, I could see that the upgrade process was nearly finished, but hanged as a graphical process was asking for a confirmation during a dpkg configure. I tried to kill the lockscreen or the configuration process, but nothing worked, and I was left with no solution but to force shutdown my latop.<h2 id=second-mistake>Second mistake</h2><p>Upon reboot and after asking my passphrase to decrypt my harddrive, I was disappointed to notice that the boot process hanged. Without any way to know what was happening. Moreover, since my laptop has an UEFI, it was difficult to reboot to Grub in order to drop into a recovery shell.<p>From Grub, I was then able to reboot my laptop with a console output to discover what was going on. And it wasn’t pretty. Some systemd daemon would fail to start due to cyclic dependencies in their configuration files, or respective dependencies.<p>Of course, it is perfectly fine to forbid login if the thermal sensor daemon fails to start.<p><img src=ubuntu1.jpg><h2 id=repair>Repair</h2><p>Fixing was pretty easy. Or it should have been. Or it was, before. Basically, one would spawn a recovery shell, then restarting <code>dpkg --configure -a</code> to finish OS configuration, and then reboot.<p>However, the configuration process failed at some point. Some package where not configured due to an unconfigured dependency, <em>anacron</em>. Running <code>dpkg --configure</code>, then <code>ps auxf</code>, I saw that the configuration process was hanging on <code>systemd-tty-ask-password-agent</code>. Running as root. Headless.<p>I attempted to do the same, through <em>aptitude</em> this time. Starting the network would fail, as <code>/etc/resolv.conf</code> was missing because systemd was not working. It was fun to repair name resolution, but this still wasn’t enough to be able to reconnect to a wifi network.<h2 id=success>Success</h2><p>I was ready to backup, reformat, reinstall. This was way faster than fixing this clusterfuck. However, after reconfiguring most of the packages, I was finally able to boot a non-working GDM up to login screen, which then started the wifi and reconnected to my home network. I immediatly returned to a tty, ran <em>aptitude</em> to restart installation and configuration, and reboot with 50% chance of success. And I am now writting this on my newly installed <em>Artful Aardvak</em><p>I still have no idea how I managed to pull this.<h2 id=conclusion>Conclusion</h2><p>First, for and end user, something as simple as an upgrade should not fail with something as simple as locking the screen.<p>Second, it is surprising that something as critical as the process of installing a core package should depend on something as complex and fragile as systemd. Even more as it was a hidden dependency.<p>I found firsthand that fixing systemd from a recovery shell is an impossible task. Either you are lucky, or you are left with reinstalling everything.<p>The only thing that helped me is that once you get through or around sytemd, you are still using a Unix. And you can still rely on something as robust as <em>dpkg</em>.<blockquote><p>User-friendly mon cul.</blockquote>