Bug#770752: upgrade-reports: wheezy->jessie upgrade: systemd emerg mode because of unpurged package
Package: upgrade-reports
Severity: normal
I upgraded wheezy->jessie with "apt-get -s dist-upgrade". The apt-get
failed and I needed several rounds of this to complete the upgrade:
# dpkg --configure -a
# apt-get install -f
# apt-get autoremove
But that's just background info. This upgrade also installed systemd.
After checking with ...
# apt-get update
# apt-get dist-upgrade
... to make sure there were no unfinished things, I rebooted. The
system came up, but systemd came up in emergency mode.
This wasn't a welcome development. I had been avoiding getting
embroiled in the public arguments about the merits of systemd and was
basically neutral about it. I got the feeling though that my
neutrality was about to change.
I authenticated as root (with some difficulty; systemd appeared still
to be checking local filesystems in parallel, and these processes were
writing to the console) and tried out the diagnostic commands systemd
suggested (for examining its journal). The result was quite
unexpected.
The journal contained a summary of systemd's attempts to start various
subsystems. Most of the problems in the log related to hald. A
minute's web research showed that since this is now obsolete, the fix
is to uninstall it. I uninstalled it and rebooted.
The second time, I was returned to emergency mode; two services had
failed:
console-kit-log-system-start.service
ebtables.service
The ebtables package was uninstalled (in state "rc" according to dpkg
-l). I don't remember when I uninstalled it. Perhaps it was
uninstalled by one of the invocations of "apt-get autoremove" above.
Purging the ebtables package fixed one of the two problems.
Unsettlingly though this made the other (apparently entirely
unrelated) service flip from broken to working, so all was suddenly
well.
For a first experience with systemd, I think this went reasonably
well, for me. But for a non-power-user to update from SYSV-style init
to systemd seems a stretch, at least if my experience is typical.
Anyway, once I'd booted again and logged in, everything seems to be
working.
According to etckeeper, the version of ebtables I purged was
2.0.9.2-2.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Reply to: