Bug#802211: Additional comments about the issue

Marga Manterola marga at google.com
Fri Jul 7 09:51:29 BST 2017


Having thought about this a bit more, I want to add that while I understand
the concern, it does seem to me that it's a rather convoluted case to
consider: someone has password protected grub AND their BIOS (otherwise you
can just as easily boot a pendrive), but they have not encrypted their
hard-drive?

Of course having the proposed solution of allowing a user to login if they
are in sudo/admin sounds like the right way to go, but in the meantime
there's a lot of people with password-less root accounts that will not be
able to use recovery mode when they need it :-/

Additionally, this bug talks about rescue.service, but as I mentioned in my
previous message, emergency.service is also affected by this.
 emergency.service looks exactly like rescue.service except that it's
triggered by some core pieces of the system failing. So, for example, an
error in fstab will trigger executing emergency.service.

Can we at least do the --force for emergency.service? Getting there would
NOT be as simple as selecting the "recovery mode" option, but would rather
require that the machine fails to boot for some reason.
-- 
Cheers,
Marga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20170707/1422805e/attachment.html>


More information about the Pkg-systemd-maintainers mailing list