Re: [gentoo-user] problems debugging a systemd problem

[Rich Freeman]

On Thu, May 28, 2015 at 2:15 AM,  <covici@××××××××××.com> wrote:
>
> Thanks for your quick reply, but I do have rd.shell=1, but it did not
> drop to a shell,it just hung, so I could not do journalctl or anything
> -- the nearest break point was pre-initqueue which was maybe too early
> and the next one is pre-mount which it never got to.

It could very well be a dracut bug (consider bringing the issue to
them), but how long did you wait while it was looping.  I've seen
cases where dracut looped for a few minutes before dropping to a
shell.  There are a few loops where dracut is waiting for udev to
detect all devices, and if it is looking for a device that will never
appear, then it will potentially loop forever.  There should be a
timeout, but I don't know what it is set to by default.

Once you get a shell you should be able to inspect the
journal/dmesg/etc and try to see what is going on.

Sure, you could have booted a rescue CD, but I don't see what it would
have gained you as far as troubleshooting the problem with your
initramfs (though it would have allowed you to rebuild it if the
initramfs itself was broken, or try out a different version/etc).  As
you point out any logs it creates are stored in tmpfs or ramfs - that
is true of just about any initramfs since it won't have any place to
store them until it mounts root.

I don't know if setting the rescue target would have helped.  I think
that the behavior of that option is to still boot to your root
filesystem and THEN drop to a shell.  If you want to force a rescue
shell within the initramfs you need to use rd.break or such, and as
you point out you need to find the right breakpoint for this.

I'd suggest talking to the dracut devs about how it should have
behaved in those circumstances.  At the very least they might be able
to improve the error reporting.

-- 
Rich