[Bug 1766872] Re: 'Enable Network' in recovery mode not working in Bionic
Eric Desrochers
eric.desrochers at canonical.com
Tue May 1 14:55:32 UTC 2018
https://www.freedesktop.org/software/systemd/man/systemctl.html
If "ignore-dependencies" is specified, then all unit dependencies are
ignored for this new job and the operation is executed immediately. If
passed, no required units of the unit passed will be pulled in, and no
ordering dependencies will be honored. This is mostly a debugging and
rescue tool for the administrator and should not be used by applications
based on the above description, --job-mode may apply in friendly-
recovery as it fit in a debugging purpose IMHO.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to friendly-recovery in Ubuntu.
https://bugs.launchpad.net/bugs/1766872
Title:
'Enable Network' in recovery mode not working in Bionic
Status in friendly-recovery package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
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
More information about the foundations-bugs
mailing list