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 D68B71382C5 for ; Sat, 15 May 2021 12:03:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D90B8E0886; Sat, 15 May 2021 12:03:15 +0000 (UTC) Received: from smtp.bonedaddy.net (smtp.bonedaddy.net [45.33.94.42]) (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 EC0BDE0843 for ; Sat, 15 May 2021 12:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bonedaddy.net; s=mail; t=1621080234; bh=qeH+ZiYbaQjUgmyN3jrwtLhrxQuNQg9sJgrIw6YKR+E=; h=Subject:To:References:From:Date:In-Reply-To; b=mb0j7hQm95eUv6h6eeBP6zHJUTP5Ajb0lomCUWGkpRjAp9uN7LgJAc3/2LV/ABFpp Mhpg46ysjA7QVJYy7FqWRI+ZC3/CBdBl1ATg9yafOyb+tgcOBSx54oz1bSb43uEM4z 4XOP/toxgD1/0a7si0/czhAaewgMdQ4QvKxUogdaqqGp+c6I74zoqTG0lzKOIpBt4l azyhk17uNQEVs/wWm0859T2tW2WltdHdp3Bua1CMlGI0mhYKxj9ZLJqlWYowq3gEvW k59FsxRLpeUtYwpmFL4cdsz2Bbbvqp7XrRet3tcyMlCC1H7kjvIsnt0ZaicjMw3sLD Azza5x/RNz8uA== Subject: [gentoo-user] =?UTF-8?Q?Re=3a_boot_hangs_forever_at_=e2=80=9cLoading_initial_ramd?= =?UTF-8?B?aXNrLi4u4oCd?= To: gentoo-user@lists.gentoo.org References: <1b7b0ba0-47fe-59e3-dd1f-50e5ab93125a@users.sourceforge.net> From: Todd Goodman Message-ID: Date: Sat, 15 May 2021 08:03:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9FE209BE0A81FD01910E2591" Content-Language: en-US X-Archives-Salt: d62dec01-2da1-4742-9f66-27eba1f2dc44 X-Archives-Hash: c7124f51e6f23f3f3debfcb35e705143 This is a multi-part message in MIME format. --------------9FE209BE0A81FD01910E2591 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/14/2021 5:15 PM, John Blinka wrote: > n > > On Fri, May 14, 2021 at 2:36 AM John Covici > wrote: > > > 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.  Also, see if there is any genkernel option to get some debugging > info out of the initrd, I know using dracut you can get breakpoints > during the process and see how its doing. > > > Tried dracut.  No change. > > Added the kernel command line debug options (#3 in “Identifying your > problem area” in ‘man dracut’).  No change. > > Feeling peevish, I made a file of random junk using dd if=/dev/random > of=initrd.img count=4096.  Then supplied that pile of junk as the > initrd.  Again, no change. > > Then I supplied a nonexistent file name (xxx.img) as the initrd.  This > time I got a complaint: > > error: file ‘/xxx.img’ not found. > > Press any key to continue... > > So, it’s getting as far as wanting to read the initrd, and is smart > enough to tell whether the specified initrd actually exists on the > specified boot partition.  But it can’t 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 memory location of the initrd. > > I’ve observed that that no booting output comes out of linux, nor any > complaints from linux about the nonsense contents I fed it from the > random initrd I built. 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:  learned how to run an interactive grub2 command shell. > With full debugging turned on, it looks like grub2 can load the kernel > image, and it looks like it loads the initrd as well.  At least there > are no 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.  Don’t know whether grub2 or linux has failed.  I > don’t know how to get either one to tell me more. > > John This is likely not your issue with an integrated Intel GPU, but I was building a new system recently with UEFI, ASUS ROG mobo, and nvidia GPU and had this same issue. Surprisingly, this turned out to require me to set the simple framebuffer support in the kernel config (I also set the UEFI framebuffer support) or else I would get no screen output after the loading initial ramdisk... message. Just something I ran into for the first time ever recently Todd --------------9FE209BE0A81FD01910E2591 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/14/2021 5:15 PM, John Blinka wrote:
n

On Fri, May 14, 2021 at 2:36 AM John Covici <covici@ccs.covici.com> wrote:

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.  Also, see if there is any genkernel option to get some debugging
info out of the initrd, I know using dracut you can get breakpoints
during the process and see how its doing.

Tried dracut.  No change.

Added the kernel command line debug options (#3 in “Identifying your problem area” in ‘man dracut’).  No change.

Feeling peevish, I made a file of random junk using dd if=/dev/random of=initrd.img count=4096.  Then supplied that pile of junk as the initrd.  Again, no change.

Then I supplied a nonexistent file name (xxx.img) as the initrd.  This time I got a complaint:

error: file ‘/xxx.img’ not found.

Press any key to continue...

So, it’s getting as far as wanting to read the initrd, and is smart enough to tell whether the specified initrd actually exists on the specified boot partition.  But it can’t 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 memory location of the initrd.

I’ve observed that that no booting output comes out of linux, nor any complaints from linux about the nonsense contents I fed it from the random initrd I built.  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:  learned how to run an interactive grub2 command shell. With full debugging turned on, it looks like grub2 can load the kernel image, and it looks like it loads the initrd as well.  At least there are no 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.  Don’t know whether grub2 or linux has failed.  I don’t know how to get either one to tell me more.

John

This is likely not your issue with an integrated Intel GPU, but I was building a new system recently with UEFI, ASUS ROG mobo, and nvidia GPU and had this same issue.

Surprisingly, this turned out to require me to set the simple framebuffer support in the kernel config (I also set the UEFI framebuffer support) or else I would get no screen output after the loading initial ramdisk... message.

Just something I ran into for the first time ever recently

Todd

--------------9FE209BE0A81FD01910E2591--