[systemd-devel] Too little information is shown when system enters emergency mode

Colin Guthrie gmane at colin.guthr.ie
Sun Oct 28 10:29:46 PDT 2012


'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 28/10/12 01:19 did
gyre and gimble:
> On Tue, Oct 23, 2012 at 04:58:46PM +0200, Lennart Poettering wrote:
>> On Sun, 21.10.12 15:59, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
>>
>>> Welcome to emergency mode. Use "systemctl default" or ^D to enter default mode.
>>> Give root password for login:
>>
>> systemd 195 will now also mention "journalctl -b" in this
>> message. Originally this was only in the rescue mode, because of the
> Thanks! I tweaked the message now a bit more to take into account
> what sulogin says by itself.
> 
>> assumption that if you boot directly to emergency mode then no logs
>> would be in the journal, and hence no point in recommending this
>> command. However, after all most of the times people will end up in
>> emergency mode is when file systems not showing up where journald *is*
>> actually running and includes the desired, useful information.
>>
>>> Started /boot/efi                                                      [  OK  ]
>>> Dependency failed. Aborted start of /mnt                               [ ABORT]
>>> Dependency failed. Aborted start of Login Service                      [ ABORT]
>>> Dependency failed. Aborted start of D-Bus System Message Bus           [ ABORT]
>>> Welcome to emergency mode. Use "systemctl default" or ^D to enter default mode.
>>
>> Hmm, we definitely should show the initial unit that failed in this
>> output. 
>>
>> Can you restest with 195 please? If you find that there's information
>> missing in "journalctl -b" or in the status output, then please file a
>> bug, we really should place useful information at both.
> It _is_ already better, the output is more complete and includes the
> failing device, so that part is fine.
> 
> But there's one fundamental problem: the message suggests 'systemctl
> default', but 'systemctl default' will fail again, unless the error
> went away by itself, which is not going to happen in case of a missing
> device. But it's a tough nut to crack.

Actually this might relate to a problem one of our users is encountering
with a raid setup. The devices appear too late, but they do seem to
appear OK (unless I'm misreading the plot output).

https://bugs.mageia.org/show_bug.cgi?id=7892

Here the user enters emergency.target and shortly after the devices seem
to appear (I don't think they are triggered manually here).

Can anyone else read anything from the final plot attached to that bug
and advise on how best to delay the triggering of emergency.target for a
while? Any advice appreciated.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/



More information about the systemd-devel mailing list