** Description changed: [Impact] * network menu in recovery mode doesn't work correctly, blocking at starting systemd services depends to enable networking. [Test Case] * Boot w/ Xenial or Bionic in recovery mode via grub * Choose "network" in friendly-recovery menu The network won't be activated and it'll be stuck at systemd-tty-ask- password : # pstree systemd-+-bash---pstree |-recovery-menu---network---systemctl---systemd-tty-ask [Regression Potential] * Low. * 'resume' option fails to 'resume' boot now, but I think it can still be fix later on as the system can be rebooted with other alternatives such as entering the 'root' option and reboot or reset, poweroff the machines, instances, ... I think it's more important to have a network working in friendly-recovery than being able to resume it at the moment. The tradeoff is worth it IMHO. * All other options works fine as expected. * Cosmic has the same changes already in place. + + After verification the 'resume' has the same effect before that change, + it boots up but still seems to stick in 'recovery' option according to + /proc/cmdline. [Other Info] * Upstream : https://bazaar.launchpad.net/~ubuntu-core-dev/friendly-recovery/ubuntu/changes/161?start_revid=161 Revision 154 to 161 [Original 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.
** Description changed: [Impact] * network menu in recovery mode doesn't work correctly, blocking at starting systemd services depends to enable networking. [Test Case] * Boot w/ Xenial or Bionic in recovery mode via grub * Choose "network" in friendly-recovery menu The network won't be activated and it'll be stuck at systemd-tty-ask- password : # pstree systemd-+-bash---pstree |-recovery-menu---network---systemctl---systemd-tty-ask [Regression Potential] * Low. * 'resume' option fails to 'resume' boot now, but I think it can still be fix later on as the system can be rebooted with other alternatives such as entering the 'root' option and reboot or reset, poweroff the machines, instances, ... I think it's more important to have a network working in friendly-recovery than being able to resume it at the moment. The tradeoff is worth it IMHO. * All other options works fine as expected. * Cosmic has the same changes already in place. - After verification the 'resume' has the same effect before that change, - it boots up but still seems to stick in 'recovery' option according to - /proc/cmdline. + After verification the 'resume' has the same effect before/after that + change, it boots up but still seems to stick in 'recovery' option + according to /proc/cmdline. [Other Info] * Upstream : https://bazaar.launchpad.net/~ubuntu-core-dev/friendly-recovery/ubuntu/changes/161?start_revid=161 Revision 154 to 161 [Original 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. ** Description changed: [Impact] * network menu in recovery mode doesn't work correctly, blocking at starting systemd services depends to enable networking. [Test Case] * Boot w/ Xenial or Bionic in recovery mode via grub * Choose "network" in friendly-recovery menu The network won't be activated and it'll be stuck at systemd-tty-ask- password : # pstree systemd-+-bash---pstree |-recovery-menu---network---systemctl---systemd-tty-ask [Regression Potential] - * Low. - * 'resume' option fails to 'resume' boot now, but I think it can still be fix later on as the system can be rebooted with other alternatives such as entering the 'root' option and reboot or reset, poweroff the machines, instances, ... I think it's more important to have a network working in friendly-recovery than being able to resume it at the moment. The tradeoff is worth it IMHO. + * Low. * All other options works fine as expected. * Cosmic has the same changes already in place. - After verification the 'resume' has the same effect before/after that - change, it boots up but still seems to stick in 'recovery' option - according to /proc/cmdline. + * According to xnox, resume option fails to boot now. + After verification the 'resume' has the same effect before/after that change, it boots up but still seems to stick in 'recovery' option according to /proc/cmdline so I don't see any obvious behaviour change before and after. [Other Info] * Upstream : https://bazaar.launchpad.net/~ubuntu-core-dev/friendly-recovery/ubuntu/changes/161?start_revid=161 Revision 154 to 161 [Original 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. ** Description changed: [Impact] * network menu in recovery mode doesn't work correctly, blocking at starting systemd services depends to enable networking. [Test Case] * Boot w/ Xenial or Bionic in recovery mode via grub * Choose "network" in friendly-recovery menu The network won't be activated and it'll be stuck at systemd-tty-ask- password : # pstree systemd-+-bash---pstree |-recovery-menu---network---systemctl---systemd-tty-ask [Regression Potential] * Low. - * All other options works fine as expected. + * All options works fine. * Cosmic has the same changes already in place. * According to xnox, resume option fails to boot now. After verification the 'resume' has the same effect before/after that change, it boots up but still seems to stick in 'recovery' option according to /proc/cmdline so I don't see any obvious behaviour change before and after. [Other Info] * Upstream : https://bazaar.launchpad.net/~ubuntu-core-dev/friendly-recovery/ubuntu/changes/161?start_revid=161 Revision 154 to 161 [Original 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1766872 Title: 'Enable Network' in recovery mode not working properly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1766872/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
