Package: upgrade-reports
Severity: important
Hello, I performed a wheezy->jessie upgrade on 3 different armel
devices yesterday.
Here are a few notes about some speed bumps that cropped up.
The devices in question are:
* Two QNAP TS-419P+ Turbo devices
* One QNAP TS-219P II Turbo device
I performed the upgrade using these steps:
* Purge removed packages with:
apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')
* Change "wheezy" to "jessie" in sources.list
* apt-get update
* apt-get upgrade
* apt-get dist-upgrade
* reboot
These are the issues I encountered:
** error: apt-get dist-upgrade broke during a flash-kernel
This happened on the two QNAP TS-419P+ devices but not on the QNAP
TS-219P II Turbo device. The "apt-get dist-upgrade" stage aborted in
a flash-kernel trigger that failed, because it seemed to try to flash
the jessie 3.16 kernel before it was properly unpacked. Unfortunately
I don't have the error message - I expected to capture it on the third
device but of course the error didn't happen there. It was something about
how it couldn't find the vmlinuz 3.16 file; it seemed confused about whether
it should flash the wheezy 3.2 or the jessie 3.16 kernel. During both the
"upgrade" and the "dist-upgrade" stage, there were probably between 5 and 10
runs of the flash-kernel trigger, which takes quite a long time.
I recovered by issuing an "apt-get -f install" which proceeded to unpack
several more packages and the later flash-kernel triggers succesfully flashed
a 3.16 kernel. Finally I re-ran "apt-get dist-upgrade" to wrap it up.
Full disclosure: on the failing machines I had an additional sources.list.d
entry for www.deb-multimedia.org jessie, which was not present on the machine
that didn't exhibit this error.
** frequent flash-kernel triggers
As mentioned about, on all the machines the flash-kernel trigger ran
frequently during the upgrade and dist-upgrade operations. Since this
takes several minutes, it would be ideal if this only happened once
during an upgrade or dist-upgrade run.
** odd entry in dmesg: "alg: hash: Test 3 failed for mv-sha1"
dmesg reveals some slightly concerning messages:
[ 35.120866] alg: hash: Test 3 failed for mv-sha1
[ 35.120895] 00000000: 10 bf d7 00 71 0b bb 83 3a 26 d0 97 13 05 99 f5
[ 35.120910] 00000010: 3a 92 53 3c
[ 35.216233] alg: hash: Test 1 failed for mv-hmac-sha1
[ 35.216262] 00000000: 0c aa 9f d5 37 c3 79 3a 91 d9 21 5f 42 2b 2c 24
[ 35.216277] 00000010: b7 c3 16 0c
This happens on all three machines. Not sure if this is a problem?
Never saw this on the wheezy kernel.
** journalctl permission / no journal found
It was not immediately obvious how to view systemd journals as a non-root
user, even being a member of the "root", "adm", "staff" groups. Apparently
the correct solution is to add the user to the group "systemd-journal".
The error message given, "no journals found", is also not very helpful in
diagnosing the problem. Perhaps something could be written about this in
the release notes.
** shutdown -rf now doesn't work anymore
Apparently systemd has removed the skip-fsck option to shutdown. The error
message given is not so pretty:
"Code should not be reached 'Unhandled option' at
../src/systemctl/systemctl.c:6316, function shutdown_parse_argv(). Aborting."
I guess the workaround is to just use "shutdown -r" and deal with potential
fsck delays. tune2fs is a too permanent solution to removing fscks; I miss
a way to prevent fscks in a one-shot fashion.
Also, it seems running "shutdown -r" now longer kicks out active ssh
sessions; instead other clients won't see the system going down until
they try to type in their session and get a broken pipe error back.
** bind9 ignores /etc/default/bind9 and starts on ipv6
It looks like systemd ignores /etc/default/bind9, which contains
OPTIONS="-u bind -4"
so bind9 starts up with both IPv4 and IPv6 enabled, which causes a LOT of
"named: error (network unreachable) resolving ...." log entries and possibly
delays.
I worked around this by hacking in an "-4" option into the ExecStart line of
/lib/systemd/system/bind9.service
** bitlbee /version identifies as "Linux/armv7l"
When issuing a /version command in irssi against a local bitlbee installation,
the response given back is "BitlBee-3.2.2-2. localhost Linux/armv7l", which
makes me wonder if the bitlbee binary is built for armv7 (debian armel
should be at armv5; uname -a gives armv5tel). It seems to work, so maybe
not a problem
** arpwatch does not start on boot
The arpwatch daemon no longer starts properly on boot. It logs the
following lines:
arpwatch[1052]: Running as uid=109 gid=105
arpwatch[1052]: Link layer type 113 not ethernet or fddi
and exits.
Manually restarting after the system has booted complete seems to work.
** apcupsd's /sbin/apcaccess is broken
Running "apcaccess" just prints a "Usage:" help text, instead
of dumping the UPS statistics. Looks like it was reported in
november 2014 with a patch but there is no followup in the bug tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770984
** apache 2.4 upgrade was tricky
The sites-available/sites-enabled files apparently must
end with ".conf". This could be made more explicit in the release notes,
which only talks about "conf.d". Had to manually rename all these files and
re-a2ensite them. This wasn't so bad since there was a lot of manual work
to fix mod_access_compat entries ("Allow from all") etc to the new Require
statements. mod_access_compat didn't do a very good job, because a lot of
local configuration files with Allow/Deny statements intende to override
defaults from the debian configuration files no longer worked, since
it looks like mod_access_compat statements no longer can "undo"
2.4-style Require lines in the default configuration files. So in a way,
not having the virtual hosts that were missing a ".conf" in their
site-available filenames active helped prevent misconfigured sites
from being served while the upgrade was still in progress.
** "db5.1-util" have been kept back
On one machine, I keep getting "The following packages have been kept back:"
db5.1-util
Not sure what that's about, maybe I should just remove it?
# apt-get -s install db5.1-util
The following packages will be REMOVED:
libdb5.1 python2.6
The following packages will be upgraded:
db5.1-util
# apt-get -s install db5.1-util libdb5.1
libdb5.1 is already the newest version.
db5.1-util : Breaks: libdb5.1 (< 5.1.29-8~) but 5.1.29-5 is to be installed
E: Unable to correct problems, you have held broken packages.
So, all-in-all, I survived the upgrade and things seem to be running OK,
but I'm glad I'm not new to Debian since there were a few snags along the
way. :)
Thanks,
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: armel (armv5tel)
Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=nb_NO.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
