Created attachment 1106503 [details] journalctl output for the upgrade While doing a system upgrade from F21 to F23, plymouthd dumped core, and the system upgrade failed to complete. The system was left in a reasonably ok state, but I have no idea what upgrade actions did not complete. I have certainly had lots of issues with KDE5, but this might not be related. I will attach the log for the upgrade boot from journalctl.
The last message from rpm is: Dec 12 06:02:03 edison dnf[1263]: Verifying: hibernate-validator-5.0.1-2.fc21.noarch 5235/8033 It seems that the upgrade was essentially complete at that point. Dec 12 06:02:06 edison systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=6/ABRT Dec 12 06:02:06 edison systemd[1]: plymouth-start.service: Unit entered failed state. Dec 12 06:02:06 edison systemd[1]: plymouth-start.service: Failed with result 'core-dump'. Dec 12 06:02:08 edison systemd-coredump[18586]: Process 454 (plymouthd) of user 0 dumped core. Stack trace of thread 454: #0 0x00007efda9c148d7 n/a (/usr/lib64/libc-2.20.so (deleted)) Dec 12 03:20:47 edison kernel: perl[16259]: segfault at 5 ip 00007f0f6b415e0e sp 00007fff9cd6cbd0 error 4 in LibXML.so[7f0f6b3 d3000+69000] Dec 12 03:20:47 edison kernel: perl[16261]: segfault at 5 ip 00007f508f568e0e sp 00007ffcef84eee0 error 4 in LibXML.so[7f508f5 26000+69000] Dec 12 03:20:47 edison dnf[1263]: Upgrading : perl-XML-SAX-0.99-15.fc23.noarch 1599/8033 Dec 12 03:20:47 edison dnf[1263]: /var/tmp/rpm-tmp.P8SL2P: line 1: 16259 Segmentation fault (core dumped) perl -MXML::SAX -e "XML::SAX->add_parser(q($p))->save_parsers()" 2> /dev/null Dec 12 03:20:47 edison dnf[1263]: /var/tmp/rpm-tmp.P8SL2P: line 1: 16261 Segmentation fault (core dumped) perl -MXML::SAX -e "XML::SAX->add_parser(q($p))->save_parsers()" 2> /dev/null Dec 12 03:20:48 edison dnf[1263]: Upgrading : perl-XML-LibXML-1:2.0121-6.fc23.x86_64 1600/8033 Dec 12 03:20:48 edison systemd-coredump[16260]: Process 16259 (perl) of user 0 dumped core. Stack trace of thread 16259: #0 0x00007f0f6b415e0e n/a (/usr/lib64/perl5/vendor_perl/auto/XML/LibXML/LibXML.so) Dec 12 03:20:49 edison systemd-coredump[16262]: Process 16261 (perl) of user 0 dumped core. Stack trace of thread 16261: #0 0x00007f508f568e0e n/a (/usr/lib64/perl5/vendor_perl/auto/XML/LibXML/LibXML.so) This smells like memory corruption issue of some sort. Did you run memtest?
Thanks, I'll run memtest tonight overnight to check.
Ran memtest overnight. In 10 hours and a full pass, there were no errors. Is there anything else that could cause this problem?
I have no futher ideas. I can imagine that if the one of the libraries was corrupted in the filesystem or in memory we could see effect like that, but there's nothing in the logs you attached to support this theory. The scriptlet for perl-XML-LibXML is: if [ $1 -eq 0 ] ; then for p in XML::LibXML::SAX::Parser XML::LibXML::SAX ; do perl -MXML::SAX -e "XML::SAX->remove_parser(q($p))->save_parsers()" \ 2>/dev/null || : done fi Both this and plymouth segfaulted, and those things seem unrelated.
Yes its very strange. I'm gonna run Prime95 to see if it shows any hardware issues. Can the upgrade process deal more gracefully with a failure in plymouth? Perhaps rather than simply failing and rebooting, the user could be asked whether they wish to continue, or be dumped to a shell for debugging?
It should be fine with plymouth going away, I don't know what started the shutdown sequence. There's definitely a bug in the service file, and the upgrade process should have DefaultDependencies=no. It's on my todo list ;)
Created attachment 1112209 [details] journalctl output for upgrade on another system I got the plymouth core dump on a second system being upgraded from F21 to F23.
Created attachment 1140839 [details] log from the system-upgrade run It seems like I have been hit by this as well upgrading a KDE-spin system from F21 to F23. The new bootmeny entry has been created but I cant use it, all I get a is a blck screen with a huge cross as mouse pointer after a couple of minutes. The old kernel seems to work so far with all the new packages that were installed.
Did not have this issue on upgrade Fedora 23 -> 24. Closing.