Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
Hi, genkernel keeps a very detailed log at /run/iniramfs/gksoreport.txt. (or similar) When it exits to the cant find root prompt, type "shell" and you can read/save the report. BillK On 15/5/21 7:10 am, mad.scientist.at.la...@tutanota.com wrote: > --"Fascism begins the moment a ruling class, fearing the people may use their > political democracy to gain economic democracy, begins to destroy political > democracy in order to retain its power of exploitation and special > privilege." Tommy Douglas > > > > > May 14, 2021, 15:15 by john.bli...@gmail.com: > >> n >> >> >> On Fri, May 14, 2021 at 2:36 AM John Covici <> cov...@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 >> > 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. >
Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Saturday, 15 May 2021 00:54:02 BST John Blinka wrote: > I don’t think it’s a kernel compile issue. I just now used efibootmgr to > create a uefi entry with kernel command line parameters to define the root > fs and initrd. That worked. That result focuses the blame on grub. I'm glad that worked. Personally, I'm pleased to have ditched grub altogether. -- Regards, Peter Humphrey.
Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
--"Fascism begins the moment a ruling class, fearing the people may use their political democracy to gain economic democracy, begins to destroy political democracy in order to retain its power of exploitation and special privilege." Tommy Douglas May 14, 2021, 15:15 by john.bli...@gmail.com: > n > > > On Fri, May 14, 2021 at 2:36 AM John Covici <> cov...@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 > 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.
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Fri, May 14, 2021 at 7:10 PM 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 Yes. Same problems with several kernels and associated initrds, the latter produced by genkernel or dracut or even some gibberish I pretended was an initrd. From grub debug output, I believe the problem exists right before the kernel tries to use the initrd. It’s contents are irrelevant at that stage. and reinstalling grub. That may or may not be the answer, but it’s such an obvious step. Will definitely give that a try. 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 don’t think it’s a kernel compile issue. I just now used efibootmgr to create a uefi entry with kernel command line parameters to define the root fs and initrd. That worked. That result focuses the blame on grub. John >
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
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
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Fri, May 14, 2021 at 7:50 AM John Blinka wrote: > > > On Fri, May 14, 2021 at 3:12 AM William Kenworthy > wrote > >> > >> Try https://wiki.ubuntu.com/DebuggingKernelBoot ... I am not sure >> genkernel uses that exact name but I did need to find the initramfs boot >> log to diagnose a failure in a genkernel initramfs at one time. > > Unfortunately, made no difference and provided no new information. https://www.askapache.com/linux/linux-debugging/ might be too old to be relevant any more, but tried almost everything it suggested to obtain debugging output. Not one byte of debug info appeared. Going to try the dracut approach suggested elsewhere. John >
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Fri, May 14, 2021 at 3:12 AM William Kenworthy wrote > > > Try https://wiki.ubuntu.com/DebuggingKernelBoot ... I am not sure > genkernel uses that exact name but I did need to find the initramfs boot > log to diagnose a failure in a genkernel initramfs at one time. That’s an intriguing link. Exploring it now. John > >
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
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. Here’s what I see when pressing “e” just before the system attempts to boot: setparams ‘Gentoo GNU/Linux’ load_video if [ “x$grub_platform” = xefi ]; then set gfxpayload=keep fi insmod gzio insmod part_gpt insmod fat set root=‘hd0,gpt2’ if [ x$feature_platform_search_hint = xy ]; then search —no-floppy —fs-uuid —set=root —hint-bios=hd0,gpt2 —hint-baremetal=ahci0, got2 5C75-30A0 else search —no-floppy —fs-uuid —set=root 5C75-30A0 fi echo‘Loading Linux 5.10.27-gentoo-x86_64 ...’ linux /vmlinuz-5.10.27-gentoo-x86_64 root=UUID=0df096ca-4dc8-4325-9296-7b0ddb67f044 ro loglevel=4 nomodeset echo‘Loading initial ramdisk ...’ initrd/early_ucode.cpio /initramfs-5.10.27-gentoo-x86_64.img I have checked the uuid and filenames - they are correct. (hd0,gpt2) makes sense. There’s only 1 disk connected, it uses gpt, and the second partition is a fat boot partition with the above uuid. The named files exist on that partition. I don’t see anything in ‘man genkernel’ that looks like a way to get debug info out of an initrd/initramfs. Looks like there’s a way to turn it off, so perhaps it’s on by default? John
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On 14/5/21 2:35 pm, John Covici wrote: > On Thu, 13 May 2021 21:58:25 -0400, > John Blinka wrote: >> [1 ] >> On Thu, May 13, 2021 at 9:12 PM Jack >> wrote: >> >>> Given you say the UUID is for the boot partition, then both the linux and >>> initrd should just have the name of the kernel and initrd files (without >>> leading "/boot",) which sounds like what you've got. I'd next wonder if >>> something is missing from the kernel/initrd combination, such as a kernel >>> module necessary for some early part of the boot process or a file system >>> (per Dale's suggestion.) Assuming that you ran genkernel after booting a >>> live image and chrooting into the new system, then we know the hardware can >>> boot a good kernel/image combo. Mainly I'm just thinking out loud here, >>> trying to coax someone's little gray cells into action. >>> >> In my early linux days, I thought it would be clever to include kernel >> support for my root filesystem in a module. Whose code resided on the root >> filesystem... That didn’t work, of course, but at least the kernel started >> to boot and threw out an error message. Here, I just get complete >> silence. So, I doubt that file system support is an issue. >> >> John > 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. > Try https://wiki.ubuntu.com/DebuggingKernelBoot ... I am not sure genkernel uses that exact name but I did need to find the initramfs boot log to diagnose a failure in a genkernel initramfs at one time. BillK
Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Thu, 13 May 2021 21:58:25 -0400, John Blinka wrote: > > [1 ] > On Thu, May 13, 2021 at 9:12 PM Jack > wrote: > > > Given you say the UUID is for the boot partition, then both the linux and > > initrd should just have the name of the kernel and initrd files (without > > leading "/boot",) which sounds like what you've got. I'd next wonder if > > something is missing from the kernel/initrd combination, such as a kernel > > module necessary for some early part of the boot process or a file system > > (per Dale's suggestion.) Assuming that you ran genkernel after booting a > > live image and chrooting into the new system, then we know the hardware can > > boot a good kernel/image combo. Mainly I'm just thinking out loud here, > > trying to coax someone's little gray cells into action. > > > In my early linux days, I thought it would be clever to include kernel > support for my root filesystem in a module. Whose code resided on the root > filesystem... That didn’t work, of course, but at least the kernel started > to boot and threw out an error message. Here, I just get complete > silence. So, I doubt that file system support is an issue. > > John 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. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Thu, May 13, 2021 at 9:12 PM Jack wrote: > Given you say the UUID is for the boot partition, then both the linux and > initrd should just have the name of the kernel and initrd files (without > leading "/boot",) which sounds like what you've got. I'd next wonder if > something is missing from the kernel/initrd combination, such as a kernel > module necessary for some early part of the boot process or a file system > (per Dale's suggestion.) Assuming that you ran genkernel after booting a > live image and chrooting into the new system, then we know the hardware can > boot a good kernel/image combo. Mainly I'm just thinking out loud here, > trying to coax someone's little gray cells into action. > In my early linux days, I thought it would be clever to include kernel support for my root filesystem in a module. Whose code resided on the root filesystem... That didn’t work, of course, but at least the kernel started to boot and threw out an error message. Here, I just get complete silence. So, I doubt that file system support is an issue. John
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”
On Thu, May 13, 2021 at 9:10 PM Dale wrote: > > I hate these init thingys and will admit I know little about the > things. I had a thought tho, could it be that the file system needed to > read the init thingy isn't included somehow or in the kernel maybe? If > it is pointing to the right place, sounds like it is to me, then it has > to be a read problem I'd think. All the uefi stuff is on a fat filesystem. I would think that something that fundamental (and universally supported) is embedded in the bios. The grub bootloader itself is on that fat filesystem, and it must have loaded or else I wouldn’t have access to the grub edit facility. So I think I’m ok on file system support. > > I haven't ever had to use the edit menu on grub2 that I remember. It > might be worth mentioning that it may have tab completion. That would > certainly remove a typo if it can complete the kernel or init thingys > file name on its own. Just a thought. Grub documentation says it does have tab completion. But the file names, uuids, and other things prone to typos that I referenced are generated by grub, so typos are unlikely to be an issue. And I’ve checked them meticulously. They look ok. > > Going back under my desk now. Maybe I’d be less frustrated by this new mobo if I did the same! ;) John