debdiff for Xenial ** Patch added: "xenial.debdiff" https://bugs.launchpad.net/ubuntu/xenial/+source/friendly-recovery/+bug/1766872/+attachment/5196250/+files/xenial.debdiff
-- 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/1766872 Title: 'Enable Network' in recovery mode not working properly. Status in friendly-recovery package in Ubuntu: In Progress Status in systemd package in Ubuntu: Won't Fix Status in friendly-recovery source package in Xenial: Confirmed Status in systemd source package in Xenial: Won't Fix Status in friendly-recovery source package in Bionic: Confirmed Status in systemd source package in Bionic: Won't Fix Status in friendly-recovery source package in Cosmic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in friendly-recovery source package in DD-Series: Confirmed Status in systemd source package in DD-Series: Won't Fix Bug description: This bug has been noticed after the introduction of the fix of (LP: #1682637) in Bionic. I have notice a block in Bionic when choosing 'Enable Network' option in recovery mode on different bionic vanilla system and I can reproduce all the time. I also asked colleagues to give it a try (for a second pair of eye on this) and they have the same result as me. Basically, when choosing 'Enable Network' it get block or lock. If we hit 'ctrl-c', then a shell arrive and the system has network connectivity. Here's what I find while enabling "systemd.debug-shell=1" from vtty9 : # pstree systemd-+-bash---pstree |-recovery-menu---network---systemctl---systemd-tty-ask |-systemd-journal .... # ps root 486 473 0 08:29 tty1 00:00:00 /bin/systemd-tty-ask-password-agent root 473 486 0 08:29 tty1 00:00:00 systemctl start dbus.socket root 486 283 0 08:29 tty1 00:00:00 /bin/sh /lib/recovery- mode/options/network Additionally, systemd-analyze blame: "Bootup is not yet finished. Please try again later" "systemctl list-jobs" is showing a 100 jobs in 'waiting' state The only 'running' unit is friendly-recovery.service : 52 friendly-recovery.service start running The rest are all "waiting". My understanding is that "waiting" units will be executed only after those which are "running" are completed. Which explain why the "ctlr-c" allow the boot to continue. All the systemd special unit important at boot-up are waiting. 7 sysinit.target start waiting 3 basic.target start waiting ..... Seems like systemd is not fully initialise in 'Recovery Mode' and doesn't allow any 'systemctl start' operation without password/passphrase request, which I suspect is hidden by the recovery-mode menu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1766872/+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
