<div dir="ltr">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?<div><br></div><div>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 :-/<div><br></div><div>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.</div><div><br></div><div>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.</div></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Cheers,<div>Marga</div></div></div>