From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 10F77138CD3 for ; Thu, 28 May 2015 14:12:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DAB60E08A2; Thu, 28 May 2015 14:12:27 +0000 (UTC) Received: from mail0200.smtp25.com (mail0200.smtp25.com [174.37.170.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D3176E087C for ; Thu, 28 May 2015 14:12:26 +0000 (UTC) Received: from ccs.covici.com (localhost [127.0.0.1]) by ccs.covici.com (8.14.9/8.14.8) with ESMTP id t4SECNSx023856 for ; Thu, 28 May 2015 10:12:23 -0400 From: covici@ccs.covici.com To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] problems debugging a systemd problem In-reply-to: References: <28995.1432789799@ccs.covici.com> <30995.1432793754@ccs.covici.com> Comments: In-reply-to Rich Freeman message dated "Thu, 28 May 2015 07:23:11 -0400." X-Mailer: MH-E 8.5; nmh 1.6; GNU Emacs 23.4.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23854.1432822343.1@ccs.covici.com> Date: Thu, 28 May 2015 10:12:23 -0400 Message-ID: <23855.1432822343@ccs.covici.com> X-SpamH-OriginatingIP: 70.109.53.110 X-SpamH-Filter: s-out-001.smtp25.com-t4SECOu3017443 X-Archives-Salt: b9f228a2-274e-4b4e-941a-669838b1b195 X-Archives-Hash: b4af67165247516a5a0f0e66982fba10 Rich Freeman wrote: > On Thu, May 28, 2015 at 2:15 AM, 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. Thanks, so how would I get in touch with dracut devs? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com