| 2018-04-25 13:26:36 |
Eric Desrochers |
bug |
|
|
added bug |
| 2018-04-25 13:26:57 |
Eric Desrochers |
friendly-recovery (Ubuntu): importance |
Undecided |
High |
|
| 2018-04-25 13:28:50 |
Eric Desrochers |
bug task added |
|
systemd (Ubuntu) |
|
| 2018-04-25 13:32:31 |
Eric Desrochers |
tags |
|
sts |
|
| 2018-04-25 14:28:10 |
Eric Desrochers |
description |
This bug has been introduced by 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
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. |
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
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. |
|
| 2018-04-25 14:48:55 |
Eric Desrochers |
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
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. |
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. |
|
| 2018-04-27 13:53:38 |
Eric Desrochers |
systemd (Ubuntu): status |
New |
Won't Fix |
|
| 2018-04-30 22:57:31 |
Brian Murray |
tags |
sts |
rls-bb-incoming sts |
|
| 2018-04-30 22:58:09 |
Launchpad Janitor |
friendly-recovery (Ubuntu): status |
New |
Confirmed |
|
| 2018-05-02 19:01:43 |
Eric Desrochers |
branch linked |
|
lp:~slashd/friendly-recovery/lp1766872 |
|
| 2018-05-10 16:19:38 |
Jake Harr |
bug |
|
|
added subscriber Jake Harr |
| 2018-05-31 12:35:30 |
Francis Ginther |
tags |
rls-bb-incoming sts |
id-5afda46ded21519fcf26f22b rls-bb-incoming sts |
|
| 2018-08-20 10:41:18 |
Bougron |
attachment added |
|
dmesg trace https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1766872/+attachment/5177864/+files/TRACE.txt |
|
| 2018-08-20 13:32:05 |
Bougron |
attachment added |
|
T.txt https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1766872/+attachment/5178023/+files/T.txt |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
nominated for series |
|
Ubuntu Dd-series |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
bug task added |
|
friendly-recovery (Ubuntu Dd-series) |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
bug task added |
|
systemd (Ubuntu Dd-series) |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
bug task added |
|
friendly-recovery (Ubuntu Bionic) |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
bug task added |
|
systemd (Ubuntu Bionic) |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
bug task added |
|
friendly-recovery (Ubuntu Cosmic) |
|
| 2018-09-28 12:05:03 |
Eric Desrochers |
bug task added |
|
systemd (Ubuntu Cosmic) |
|
| 2018-09-28 12:05:24 |
Eric Desrochers |
systemd (Ubuntu Bionic): status |
New |
Won't Fix |
|
| 2018-09-28 12:05:27 |
Eric Desrochers |
systemd (Ubuntu Dd-series): status |
New |
Won't Fix |
|
| 2018-09-28 12:06:13 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): status |
New |
Confirmed |
|
| 2018-09-28 12:06:16 |
Eric Desrochers |
friendly-recovery (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2018-09-28 12:06:30 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): importance |
High |
Medium |
|
| 2018-09-28 12:06:32 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): importance |
Undecided |
Medium |
|
| 2018-09-28 12:06:33 |
Eric Desrochers |
friendly-recovery (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2018-09-28 12:06:38 |
Eric Desrochers |
friendly-recovery (Ubuntu Bionic): importance |
Medium |
Low |
|
| 2018-09-28 12:06:40 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): importance |
Medium |
Low |
|
| 2018-09-28 12:06:41 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): importance |
Medium |
Low |
|
| 2018-09-28 12:07:48 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-09-28 12:08:05 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): assignee |
Eric Desrochers (slashd) |
|
|
| 2018-09-29 22:09:33 |
Saroumane |
bug |
|
|
added subscriber Saroumane |
| 2018-10-02 22:13:56 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-10-02 22:13:58 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-10-02 22:14:01 |
Eric Desrochers |
friendly-recovery (Ubuntu Bionic): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-10-02 22:14:09 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-10-02 22:14:09 |
Eric Desrochers |
bug task added |
|
friendly-recovery (Ubuntu Xenial) |
|
| 2018-10-02 22:14:09 |
Eric Desrochers |
bug task added |
|
systemd (Ubuntu Xenial) |
|
| 2018-10-02 22:14:25 |
Eric Desrochers |
friendly-recovery (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2018-10-02 22:14:25 |
Eric Desrochers |
friendly-recovery (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-10-02 22:14:36 |
Eric Desrochers |
friendly-recovery (Ubuntu Xenial): importance |
Undecided |
Low |
|
| 2018-10-02 22:14:54 |
Eric Desrochers |
systemd (Ubuntu Xenial): status |
New |
Won't Fix |
|
| 2018-10-02 22:22:20 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): status |
Confirmed |
In Progress |
|
| 2018-10-02 22:30:52 |
Eric Desrochers |
summary |
'Enable Network' in recovery mode not working in Bionic |
'Enable Network' in recovery mode not working properly. |
|
| 2018-10-03 01:29:47 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): importance |
Low |
Medium |
|
| 2018-10-03 01:30:35 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): importance |
Low |
Medium |
|
| 2018-10-03 01:31:00 |
Eric Desrochers |
friendly-recovery (Ubuntu Bionic): importance |
Low |
Medium |
|
| 2018-10-03 01:31:10 |
Eric Desrochers |
friendly-recovery (Ubuntu Xenial): importance |
Low |
Medium |
|
| 2018-10-03 01:40:07 |
Eric Desrochers |
attachment added |
|
xenial.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/friendly-recovery/+bug/1766872/+attachment/5196250/+files/xenial.debdiff |
|
| 2018-10-03 01:45:06 |
Eric Desrochers |
attachment added |
|
bionic.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/friendly-recovery/+bug/1766872/+attachment/5196251/+files/bionic.debdiff |
|
| 2018-10-03 01:45:20 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2018-10-03 01:55:26 |
Eric Desrochers |
attachment added |
|
cosmic.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/friendly-recovery/+bug/1766872/+attachment/5196252/+files/cosmic.debdiff |
|
| 2018-10-03 02:04:48 |
Eric Desrochers |
friendly-recovery (Ubuntu Bionic): status |
Confirmed |
In Progress |
|
| 2018-10-03 02:04:59 |
Eric Desrochers |
friendly-recovery (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2018-10-03 02:05:19 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): status |
Confirmed |
Invalid |
|
| 2018-10-03 04:20:40 |
Ubuntu Foundations Team Bug Bot |
tags |
id-5afda46ded21519fcf26f22b rls-bb-incoming sts |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts |
|
| 2018-10-15 13:41:11 |
Eric Desrochers |
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. |
[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, we have tested differents scenarios and everything reported fine so far.
[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. |
|
| 2018-10-15 14:05:41 |
Eric Desrochers |
description |
[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, we have tested differents scenarios and everything reported fine so far.
[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. |
[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, we have tested differents scenarios and everything reported fine so far.
* '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 workin in friendly-recovery than being able to resume it at the moment.
[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. |
|
| 2018-10-15 14:08:15 |
Eric Desrochers |
description |
[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, we have tested differents scenarios and everything reported fine so far.
* '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 workin in friendly-recovery than being able to resume it at the moment.
[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. |
[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, we have tested differents scenarios and everything reported fine so far.
* '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.
[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. |
|
| 2018-10-15 14:14:15 |
Eric Desrochers |
description |
[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, we have tested differents scenarios and everything reported fine so far.
* '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.
[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. |
[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.
[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. |
|
| 2018-10-15 14:16:13 |
Eric Desrochers |
description |
[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.
[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. |
[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.
[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. |
|
| 2018-10-15 14:16:39 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): status |
In Progress |
Fix Released |
|
| 2018-10-15 14:46:35 |
Eric Desrochers |
description |
[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.
[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. |
[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. |
|
| 2018-10-15 14:46:55 |
Eric Desrochers |
description |
[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. |
[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/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. |
|
| 2018-10-15 14:51:40 |
Eric Desrochers |
description |
[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/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. |
[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.
* 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. |
|
| 2018-10-15 14:51:55 |
Eric Desrochers |
description |
[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.
* 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. |
[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 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. |
|
| 2018-10-15 15:00:50 |
Łukasz Zemczak |
friendly-recovery (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-10-15 15:00:52 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-10-15 15:00:54 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2018-10-15 15:00:56 |
Łukasz Zemczak |
tags |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-needed verification-needed-bionic |
|
| 2018-10-15 15:12:31 |
Eric Desrochers |
friendly-recovery (Ubuntu Cosmic): assignee |
Eric Desrochers (slashd) |
Dimitri John Ledkov (xnox) |
|
| 2018-10-15 15:21:04 |
Eric Desrochers |
friendly-recovery (Ubuntu Dd-series): assignee |
Eric Desrochers (slashd) |
|
|
| 2018-10-16 19:38:52 |
Eric Desrochers |
tags |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-needed verification-needed-bionic |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-done-bionic verification-needed |
|
| 2018-10-16 20:16:40 |
David Coronel |
bug |
|
|
added subscriber David Coronel |
| 2018-10-22 08:00:02 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-10-22 08:10:07 |
Launchpad Janitor |
friendly-recovery (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-10-22 08:44:08 |
Łukasz Zemczak |
friendly-recovery (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-10-22 08:44:11 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-10-22 08:44:17 |
Łukasz Zemczak |
tags |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-done-bionic verification-needed |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-done-bionic verification-needed verification-needed-xenial |
|
| 2018-10-22 20:24:30 |
David Coronel |
tags |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-done-bionic verification-needed verification-needed-xenial |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-done-bionic verification-done-xenial verification-needed |
|
| 2018-10-29 09:44:15 |
Launchpad Janitor |
friendly-recovery (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-11-24 22:54:44 |
Mathew Hodson |
friendly-recovery (Ubuntu Disco): status |
Invalid |
Fix Released |
|
| 2018-11-24 22:57:40 |
Mathew Hodson |
tags |
id-5afda46ded21519fcf26f22b patch rls-bb-incoming sts verification-done-bionic verification-done-xenial verification-needed |
id-5afda46ded21519fcf26f22b patch sts verification-done-bionic verification-done-xenial |
|
| 2018-11-24 22:57:57 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu) |
|
|
| 2018-11-24 22:58:06 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Xenial) |
|
|
| 2018-11-24 22:58:13 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Bionic) |
|
|
| 2018-11-24 22:58:18 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Cosmic) |
|
|
| 2018-11-24 22:58:24 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Disco) |
|
|
