From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B000C1382C5 for ; Fri, 14 May 2021 23:10:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D38D6E0895; Fri, 14 May 2021 23:10:20 +0000 (UTC) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) (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 4171BE0875 for ; Fri, 14 May 2021 23:10:19 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 7C27A1060164 for ; Fri, 14 May 2021 23:10:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1621033817; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=P4vVW9zffrKeXlnxZL8r1DQR28Rrpw1suQ2TysvpEfk=; b=2ytoYlhSh70GY7Dr1nHg0oatvZm1dRMhNA4fi8/s9uMfWfXGcNeERWENPGjcLyvp HnhNUo5e8faGghAxVpb6p6pkGXTNT2JCVhxk79aMttfkzQROuuRcciPbQC6kBTFkH0R gVA83mRyXNhHYCc2m35HJL3IDLJRFrp5gLsL6j6BIEcMVNbFJi2QUhXgN6j9NQduFkp ADaj82dk9jjQY3lIa1w48wuBhHr9YF6hd38YVcrwjYWhP8RD1H2ZptOV3h1N3hduuPT h4NOy9M/PtNBE4NXSXogvRVzjD0/RA5emZ14YXNaLcSeqmI9DmYvymJfaIEVQWS9DL/ 1veFmHENyA== Date: Sat, 15 May 2021 01:10:17 +0200 (CEST) From: mad.scientist.at.large@tutanota.com To: Gentoo User Message-ID: In-Reply-To: References: <1b7b0ba0-47fe-59e3-dd1f-50e5ab93125a@users.sourceforge.net> Subject: =?UTF-8?Q?Re:_[gentoo-user]_Re:_[gentoo-user]_Re:_[gentoo-user]_Re:_[ge?= =?UTF-8?Q?ntoo-user]_boot_hangs_forever_?= =?UTF-8?Q?at_=E2=80=9CLoading_initial_ramdisk...=E2=80=9D?= 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d17e9420-0431-4a4c-b316-ae748916fda1 X-Archives-Hash: 8759d121c1de38ef3ae9f69a1c49c54d --"Fascism begins the moment a ruling class, fearing the people may use the= ir political democracy to gain economic democracy, begins to destroy politi= cal democracy in order to retain its power of exploitation and special priv= ilege." Tommy Douglas May 14, 2021, 15:15 by john.blinka@gmail.com: > n > > > On Fri, May 14, 2021 at 2:36 AM John Covici <> covici@ccs.covici.com> > w= rote: > >> >> I would look in the grub.cfg and give us exactly what is in the stanza >> you are using, including where it thinks the root file system is, >> etc.=C2=A0 Also, see if there is any genkernel option to get some debug= ging >> info out of the initrd, I know using dracut you can get breakpoints >> during the process and see how its doing. >> > > Tried dracut.=C2=A0 No change. > > Added the kernel command line debug options (#3 in =E2=80=9CIdentifying y= our problem area=E2=80=9D in =E2=80=98man dracut=E2=80=99).=C2=A0 No change= . > > Feeling peevish, I made a file of random junk using dd if=3D/dev/random o= f=3Dinitrd.img count=3D4096.=C2=A0 Then supplied that pile of junk as the i= nitrd.=C2=A0 Again, no change. > > Then I supplied a nonexistent file name (xxx.img) as the initrd.=C2=A0 Th= is time I got a complaint: > > error: file =E2=80=98/xxx.img=E2=80=99 not found. > > Press any key to continue... > > So, it=E2=80=99s getting as far as wanting to read the initrd, and is sma= rt enough to tell whether the specified initrd actually exists on the speci= fied boot partition.=C2=A0 But it can=E2=80=99t actually be doing anything = with the initrd, or it would have objected to the random junk I fed it. > > From > https://en.m.wikipedia.org/wiki/Initial_ramdisk#Implementation> , = it appears that grub is in charge of loading both linux and the initrd into= memory, then handing execution over to linux along with a pointer to the m= emory location of the initrd. > > I=E2=80=99ve observed that that no booting output comes out of linux, nor= any complaints from linux about the nonsense contents I fed it from the ra= ndom initrd I built.=C2=A0 That suggests to me that grub has failed to load= linux and/or the initrd into memory, or that it's failed to hand execution= control to linux. > > Next step: =C2=A0learned how to run an interactive grub2 command shell. W= ith full debugging turned on, it looks like grub2 can load the kernel image= , and it looks like it loads the initrd as well.=C2=A0 At least there are n= o complaints and the reported initrd size looks correct. > > But when I issue the boot command, grub2 issues a handful of mallocs and = does a little token parsing, and then just stops... > > So it appears that the boot problem arises right around the handoff from = grub2 to linux.=C2=A0 Don=E2=80=99t know whether grub2 or linux has failed.= =C2=A0 I don=E2=80=99t know how to get either one to tell me more. > > John > Have you recompiled the kernel?=C2=A0 Could be a random, erroneous write to= disk or something in the kernel compile didn't go well.=C2=A0 I'd suggest = also rebuilding the initrd and reinstalling grub.=C2=A0 I.e. I think there = is likely a kernel compile issue since it doesn't ever launch the kernel su= ccesfully either on autopilot or when you run grub interactive.=C2=A0 Might= also recompile grub, perhaps there's a change in compiler options that pro= duces an incompatible (at least partially).=C2=A0 I also suggest the rebuil= d so you can be sure you have the right initrd and matching kernel.