Mailing List Archive

On 5/13/21 5:06 PM, John Blinka wrote:
> Hi, Gentooers,
>
> New thread, next obstacle in booting new Asus mobo.
>
> As the subject says, the boot hangs indefinitely. Output to the screen is
>
>   Booting a command list
>
> Loading Linux 5.10.27-gentoo-x86_64 ...
> Loading initial ramdisk ...
>
> And there it stops forever.
>
> The kernel is the latest stable gentoo-sources.  I normally do a
> custom configuration, but in this instance built it with “genkernel
> all”, using whatever config genkernel produces. I use grub (grub2),
> and installed the kernel and initrd with “grub-mkconfig -o
> /boot/grub/grub.cfg”, as I normally do.
>
> Googling around shows that this problem tends to occur when grub can’t
> find the initrd.
>
> So  I looked at the grub boot script by pressing “e” just before the
> boot starts to make sure that grub is looking in the right place for
> the kernel and for the initrd.  I think it is, since deliberately
> misspelling either file name with the grub editor causes error
> messages saying grub can’t find what I told it to look for.  And those
> error messages do not occur with the boot script that grub generated.
>
> Normally, loading the initrd takes only a few seconds.
>
> How does one debug this situation?
>
> John

I'd start by removing any "quiet" or "splash" from the kernel command
line.    You should be able to see them when you hit "e". I'm not sure
if it will actually help, but it should be a start.

On Friday, 14 May 2021 00:06:07 BST John Blinka wrote:

> How does one debug this situation?

Just coming to this belatedly, not having noticed what may be a connection until now. I
have an Asus X99-A motherboard, and I never got grub to work at all. I use a
combination of efibootmgr and bootctl to manage my boot process. (Bootctl is in sys-
boot/systemd-boot; that's the only systemd package I have on this openrc system.)

You could look at the handbook [1] for how to set these up. I had to develop my own
method by picking bits out of it. I use efibootmgr to create entries in the UEFI BIOS, then
bootctl to keep them up to date. Oh, and I had to leave a small, otherwise unused
partition before the FAT32 boot partition. From parted:

Number Start End Size File system Name Flags
1 1.00MiB 9.00MiB 8.00MiB
2 9.00MiB 1025MiB 1016MiB fat32 boot, esp
3 1025MiB 50176MiB 49151MiB linux-swap(v1) swap
4 50176MiB 66560MiB 16384MiB ext4
5 66560MiB 132096MiB 65536MiB ext4
[...]
This may be a red herring of course; I wouldn't be too surprised if I'm doing things all
wrong, and your motherboard may differ from mine in many ways.


1. https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader[1]


--
Regards,
Peter.


--------
[1] https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader

mad.scientist.at.large@tutanota.com wrote:
>
> Have you recompiled the kernel?  Could be a random, erroneous write to disk or something in the kernel compile didn't go well.  I'd suggest also rebuilding the initrd and reinstalling grub.  I.e. I think there is likely a kernel compile issue since it doesn't ever launch the kernel succesfully either on autopilot or when you run grub interactive.  Might also recompile grub, perhaps there's a change in compiler options that produces an incompatible (at least partially).  I also suggest the rebuild so you can be sure you have the right initrd and matching kernel.
>
>


I had another thought.  Just in case it is a bug with grub that only
affects certain hardware, maybe try a different bootloader?  Maybe try
lilo or some other bootloader that works with your hardware.  I seem to
recall you having EFI so I'm sure there is plenty of those to choose from.

Dale

:-)  :-)

On Fri, May 14, 2021 at 7:32 PM Dale <rdalek1967@gmail.com> wrote:

>
> I had another thought. Just in case it is a bug with grub that only
> affects certain hardware, maybe try a different bootloader? Maybe try
> lilo or some other bootloader that works with your hardware. I seem to
> recall you having EFI so I'm sure there is plenty of those to choose from.


Good thought - I just now got a successful boot using efibootmgr. Peter
Humphries also suggested that somewhere in this thread, but also stated
that he couldn’t get grub to work on the same brand mobo (Asus). I’d
almost believe that it’s a grub-Asus thing except for the fact that
Sysrescue and Ubuntu both boot successfully. And I think they use grub.

Maybe time to experiment with a different version or fresh installation of
grub. Except that I’m burnt out on booting. Think I’ll go outside and dig
some holes.

John

>

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
> <mailto: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
> <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

On Sat, May 15, 2021 at 8:03 AM Todd Goodman <tsg@bonedaddy.net> wrote:

> 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
>

Thanks! This may actually be the crux of all the issues I’ve had. I’ve
now got this mobo booting gentoo from disk (instead of usb) while using
grub as the boot loader. I have not gotten X11 working. When I make the
kernel modifications advised in https://wiki.gentoo.org/wiki/Xorg/Guide, I
get the same black screen after loading the initrd as I did the first time
I started wrestling with this beast. Adding “nomodeset” to the boot
command gives me back my screen, but it interferes with X11. So, I’ll take
another look at the kernel config with your experience in mind.

Fingers crossed!

John

>