Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

[William Kenworthy]

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

[gentoo-user] Re: [gentoo-user] Re: boot hangs forever at “Loading initial ramdisk...”

[John Blinka]

On Sat, May 15, 2021 at 8:03 AM Todd Goodman  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

>

Re: [gentoo-user] Asus laptop & brightness keys

[Emmanuel Vasilakis]

On 15/05/2021 14:12, Michael wrote:

On Saturday, 15 May 2021 11:46:46 BST Emmanuel Vasilakis wrote:

Hi!

I got a new Asus Zenbook laptop, with a ryzen 4500U processor. Most
things run great, except those brightness keys!

Nothing is reported when pressing them, either with showkeys or
acpi_listen, so I can't bind them to a shortcut. Brightness by changing
the value in /sys/class/backlight/amdgpu_b10/brightness works fine.

I have asus_wmi and asus_nb_wmi modules loaded, so things like
multitouch pad and keyboard backlight work fine.

I'm running a 5.10.27 gentoo sources kernel. Most people on the net say
that using the 'acpi_osi= ' parameter fixes it, but in my case it just
hangs at kernel boot. Did try e.g. acpi_osi=Linux, but nothing changed.

At the same time, using a live Manjaro usb both brightness keys work
fine, and they are usable under Gnome.

I'm sure I'm missing something in my kernel configuration Any ideas?

Thanks!


Assuming the Manjaro Live-USB is running the same version of kernel/modules
and firmware, then it is worth checking /proc/config.gz for the running
kernel's configuration and comparing it with your gentoo configuration.

Also while you're there you could check with lsmod what modules were loaded by
the Manjaro kernel to see if you're missing something.



Ah, I had gone through that! Looked at almost line by line the two 
dmesg, lsmod, configs etc. Of course Manjaro's config is  big!


Turns out there was something in ACPI page of kernel config that did the 
trick (not sure what exactly to be honest - might be Video).


Thanks though!

[gentoo-user] Re: boot hangs forever at “Loading initial ramdisk...”

[Todd Goodman]

On 5/14/2021 5:15 PM, John Blinka wrote:

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


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

Re: [gentoo-user] Asus laptop & brightness keys

[Michael]

On Saturday, 15 May 2021 11:46:46 BST Emmanuel Vasilakis wrote:
> Hi!
> 
> I got a new Asus Zenbook laptop, with a ryzen 4500U processor. Most
> things run great, except those brightness keys!
> 
> Nothing is reported when pressing them, either with showkeys or
> acpi_listen, so I can't bind them to a shortcut. Brightness by changing
> the value in /sys/class/backlight/amdgpu_b10/brightness works fine.
> 
> I have asus_wmi and asus_nb_wmi modules loaded, so things like
> multitouch pad and keyboard backlight work fine.
> 
> I'm running a 5.10.27 gentoo sources kernel. Most people on the net say
> that using the 'acpi_osi= ' parameter fixes it, but in my case it just
> hangs at kernel boot. Did try e.g. acpi_osi=Linux, but nothing changed.
> 
> At the same time, using a live Manjaro usb both brightness keys work
> fine, and they are usable under Gnome.
> 
> I'm sure I'm missing something in my kernel configuration Any ideas?
> 
> Thanks!

Assuming the Manjaro Live-USB is running the same version of kernel/modules 
and firmware, then it is worth checking /proc/config.gz for the running 
kernel's configuration and comparing it with your gentoo configuration.

Also while you're there you could check with lsmod what modules were loaded by 
the Manjaro kernel to see if you're missing something.

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Asus laptop & brightness keys

[Emmanuel Vasilakis]

Hi!

I got a new Asus Zenbook laptop, with a ryzen 4500U processor. Most 
things run great, except those brightness keys!


Nothing is reported when pressing them, either with showkeys or 
acpi_listen, so I can't bind them to a shortcut. Brightness by changing 
the value in /sys/class/backlight/amdgpu_b10/brightness works fine.


I have asus_wmi and asus_nb_wmi modules loaded, so things like 
multitouch pad and keyboard backlight work fine.


I'm running a 5.10.27 gentoo sources kernel. Most people on the net say 
that using the 'acpi_osi= ' parameter fixes it, but in my case it just 
hangs at kernel boot. Did try e.g. acpi_osi=Linux, but nothing changed.


At the same time, using a live Manjaro usb both brightness keys work 
fine, and they are usable under Gnome.


I'm sure I'm missing something in my kernel configuration Any ideas?

Thanks!

Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

[Peter Humphrey]

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.