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 |