Recovery shell does not spawn if mountall stopped by esc (mountall 1.0)

[Luke]

Binary package hint: mountall

Source package: mountall 1.0
Ubuntu package: mountall 1.0 (all I get from apt-cache policy mountall)
Test System: MSI Wind U100 (Intel Atom), booting both from hard disk and from a slow flash drive with Karmic installed

Expected Actions:
On a hung mountall with dependant mounts(bad passphrase to deny access to encrypted /home), expected pressing "esc" to stop usplash(if running) and spawn recovery shell

On pressing exc during root partition fsck, expected cancellation of checks, continuation of boot(this works on non-root partitions). Would accept continuation of fsck with esc entirely ignored.

In every instance I can generate where mountall exits due to an error, I would expect mountall-shell.conf to in fact spawn a recovery shell, no matter what stopped mountall from finishing

Actual results:

Instead, in every test I have tried , pressing esc does not spawn a shell, and if usplash is running, it does not exit but continues. I have not been able to force an fsck failure as the clock bug is fixed, and a bad passphrase on the LUKS
partition generates the unavailable dependant mount/unavailable swap device open-ended wait, with option to press esc. Sometimes I have been able to bring up tty8, and get a reference to mountall exiting 8-but NO recovery shell, just a console ignoring all input.

It appears that mountall-shell is not triggering when mountall stops, leaving the boot process hung and not responsive to anything but reset. sudo initctl -list reveals a list of processes including "mountall-shell stop/waiting" and "mountall-reboot stop/waiting" , but when the interactive recovery shell should spawn it does not.

Oh well, I guess that gets around the vulnerability to a "esc spam root shell" which for obvious reasons I cannot duplicate, but also means recovery from any error sufficient to force mountall to exit might also have the same problem, leaving systems unbootable to those without live discs or other recovery media.

Until this is fixed, I recommend keeping a flash drive with Ubuntu Jaunty on it handy if you carry a laptop, and at least a live disc if not the (faster) recovery flash drive around your desktop, as you will not be able to get around this and boot otherwise if anything goes wrong with mounting your filesystems. Of course, this means all encrypted /home systems no longer have the ability to boot to an unencrypted backup, empty /home directory if, say, the LUKS mapping gets corrupted. That I have tested-without the shell you cannot even manually emit "filesystem" to get the boot to continue.

[Luke (lukekuhn)]

  I've done more testing, and this is even worse than I thought.

 If a filesystem fails fsck (tested by rolling clock back a week), the recovery shell does NOT spawn and you CANNOT run fsck manually. If I do this on the console, I do not get any message from Init about mountall stopping, only a message about fsck's exit status. On an esc press against a waiting mountall, I get mountall:cancelled instead of a message from init about mountall ending. SAME message if I try to cancel a root filesystem fsck run.

I think two things are happening here:

1: It looks like Mountall isn't actually EXITING, thus no "start on mountall stopped" process launches, and with mountall in an "infinate delayed exit," init simply waits-forever. I put a variety of test scripts in set to start on stopped mountall-and not one of them would launch. I then set a script to start on startup, stop mountall, shut down the splash screen, run /sbin/sulogin , then restart mountall, and this worked as written.
This means you can spawn a shell, but the trigger for mountall-shell.conf (mountall stopped) is not getting sent.

2: On a root filesystem fsck run, an esc press gets detected by mountall and treated as "cancel mountall", while on an non-root filesytem fsck run, mountall stops fsck but is not itself cancelled. Perhaps the internal variable on mountall responding to an Esc press is being improperly set during root fsck runs only?

  If you install karmic on a cheap flash drive or any other circumstance where frequent filesystem corruption is a fact of life, there are two solutions: either set all fsck pass numbers to 0 and check it at intervals on another system, or open /etc/default/rcS and set FSCKFIX=yes . The danger of the latter is data loss in a severe filesystem corruption case before you get to make any decisions about recovering data first, then fixing the filesystem.

[Scott James Remnant (Canonical) (canonical-scott)]

Sounds like cryptsetup is taking the escape key instead

[Luke (lukekuhn)]

Can anyone confirm that if cryptsetup is not installed, the recovery shell works? If this is so and Cryptsetup does not get fixed, I will have to write a script to detect "single" in /proc/cmdline and open a shell prior to mountall, for recovery on a subsequent boot. This will be needed on all my systems, as I always use encrypted /home , swap , and tmp directories.

I've seen esc on root(NOT encrypted) filesystem fsck lead to a hung mountall, esc
on the dependent mounts (encrypted partition not ready) do the same. if this is Cryptsetup, a patch will be needed if cryptsetup doesn't get fixed upstream(bugs from Jaunty are still unfixed there).

> Date: Mon, 9 Nov 2009 16:25:51 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 476161] Re: Recovery shell does not spawn if mountall stopped by esc (mountall 1.0)
>
> Sounds like cryptsetup is taking the escape key instead
>
> ** Package changed: mountall (Ubuntu) => cryptsetup (Ubuntu)
>
> --
> Recovery shell does not spawn if mountall stopped by esc (mountall 1.0)
> https://bugs.launchpad.net/bugs/476161
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Find the right PC with Windows 7 and Windows Live.
http://www.microsoft.com/Windows/pc-scout/laptop-set-criteria.aspx?cbid=wl&filt=200,2400,10,19,1,3,1,7,50,650,2,12,0,1000&cat=1,2,3,4,5,6&brands=5,6,7,8,9,10,11,12,13,14,15,16&addf=4,5,9&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen2:112009

[Luke (lukekuhn)]

I have written a workaround for any of the various "no recovery shell" bugs. It's not perfect as you have to reboot in single-suer mode to use it(and again for a root filesystem error correction), but it allows you to recover without booting from another device. It looks for the word "single" on /proc/cmdline, and if it is present stops mountall, opens a recovery shell, and restarts mountall on exiting the shell. It basically does what mountall-shell.conf would do if it caught the stopped mountall signal.

Cut and paste the text below, save it as "recovery-shell.conf" and drop it into /etc/init .

# Recovery shell-opens shell BEFORE Mountall starts
author "Luke"
description "Bugfix-Recovery shell for single user mode,to recover from failed boots"

start on startup

task
console owner

script
        if test $(grep single /proc/cmdline | head -c 4) ; then

        initctl stop mountall
        usplash_write "QUIT"
        setupcon
    echo "A Root Shell will now be started for recovery."
        sulogin
        exec start --no-wait mountall
        fi
end script

_________________________________________________________________
Windows 7: Unclutter your desktop.
http://go.microsoft.com/?linkid=9690331&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009