On Sun, 22 Jan 2017, Michael Biebl wrote:
Control: tags -1 + moreinfo
Am 22.01.2017 um 14:14 schrieb David Taylor:
Currently running systemd_231-9, first experienced this problem when
trying to upgrade to 232-8, 232-13 is still giving the same problem.
Upgrading from -9 to -8? I guess you mistyped this.
What is the first version you encountered the problem? Which version was
still working fine? Were other changes made to the system?
No typo - the first failed upgrade was from 231-9 to 232-8. Nothing
else changed at that time (except other package upgrades, but they seem
irrelevant, given that downgrading to 231-9 leaves a working system and
upgrading to either 232-8 or 232-13 leaves it failing to boot.)
During upgrade or boot systemd aborts due to an assertion failure:
Broadcast message from systemd-journald@<host> (Sun 2017-01-22 12:59:45 GMT):
systemd[1]: Caught <ABRT>, dumped core as pid 1535.
Message from syslogd@<host> Jan 22 12:59:45 ...
systemd[1]: Caught <ABRT>, dumped core as pid 1535.
Broadcast message from systemd-journald@<host> (Sun 2017-01-22 12:59:45 GMT):
systemd[1]: Freezing execution.
Message from syslogd@deb550s at Jan 22 12:59:45 ...
systemd[1]: Freezing execution.
syslog shows:
systemd[1]: Assertion 'u' failed at ../src/core/unit.c:521, function
unit_free(). Aborting.
A similar problem appears to have been fixed upstream:
https://github.com/systemd/systemd/issues/4747
Can you attach the core file (should be found at /core) from the crash
with the exact systemd version you were using.
I built the systemd_232-13 package locally from source, so I'm not sure how
useful the core file would be to you. I have reproduced the backtrace below.
If you need any more details (or feel the core would still be useful) let me
know.
Reading symbols from /bin/systemd...Reading symbols from
/usr/lib/debug/.build-id/24/30880e7d50808599be7bb2bafe54dab1a14bb8.debug...done.
done.
[New LWP 5370]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/lib/systemd/systemd --system --deserialize 19'.
Program terminated with signal SIGABRT, Aborted.
(gdb) bt
#0 0x00007f7f747302f7 in kill () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000560a0a3188aa in crash (sig=6) at ../src/core/main.c:189
#2 <signal handler called>
#3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#4 0x00007f7f7473140a in __GI_abort () at abort.c:89
#5 0x00007f7f75ebd4c2 in log_assert_failed (text=<optimized out>, file=<optimized
out>, line=<optimized out>,
func=<optimized out>) at ../src/basic/log.c:795
#6 0x0000560a0a3838c1 in unit_free (u=<optimized out>) at
../src/core/unit.c:521
#7 0x0000560a0a32c4a0 in device_setup_unit.lto_priv.274
(m=m@entry=0x560a0ab5e800, dev=dev@entry=0x560a0ac26690,
path=path@entry=0x560a0ac2cef0 "/dev/disk/by-partlabel/", '†' <repeats 35
times>, main=main@entry=false)
at ../src/core/device.c:369
#8 0x0000560a0a32cc20 in device_process_new.lto_priv.276 (m=0x560a0ab5e800,
dev=0x560a0ac26690) at ../src/core/device.c:420
#9 0x0000560a0a36bf15 in device_enumerate.lto_priv.149 (m=0x560a0ab5e800) at
../src/core/device.c:689
#10 0x0000560a0a360a1f in manager_enumerate (m=<optimized out>) at
../src/core/manager.c:1141
#11 0x0000560a0a312389 in manager_startup (fds=0x560a0ab5f2d0,
serialization=<optimized out>, m=0x560a0ab5e800)
at ../src/core/manager.c:1269
#12 main (argc=4, argv=<optimized out>) at ../src/core/main.c:1774
The above bug report suggests a problem with unicode partition labels.
Do you have such a partition?
I didn't think so, but double-checking in /dev/disk/by-partlabel shows I do
have an NTFS partition with the label †††††††††††††††††††††††††††††††††††:
# ls -l /dev/disk/by-partlabel/
total 0
lrwxrwxrwx 1 root root 10 Jan 22 13:19 ††††††††††††††††††††††††††††††††††† ->
../../sdb3
lrwxrwxrwx 1 root root 10 Jan 22 13:19 EFI\x20system\x20partition -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 22 13:19 Microsoft\x20reserved\x20partition ->
../../sdb2
I'm not sure where that PARTLABEL came from (I definitely didn't choose
it), but the filesystem is part of a Windows 10 install.
Can you reproduce the problem reliably? Do you know how we can reproduce
the problem?
Yes, the problem occurs every time I upgrade the package (or reboot with
the upgraded package installed). I assume you could reboot it by
creating an NTFS filesystem with PARTLABEL="†††††††††††††††††††††††††††††††††††"
--
David Taylor
