[systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

Sergei Franco sergei.franco at gmail.com
Mon Sep 26 00:37:21 UTC 2016


I wasn't aware of emergency.target existence (systemd is new to me).
What would be correct way to automatically start networking/ssh in
emergency mode?

The only thing I could find is this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1213781


Sergei.





On 26 September 2016 at 13:09, Dave Reisner <d at falconindy.com> wrote:

> On Mon, Sep 26, 2016 at 11:35:51AM +1300, Sergei Franco wrote:
> > Thank you for your quick reply.
> >
> > I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
> > present the following message:
> >
> > The disk drive for /data is not ready yet or not present.
> > keys:Continue to wait, or Press S to skip mounting or M for manual
> recovery
> >
> > So it is not as big difference as I initially thought, except it is much
> > easier to deal with by simply pressing S, while I believe there is no
> > such option for systemd (it would be nice).
>
> Making bootup potentially interactive in this manner is strictly worse
> than dumping you into emergency mode. At least with emergency mode, you
> might be able to add dependencies to emergency.target such that, for
> example, an sshd comes up and an admin can login to the remote box.
> How's this supposed to work with a random prompt which must be accessed
> on /dev/console?  Enforce that everyone has some sort of out of band
> console?
>
> Unclear why you consider this a superior design decision...
>
> > So in future for non crucial disks I will use nofail.
> >
> > Best regards.
> >
> > Sergei.
> >
> > P.S. As advised I have replied to correct address.
> >
> > On 26 September 2016 at 11:30, Reindl Harald <h.reindl at thelounge.net>
> wrote:
> >
> >     if you post somehting to a mailing-list and you get a response on
> the list
> >     POST REPLIES TO THE LIST - *period*
> >
> >     Am 26.09.2016 um 00:28 schrieb Sergei Franco:
> >
> >         Thank you for your quick reply.
> >
> >         I just tested this scenario on Ubuntu 12.04LTS (with upstart)
> and it
> >         present the following message:
> >
> >         The disk drive for /data is not ready yet or not present.
> >         keys:Continue to wait, or Press S to skip mounting or M for
> manual
> >         recovery
> >
> >         So it is not as big difference as I initially thought, except it
> is
> >         much
> >         easier to deal with by simply pressing S, while I believe there
> is no
> >         such option for systemd (it would be nice).
> >
> >         So in future for non crucial disks I will use nofail.
> >
> >         Best regards.
> >
> >         Sergei.
> >
> >         On 26 September 2016 at 10:57, Reindl Harald <
> h.reindl at thelounge.net
> >         <mailto:h.reindl at thelounge.net>> wrote:
> >
> >
> >
> >             Am 25.09.2016 um 23:52 schrieb Sergei Franco:
> >
> >                 I am looking at correct way to disable the "feature" of
> >                 emergency mode
> >                 when systemd encounters missing block device entires in
> fstab.
> >
> >                 For example:
> >
> >                 the following entry is in /etc/fstab:
> >                 UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data
>
> >          xfs
> >                 defaults        0       0
> >
> >                 If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has
> been
> >                 detached
> >                 and machine rebooted it stops booting with Emergency
> mode, even
> >                 though
> >                 the /data is not crucial for boot
> >
> >
> >             RTFM - when you don't say "nofail" it's ecpected to be
> crucial
> >
> >             your entry says it's crucial
> >
> >             http://unix.stackexchange.com/questions/53456/what-is-the-di
> >         fference-between-nobootwait-and-nofail-in-fstab
> >             <http://unix.stackexchange.com/questions/53456/what-is-the-
> >         difference-between-nobootwait-and-nofail-in-fstab>
> >
> >
> >
> >
>
> > _______________________________________________
> > systemd-devel mailing list
> > systemd-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160926/1c7e4c9a/attachment.html>


More information about the systemd-devel mailing list