Mailing List Archive

On 14/5/21 2:35 pm, John Covici wrote:
> On Thu, 13 May 2021 21:58:25 -0400,
> John Blinka wrote:
>> [1 <text/plain; UTF-8 (quoted-printable)>]
>> On Thu, May 13, 2021 at 9:12 PM Jack <ostroffjh@users.sourceforge.net>
>> 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

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.


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

On Fri, May 14, 2021 at 3:12 AM William Kenworthy <billk@iinet.net.au> 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

>
>

On Fri, May 14, 2021 at 7:50 AM John Blinka <john.blinka@gmail.com> wrote:

>
>
> On Fri, May 14, 2021 at 3:12 AM William Kenworthy <billk@iinet.net.au>
> 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

>

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

--"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.blinka@gmail.com:

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

On Fri, May 14, 2021 at 7:10 PM <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


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

>

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.

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.large@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.blinka@gmail.com:
>
>> 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
>>
> 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.
>