Gentoo Archives: gentoo-user

From: Todd Goodman <tsg@×××××××××.net>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: boot hangs forever at “Loading initial ramdisk...”
Date: Sat, 15 May 2021 12:03:21
Message-Id: c1b7054c-1170-95be-74c4-2b0dfbd56c35@bonedaddy.net
In Reply to: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...” by John Blinka
1 On 5/14/2021 5:15 PM, John Blinka wrote:
2 > n
3 >
4 > On Fri, May 14, 2021 at 2:36 AM John Covici <covici@××××××××××.com
5 > <mailto:covici@××××××××××.com>> wrote:
6 >
7 >
8 > I would look in the grub.cfg and give us exactly what is in the stanza
9 > you are using, including where it thinks the root file system is,
10 > etc.  Also, see if there is any genkernel option to get some debugging
11 > info out of the initrd, I know using dracut you can get breakpoints
12 > during the process and see how its doing.
13 >
14 >
15 > Tried dracut.  No change.
16 >
17 > Added the kernel command line debug options (#3 in “Identifying your
18 > problem area” in ‘man dracut’).  No change.
19 >
20 > Feeling peevish, I made a file of random junk using dd if=/dev/random
21 > of=initrd.img count=4096.  Then supplied that pile of junk as the
22 > initrd.  Again, no change.
23 >
24 > Then I supplied a nonexistent file name (xxx.img) as the initrd.  This
25 > time I got a complaint:
26 >
27 > error: file ‘/xxx.img’ not found.
28 >
29 > Press any key to continue...
30 >
31 > So, it’s getting as far as wanting to read the initrd, and is smart
32 > enough to tell whether the specified initrd actually exists on the
33 > specified boot partition.  But it can’t actually be doing anything
34 > with the initrd, or it would have objected to the random junk I fed it.
35 >
36 > From https://en.m.wikipedia.org/wiki/Initial_ramdisk#Implementation
37 > <https://en.m.wikipedia.org/wiki/Initial_ramdisk#Implementation>, it
38 > appears that grub is in charge of loading both linux and the initrd
39 > into memory, then handing execution over to linux along with a pointer
40 > to the memory location of the initrd.
41 >
42 > I’ve observed that that no booting output comes out of linux, nor any
43 > complaints from linux about the nonsense contents I fed it from the
44 > random initrd I built. That suggests to me that grub has failed to
45 > load linux and/or the initrd into memory, or that it's failed to hand
46 > execution control to linux.
47 >
48 > Next step:  learned how to run an interactive grub2 command shell.
49 > With full debugging turned on, it looks like grub2 can load the kernel
50 > image, and it looks like it loads the initrd as well.  At least there
51 > are no complaints and the reported initrd size looks correct.
52 >
53 > But when I issue the boot command, grub2 issues a handful of mallocs
54 > and does a little token parsing, and then just stops...
55 >
56 > So it appears that the boot problem arises right around the handoff
57 > from grub2 to linux.  Don’t know whether grub2 or linux has failed.  I
58 > don’t know how to get either one to tell me more.
59 >
60 > John
61
62 This is likely not your issue with an integrated Intel GPU, but I was
63 building a new system recently with UEFI, ASUS ROG mobo, and nvidia GPU
64 and had this same issue.
65
66 Surprisingly, this turned out to require me to set the simple
67 framebuffer support in the kernel config (I also set the UEFI
68 framebuffer support) or else I would get no screen output after the
69 loading initial ramdisk... message.
70
71 Just something I ran into for the first time ever recently
72
73 Todd

Replies