With friendly-recovery version 0.2.38ubuntu1, selecting the check filesystems option results in an error message like:
/etc/default/rcS: file or directory not found This file does not exist on my system. I don't know if the problem I'm reporting is related to this issue, but it does seem to be the same as another bug that was marked as a duplicate of this one (1767685). -- 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: Fix Released Status in systemd package in Ubuntu: Won't Fix Status in friendly-recovery source package in Xenial: Fix Released Status in systemd source package in Xenial: Won't Fix Status in friendly-recovery source package in Bionic: Fix Released Status in systemd source package in Bionic: Won't Fix Status in friendly-recovery source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Won't Fix Status in friendly-recovery source package in Disco: Invalid Status in systemd source package in Disco: Won't Fix Bug 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 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. 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