Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots
Hi Michael, On Sun, 22 Jan 2017, Michael Biebl wrote: Am 22.01.2017 um 18:20 schrieb David Taylor: On Sun, 22 Jan 2017, Michael Biebl wrote: Am 22.01.2017 um 14:14 schrieb David Taylor: 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 built 232-13 from source, can you cherry-pick the upstream patch and see if that fixes your issue? We might then cherry-pick that patch in the official package as well. I can prepare packages if you prefer that. I cherry-picked the two commits referenced by the upstream issue #4747: d112eae7da77899be245ab52aa1747d4675549f1 device: Avoid calling unit_free(NULL) in device setup logic (#4748) c9d5c9c0e19eea79ca0f09fe58e5c0b76b8001e2 core: make unit_free() accept NULL pointers They have resolved the problem -- 232-13 plus those two patches is now running successfully on my machine. 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 Ah, ok. So this is a dual boot system, I assume. Yes, dual boot with Windows 10. Is /dev/sdb3 the partition holding the actual Windows 10 system? [1] suggests that the partition layout is System | MSR | Windows | Recovery Yes, it's the main Windows partition. If you boot Windows, what's the partion label shown there? Is it the default label created by the Windows installer? blkid shows: /dev/sdb1: LABEL="SYSTEM" UUID="5C7A-5FAE" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="8bc4e64e-f2b7-47da-8048-ab445242bf /dev/sdb2: PARTLABEL="Microsoft reserved partition" PARTUUID="dd5c4d6d-dd1b-4908-b83e-e6b44d12ca63" /dev/sdb3: LABEL="win550s" UUID="886450D76450C998" TYPE="ntfs" PARTLABEL="†††" PARTUUID="77178a46-30b6-11e5-9bd1-5ce0c5c724c2" Windows displayes the volume label as win550s (which I set, manually when installing). For some reason the GPT partition label has been set to †††, although the two other Windows partitions have sensible partition labels. -- David Taylor
Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots
Control: found -1 232-8 Hi David Am 22.01.2017 um 18:20 schrieb 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.) Ok, marking this accordingly as found in 232-8. Otherwise 232-13 won't migrate to testing. > 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 built 232-13 from source, can you cherry-pick the upstream patch and see if that fixes your issue? We might then cherry-pick that patch in the official package as well. I can prepare packages if you prefer that. >> 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 Ah, ok. So this is a dual boot system, I assume. Is /dev/sdb3 the partition holding the actual Windows 10 system? [1] suggests that the partition layout is System | MSR | Windows | Recovery If you boot Windows, what's the partion label shown there? Is it the default label created by the Windows installer? The reason I'm asking is that I want to get a better idea which / how many users are affected. Regards, Michael [1] https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots
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@ (Sun 2017-01-22 12:59:45 GMT): systemd[1]: Caught , dumped core as pid 1535. Message from syslogd@ Jan 22 12:59:45 ... systemd[1]: Caught , dumped core as pid 1535. Broadcast message from systemd-journald@ (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 0x7f7f747302f7 in kill () at ../sysdeps/unix/syscall-template.S:84 #1 0x560a0a3188aa in crash (sig=6) at ../src/core/main.c:189 #2 #3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #4 0x7f7f7473140a in __GI_abort () at abort.c:89 #5 0x7f7f75ebd4c2 in log_assert_failed (text=, file=, line=, func=) at ../src/basic/log.c:795 #6 0x560a0a3838c1 in unit_free (u=) at ../src/core/unit.c:521 #7 0x560a0a32c4a0 in device_setup_unit.lto_priv.274 (m=m@entry=0x560a0ab5e800, dev=dev@entry=0x560a0ac26690, path=path@entry=0x560a0ac2cef0 "/dev/disk/by-partlabel/", '†' , main=main@entry=false) at ../src/core/device.c:369 #8 0x560a0a32cc20 in device_process_new.lto_priv.276 (m=0x560a0ab5e800, dev=0x560a0ac26690) at ../src/core/device.c:420 #9 0x560a0a36bf15 in device_enumerate.lto_priv.149 (m=0x560a0ab5e800) at ../src/core/device.c:689 #10 0x560a0a360a1f in manager_enumerate (m=) at ../src/core/manager.c:1141 #11 0x560a0a312389 in manager_startup (fds=0x560a0ab5f2d0, serialization=, m=0x560a0ab5e800) at ../src/core/manager.c:1269 #12 main (argc=4, argv=) 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
Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots
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? > During upgrade or boot systemd aborts due to an assertion failure: > > Broadcast message from systemd-journald@ (Sun 2017-01-22 12:59:45 GMT): > systemd[1]: Caught , dumped core as pid 1535. > Message from syslogd@ Jan 22 12:59:45 ... > systemd[1]: Caught , dumped core as pid 1535. > > Broadcast message from systemd-journald@ (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. The above bug report suggests a problem with unicode partition labels. Do you have such a partition? Can you reproduce the problem reliably? Do you know how we can reproduce the problem? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots
Package: systemd Version: 232-13 Severity: critical Justification: breaks the whole system Currently running systemd_231-9, first experienced this problem when trying to upgrade to 232-8, 232-13 is still giving the same problem. During upgrade or boot systemd aborts due to an assertion failure: Broadcast message from systemd-journald@ (Sun 2017-01-22 12:59:45 GMT): systemd[1]: Caught , dumped core as pid 1535. Message from syslogd@ Jan 22 12:59:45 ... systemd[1]: Caught , dumped core as pid 1535. Broadcast message from systemd-journald@ (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 -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.11.0-1 ii libaudit1 1:2.6.7-1 ii libblkid1 2.29-1 ii libc6 2.24-8 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.5-2 ii libgpg-error0 1.26-1 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-4 ii libkmod223-2 ii liblz4-10.0~r131-2 ii liblzma55.2.2-1.2 ii libmount1 2.29-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii libsystemd0 232-13 ii mount 2.29-1 ii util-linux 2.29-1 Versions of packages systemd recommends: ii dbus1.10.14-1 ii libpam-systemd 232-13 Versions of packages systemd suggests: ii policykit-10.105-17 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.126 ih udev 232-13 -- no debconf information
