[Touch-packages] [Bug 1923377] Re: Automatically installed systemd:i386 makes graphical boot hang
[Expired for systemd (Ubuntu) because there has been no activity for 60 days.] ** Changed in: systemd (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1923377 Title: Automatically installed systemd:i386 makes graphical boot hang Status in systemd package in Ubuntu: Expired Bug description: 1) Description: Ubuntu 20.04.2 LTS Release: 20.04 2) systemd:i386 (245.4-4ubuntu3.6, automatic) systemd:amd64 (245.4-4ubuntu3.6, automatic) 3) I expected that letting the system install/upgrade packages it suggested would cause no harm. 4) Harm was caused. Graphical boot got stuck after the grub menu. But I could access virtual console be pressing alt-F1. I accepted the upgrade on Saturday, on Sunday, when tried to boot the machine, the machine hung up. I suspect that one of the problematic packages was systemd:i386. I have no idea why a 32bit version of this got installed, and other 32bit versions as well. I attached an excerpt from /var/log/apt/history.log showing the problematic upgrade. One of the results was that the binaries /usr/bin/systemctl and /lib/systemd/systemd were 32bit executables, and they could not load appropriate the pam modules (which were still 64bit). But as I could log in from the virtual terminal just fine, this showed that pam itself was working, systemd was the problem. After long struggle I managed to fix this by reinstalling systemd, which overwrote the above binaries with their 64bit versions. Removing systemd:i386 would have deleted systemd altogether. After that I purged various 32bit packages I suspected were causing problems. And I installed the packages removed by the upgrade on Saturday, such as snapd. Now the system boots up in graphical mode just fine. But why did the 32bit versions of systemd etc got installed automatically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923377/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1923377] Re: Automatically installed systemd:i386 makes graphical boot hang
Since nobody else seems to have this problem, and I managed to fix my system, I suggest that this can be closed. For the record, I suspect that the inclusion of i386 packages started with the installation of the wine package. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1923377 Title: Automatically installed systemd:i386 makes graphical boot hang Status in systemd package in Ubuntu: Incomplete Bug description: 1) Description: Ubuntu 20.04.2 LTS Release: 20.04 2) systemd:i386 (245.4-4ubuntu3.6, automatic) systemd:amd64 (245.4-4ubuntu3.6, automatic) 3) I expected that letting the system install/upgrade packages it suggested would cause no harm. 4) Harm was caused. Graphical boot got stuck after the grub menu. But I could access virtual console be pressing alt-F1. I accepted the upgrade on Saturday, on Sunday, when tried to boot the machine, the machine hung up. I suspect that one of the problematic packages was systemd:i386. I have no idea why a 32bit version of this got installed, and other 32bit versions as well. I attached an excerpt from /var/log/apt/history.log showing the problematic upgrade. One of the results was that the binaries /usr/bin/systemctl and /lib/systemd/systemd were 32bit executables, and they could not load appropriate the pam modules (which were still 64bit). But as I could log in from the virtual terminal just fine, this showed that pam itself was working, systemd was the problem. After long struggle I managed to fix this by reinstalling systemd, which overwrote the above binaries with their 64bit versions. Removing systemd:i386 would have deleted systemd altogether. After that I purged various 32bit packages I suspected were causing problems. And I installed the packages removed by the upgrade on Saturday, such as snapd. Now the system boots up in graphical mode just fine. But why did the 32bit versions of systemd etc got installed automatically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923377/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1923377] Re: Automatically installed systemd:i386 makes graphical boot hang
Sorry, providing a couple lines from the apt update history log isn't enough for anyone to be able to analyze anything. You can try attaching your full journal logs, and the full apt and dpkg logs would help as well, but even the logs may not help and more complete system configuration data may be needed. ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1923377 Title: Automatically installed systemd:i386 makes graphical boot hang Status in systemd package in Ubuntu: Incomplete Bug description: 1) Description: Ubuntu 20.04.2 LTS Release: 20.04 2) systemd:i386 (245.4-4ubuntu3.6, automatic) systemd:amd64 (245.4-4ubuntu3.6, automatic) 3) I expected that letting the system install/upgrade packages it suggested would cause no harm. 4) Harm was caused. Graphical boot got stuck after the grub menu. But I could access virtual console be pressing alt-F1. I accepted the upgrade on Saturday, on Sunday, when tried to boot the machine, the machine hung up. I suspect that one of the problematic packages was systemd:i386. I have no idea why a 32bit version of this got installed, and other 32bit versions as well. I attached an excerpt from /var/log/apt/history.log showing the problematic upgrade. One of the results was that the binaries /usr/bin/systemctl and /lib/systemd/systemd were 32bit executables, and they could not load appropriate the pam modules (which were still 64bit). But as I could log in from the virtual terminal just fine, this showed that pam itself was working, systemd was the problem. After long struggle I managed to fix this by reinstalling systemd, which overwrote the above binaries with their 64bit versions. Removing systemd:i386 would have deleted systemd altogether. After that I purged various 32bit packages I suspected were causing problems. And I installed the packages removed by the upgrade on Saturday, such as snapd. Now the system boots up in graphical mode just fine. But why did the 32bit versions of systemd etc got installed automatically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923377/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
