remounting filesystems hangs uninterruptibly if network filesystems are unavailable

[Steve Langasek]

The "mount filesystems" and "check filesystems" options work by calling mountall. This is the correct thing to do; however, if there are filesystems listed in the fstab that are unavailable (for instance, because they're network filesystems and the network hasn't been brought up, or the server is down, or they refer to unavailable disks), mountall will hang *indefinitely* waiting for them to become available - particularly in the case of filesystems that it knows are network filesystems.

This is not a problem when it happens during a normal boot, because mountall will continue to run in the background. However, when mountall is run from friendly-recovery, it becomes the foregrounded console process and there's no way to reasonably interrupt this to return to the recovery menu - you effectively have to reboot to get back to the other recovery options (and probably use SysRq in the process if you want to actually ensure your rootfs gets cleanly unmounted).

We probably need some improvements to the mountall interface to allow a "one-shot" approach to mounting network filesystems when called from friendly-recovery.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: friendly-recovery 0.2.18
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
ApportVersion: 1.23-0ubuntu2
Architecture: amd64
Date: Sat Oct 1 12:29:46 2011
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: friendly-recovery
UpgradeStatus: Upgraded to oneiric on 2011-09-23 (7 days ago)

[Stéphane Graber (stgraber)]

Was going to mark this Fix released (well, actually did) as friendly-recovery now starts udev by default bringing up the network in quite a few cases, but then I thought of desktop installs with Network Manager where the network indeed won't be online at the time we call mountall ...

So keeping the bug open for now, will have to think about the best way to deal with this ...

[jhansonxi (jhansonxi)]

A similar situation occurs when an encrypted filesystem is listed in crypttab with local key file specified but the key has an error which prevents unlocking the volume. The boot process hangs and so does friendly-recovery during RW mount attempts. This key situation may seem odd but it involves an encrypted root volume that has the key for an encrypted /home but the key has an error so it fails to unlock.