On Sun, Oct 28, 2012 at 05:29:46PM +0000, Colin Guthrie wrote: > '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 (arvidj...@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). I think that those cases aren't that similar, since here trying to reach default.target a second time should actually suceed.
> 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. Hm, shouldn't the timeouts for devices that are slow to appear be increased? Create sys-devices-...-vdaX.device with [Unit] JobTimeoutSec=5min ? Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
