Ubuntu
mountall package

mountall tries to resume boot when it shouldn't

Bug #452196 reported by Brian Rogers
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Fix Released
Medium
Scott James Remnant (Canonical)
Ubuntu ubuntu-9.10
Karmic
Fix Released
Medium
Scott James Remnant (Canonical)
Ubuntu ubuntu-9.10

Bug Description

Binary package hint: mountall

During Karmic's boot, if the automatic filesystem check fails, it drops the user into a root shell to do the fsck manually. After you perform the disk check and exit the shell, the boot script tries to remount the root partition with write access to resume booting.

This is really bad. e2fsck actually gives a warning that the mounted filesystem has been modified and Linux must be rebooted. If this is ignored and you just remount with write access, that will create filesystem errors right away again and could lead to data loss.

Typing 'reboot' instead of 'exit' also triggers the problem because the shell still exits and the regular boot process races with the reboot process. You have to run 'reboot -f' to restart safely and not corrupt the filesystem again.

If a (read-only) partition is modified by fsck, then you can't remount rw and resume. The system must be rebooted. The simplest solution is probably to unconditionally reboot when the recovery shell exits, and make sure nothing tries to resume the boot process in the meantime.

Anders Kaseorg (andersk)
Changed in mountall (Ubuntu):
status: New → Confirmed
Anders Kaseorg (andersk)
tags: added: regression-potential ubuntu-boot
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

This can probably be fixed by a "stop on runlevel [06]" in the mountall-shell script so it doesn't attempt to re-run mountall if the user reboots in that shell

Changed in mountall (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Looking through the old checkroot script, it would always reboot after the root filesystem check failed.

May as well do the same.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

I've uploaded a new version of mountall (0.2.5) to the ubuntu-boot PPA, as usual I would appreciate a little testing before I upload it to the archive proper.

Thanks

Changed in mountall (Ubuntu):
status: Triaged → Fix Committed
assignee: nobody → Scott James Remnant (scott)
milestone: none → ubuntu-9.10
Revision history for this message
Brian Rogers (brian-rogers) wrote :

OK, I'm running the PPA version now.

If I touch /forcefsck, reboot, and cancel the scan, it drops me into the shell. When I exit that shell, the system just sits there forever and I have to reboot with ctrl-alt-delete. If I type 'reboot' instead of exiting the shell, it resumes the boot process (remounting root as rw) but eventually a reboot also happens.

I haven't yet tested what happens if fsck fails, rather than being canceled, but there is still a scenario where the system attempts to resume booting after the recovery shell, which can cause corruption.

Changed in mountall (Ubuntu Karmic):
status: Fix Committed → New
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Fixed the fact it doesn't resume after exiting the shell - was inverted logic in the code.

Changed in mountall (Ubuntu Karmic):
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 0.2.5

---------------
mountall (0.2.5) karmic; urgency=low

  * Filesystem check progress reporting, including cancellation. LP: 446596.
  * When we're waiting for a mountpoint, if a few seconds of inactivity
    passes, report what we're waiting for and allow Escape to drop you to
    a recovery shell.
  * Start usplash for filesystem check progress reporting or when we've
    been waiting for more than a few seconds. LP: #431184.

  * Hide error removing /forcefsck, people mis-report this as a bug and
    don't tell us the error above it.
  * Don't call mount.ecryptfs or mount.aufs when adding an entry for
    /etc/mtab; these helpers are broken and do not support the -f argument.
    This means your passphrase may end up in /etc/mtab, blame them not me.
    LP: #431954, #443080.
  * Unlink /etc/mtab~ after creating/truncating /etc/mtab and before writing
    mtab entries. LP: #431865.
  * Stop the recovery shell if the user runs shutdown within it, so we
    don't run mountall again. LP: #452196.
  * If the root filesystem check fails, we'll need to reboot, so just have
    the recovery shell script do that.

  * Post-review logic fixes.

 -- Scott James Remnant <email address hidden> Tue, 20 Oct 2009 12:19:16 +0100

Changed in mountall (Ubuntu Karmic):
status: Fix Committed → Fix Released
Revision history for this message
Brian Rogers (brian-rogers) wrote :

Looks good.

Testing by interrupting /forcefsck, I can verify that the reboot command reboots, and exiting re-runs fsck which will report if structural modification has occurred and trigger a reboot in that case. And fsck seems to be aware if a prior instance of fsck, run manually in the recovery shell, has made a structural modification, so it reboots in that case as well.

I'll file a new bug if I find any remaining issues with mountall.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.