remounting filesystems hangs uninterruptibly if network filesystems are unavailable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
friendly-recovery (Ubuntu) |
Triaged
|
Low
|
Unassigned |
Bug Description
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
ProcVersionSign
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)
PackageArchitec
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)
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 ...