= Code review =
In general I think this is broadly right; recovery software clearly
doesn't belong in /usr, and I can see why it simplifies things to have
this guaranteeably start before mountall rather than having to change
mountall.
However, the only other 'start on startup' job I see is hostname, and I
think we ought to run that even in recovery mode. Any job that's 'start
on startup' already has to run with a read-only root filesystem, since
that's how the initramfs typically leaves things and it isn't until
mountall runs that the root filesystem becomes read-write. Thus, why
not simply make friendly-recovery be 'start on starting mountall'? That
way, you could drop the grub2 and initramfs-tools changes entirely.
Can we make /usr/share/recovery-mode a symlink to /lib/recovery-mode for
compatibility, just in case third-party packages have added entries
here? The postinst will need to move any remaining files from
/usr/share/recovery-mode/ to /lib/recovery-mode/ and then install a
symlink, since dpkg won't replace a directory with a symlink by itself.
I think I'd slightly prefer the Upstart job to look like this:
script
if [ -x /lib/recovery-mode/recovery-menu ]; then
exec /lib/recovery-mode/recovery-menu
else
exec /sbin/sulogin
fi
end script
post-stop exec initctl emit startup
That way Upstart is directly supervising the process that's actually
doing the work; it's a detail but it seems more logical to me.
"Remount / in read/write" should read "Remount / read/write". Also, I
think it would be helpful to indicate somewhere in the UI that this
enables more recovery mode options, otherwise people will be rather
confused why some option they were vaguely looking for doesn't appear.
Perhaps check this with a designer?
I feel there ought to be some dependency relation between upstart and
friendly-recovery, perhaps Breaks in one direction or both, to make sure
partial upgrades don't leave people without recovery mode. This would
be simpler if you could take my 'start on starting mountall' suggestion
so that we don't also need dependency relations with grub-common and
initramfs-tools.
The following items apply only if you decide not to take my 'start on
starting mountall' suggestion above:
What happens if friendly-recovery isn't installed? After all, it's only
Priority: standard. Can we use *both* single and startup-event
=recovery-mode safely; or, failing that, have the relevant grub.d script
test for the presence of /lib/recovery-mode/recovery-menu and add either
single or startup-event=recovery-mode as appropriate? I think it's
important to test this both with and without friendly-recovery
installed.
To reduce code duplication, I'd prefer the initramfs-tools code to do
something like:
exec run-init ${rootmnt} ${init} "$@" ${STARTUP_EVENT:+--startup-
event=$STARTUP_EVENT} ...
= Feature freeze exception =
On the one hand, it would be lovely to get this in: the bug makes
recovery mode unusable in a significant set of situations, and that's
serious. On the other, I don't like contemplating something unforeseen
making recovery mode worse. So I'm on the fence about this, and would
appreciate input from other members of the release team (whom I've
subscribed).
I would be happier if it were possible to avoid the grub2 and initramfs-
tools changes as discussed above, and confine the change entirely to
friendly-recovery and upstart (the latter of which is fair enough since
it consists of removing a tentacle of friendly-recovery).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/575469
Title:
[UIFe] [FFe] recovery mode mounts filesystems read-write rather than
read-only
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/575469/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
