Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots

[David Taylor]

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 at 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 at 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 at entry=0x560a0ab5e800, dev=dev at entry=0x560a0ac26690,
    path=path at entry=0x560a0ac2cef0 "/dev/disk/by-partlabel/", '†' <repeats 35 times>, main=main at 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