[Bug 575469] Re: [UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only

[Steve Langasek]

Please ship the /usr/share/recovery-mode symlink in the package itself,
don't just create it in the postinst; this way it gets cleaned up on
package removal.

Should the friendly-recovery job be marked as a 'task'?

+  echo $(eval_gettext "Check all file systems (will exit read-only
mode)")

I think it would be clearer to say:

  Check all file systems (will remount filesystems read/write when
finished)

+# FIXME: Would be a lot better to just start the mountall upstart job but
+# for some reason it hangs, so instead the code below is copy/paste from mountall

Hmm; not ideal of course, but not surprising - this job is 'start on
starting mountall', so trying to start the job again will naturally
fail.

I don't think this is a particularly safe thing to do, anyway.  As soon
as mountall is run, it will start tripping off lots of other upstart
jobs, including ones that will want to claim the console, so we'll no
longer be single-threaded.  What happens when tty1.conf starts, and
wants our VT?

Maybe this should instead be handled as a special case of 'resume',
causing the job to exit with a particular exit code that gets picked up
by another job that's 'start on stopped mountall and stopped friendly-
recovery EXIT_STATUS=magicnum' and relaunches the menu?  That seems to
me that it would be more robust since our new job can then take care of
stopping and restarting tty1 as needed, but that means more code needs
written.

Or if the intent is to mount all filesystems *without* spawning other
jobs, maybe it's better to reinvent the pre-upstart mountall.sh init
script to do the mounting by hand and avoid all the events until later?

Either way, I think having the whole system start to boot while
friendly-recovery is running is a problem, and we ought not upload this
as-is.

Other than this, the changes look good to me.  Yes, this is a bit risky
for this late in the cycle, but the current recovery mode is really not
very usable... it's hard to make it worse at the moment, and the design
proposed here looks generally sound and least likely to cause
regressions provided we get the remount question sorted out.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to friendly-recovery in Ubuntu.
https://bugs.launchpad.net/bugs/575469

Title:
  [UIFe] [FFe] recovery mode mounts filesystems read-write rather than
  read-only

Status in “friendly-recovery” package in Ubuntu:
  Confirmed
Status in “newt” package in Ubuntu:
  Invalid
Status in “friendly-recovery” source package in Oneiric:
  Confirmed
Status in “newt” source package in Oneiric:
  Invalid

Bug description:
  Binary package hint: friendly-recovery

  In recovery mode, filesystems should probably be mounted read-only,
  since pending any problems they can safely be remounted read-write,
  while the reverse is not necessarily true.  This means that operations
  such as fsck, badblocks, zerofree, etc. are not possible without
  having to use a boot CD, and ensuring that any additional binaries are
  compatible.  One should assume that booting into recovery mode is
  either deliberate or has come about because of a problem.

  f-r 0.2.10 on lucid/2.6.32-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/575469/+subscriptions