On Thu, May 28, 2015 at 2:15 AM, <cov...@ccs.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
