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 3744C138CD3 for ; Thu, 28 May 2015 11:23:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C637E08BF; Thu, 28 May 2015 11:23:13 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3FEF1E0880 for ; Thu, 28 May 2015 11:23:12 +0000 (UTC) Received: by iesa3 with SMTP id a3so35619709ies.2 for ; Thu, 28 May 2015 04:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=D84P60UC9zL1HS5ujkRrSnuF12TK+Qf0OyPDgYW7F2E=; b=dNx2PmXNgOX1yCtyrW9SNsBk2CPsyAGgSyvfZDmtSsgKikqDl3a++g2RC0NyZowspl UmD2Ws6RIZbTVfQvcYHx5RYFZ347iJ6pbzk5MCEKbxFzGRSt83W6EenKUuis9Pi4vW/T f1L8GXz+g0zh8+nEwp24UjTFupRPKNNleGfEvaXfIJlkdwVqqo/PL7bPNjW8qttcL1LJ EZWnKUd6p3Q+IrqALew1EugemcAHgizp9ljA5MUW51IEtQ9NcTeNzAM69hiud4/vyJbU ObhEPUww4OEUeC67XFcAl487rIWS1yl+Cd6ncH6sIfRwX9U6ZQm5RGSrwPe4cHzVD9VX /k1g== 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 X-Received: by 10.107.135.214 with SMTP id r83mr2742248ioi.13.1432812191579; Thu, 28 May 2015 04:23:11 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.107.6.34 with HTTP; Thu, 28 May 2015 04:23:11 -0700 (PDT) In-Reply-To: <30995.1432793754@ccs.covici.com> References: <28995.1432789799@ccs.covici.com> <30995.1432793754@ccs.covici.com> Date: Thu, 28 May 2015 07:23:11 -0400 X-Google-Sender-Auth: QcTOeTbmKxm7JTP0KoEeVBvqCQ0 Message-ID: Subject: Re: [gentoo-user] problems debugging a systemd problem From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 69595dc1-1f0b-428a-b5a3-1fa80b5452b1 X-Archives-Hash: 2ae884e74f00c341396fca9de90a9704 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. -- Rich