[Solved] Installing Ethernet Drivers on Installation Media

[pingtoo]

I realize my mistake. One should not do switch_root inside dracut emergency_shell.

my apology for given wrong instruction.

For testing the setup problem the correction action should be

Code: Select all

mount /dev/nvme0n1p3 /sysroot -o ro
exit 

Once exit from the emergency_shell, dracut will automatically resume from failed mounting root and should be able to do the switch_root in its own logic.

I should have caught this condition when you said in went back in a loop. Sorry for wasting your time for doing those unnecessary work.

This is the disadvantage debug from remote, I think switch_root should actually report an error condition state that the parent process ID is not 1 and cannot do its work. but dracut would mess up the output because its way of working.


Anyway wish you have safe trip. And welcome back whenever you feel comfortable.

[xevra]

Pingtoo,

Thank you for the information and assistance.

Please do not worry about wasting my time. I don't see it that way. I am learning a lot!

I am happy to persist in the installation upon my return.

Until then, take care!

[NeddySeagoon]

xevra,

We will be here. Have a safe trip.

[xevra]

Hello again,

I have returned, and fooled around a bit on my other laptop (hostname Ryu-Ran), installing Gentoo 3 times using different settings, and writing down every command I entered into the terminal (apart from things that change no settings like "ls").

I have not turned on the machine with the Ethernet driver problem (hostname: Pharaon).

The last set of instructions for Ryu-Ran are as follows:

Code: Select all

# I'm going to attempt to install a testing version of the kernel

fdisk /dev/sda
g
n
[Enter]
[Enter]
+1G
[Y]
t
[Enter]
1
n
[Enter]
[Enter]
+12G
[Y]
t
[Enter]
19
n
[Enter]
[Enter]
[Enter]
[Y]
t
[Enter]
23
w

# Preparing the disks
mkfs.vfat -F 32 /dev/sda1
mkswap /dev/sda2
mkfs.xfs /dev/sda3
swapon /dev/sda2
mount /dev/sda3 /mnt/gentoo/
mkdir /mnt/gentoo/efi
mount /dev/sda1 /mnt/gentoo/efi

# Downloading the stage file
cd /mnt/gentoo
chronyd -q
wget https://distfiles.gentoo.org/releases/amd64/autobuilds/20250223T170333Z/stage3-amd64-openrc-20250223T170333Z.tar.xz
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo

# Changes to make.conf
nano /mnt/gentoo/etc/portage/make.conf
-------------------------------------------------------------------------------
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
COMMON_FLAGS="-O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

# NOTE: This stage was built with the bindist USE flag enabled

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C.utf8
USE="ugrd -systemd dist-kernel suid X"
NTHREADS=8
MAKEOPTS="-j8 -l9"
EMERGE_DEFAULT_OPTS="--jobs 8"
GRUB_PLATFORMS="efi-64"
ACCEPT_LICENSE="* -@EULA"
-------------------------------------------------------------------------------

# Changes to accept_keywords
nano /mnt/gentoo/etc/portage/package.accept_keywords/gentoo-sources
-------------------------------------------------------------------------------
sys-kernel/* ~amd64
virtual/dist-kernel ~amd64
dev-util/pahole ~amd64
app-text/ascii-doc ~amd64
-------------------------------------------------------------------------------

# Changes to locale.gen
nano /mnt/gentoo/etc/locale.gen
-------------------------------------------------------------------------------
en_US ISO-8859-1
en_US.UTF-8 UTF-8
-------------------------------------------------------------------------------

# Changes to installkernel
nano /mnt/gentoo/etc/portage/package.use/installkernel
-------------------------------------------------------------------------------
sys-kernel/installkernel grub ugrd
-------------------------------------------------------------------------------

# Fstab
nano /mnt/gentoo/etc/fstab
-------------------------------------------------------------------------------
/dev/sda1 /efi vfat umask=0077 0 2
/dev/sda2 none swap sw 0 0
/dev/sda3 / xfs defaults,noatime 0 1
-------------------------------------------------------------------------------

# Copy network stuff
cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

# Enter the filesystem
arch-chroot /mnt/gentoo
source /etc/profile

# Sync Portage
emerge-webrsync

# locale-gen
locale-gen
source /etc/profile
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"

# Install the kernel
emerge --ask sys-kernel/linux-firmware
# Note, with the USE flag for dist-kernel, this will install the kernel
# In the future, it may be better to install this before adding dist-kernel
#   to the use flags, and then recompiling it once the dist-kernel
#   has been installed.

# Setup
echo "Ryu-Ran" > /etc/hostname
passwd

# Manage packages and DHCPCD and SSHD
emerge --ask net-misc/dhcpcd app-shells/bash-completion sys-fs/xfsprogs sys-fs/dosfstools
rc-update add dhcpcd default
rc-update add sshd default

# GRUB
emerge --ask --verbose sys-boot/grub
grub-install --efi-directory=/efi
grub-mkconfig -o /boot/grub/grub.cfg

# Chrony
emerge --ask net-misc/chrony
chronyd -q

# Reboot
exit
cd
umount -R /mnt/gentoo
reboot

My Gentoo speedrun installation (no binaries category) is down to 3 hours on Ryu-Ran, and with

Code: Select all

eselect kernel list

, I can verify that I am running linux-6.13.4-gentoo-dist on Ryu-Ran.

This is a newer kernel than 6.13.1, which is currently the version on Pharaon. So if part of the intention of this test was to verify that there's no issues with the testing packages, I have only verified that there are no issues which present themselves on Ryu-Ran now, and have not verified either the version of the packages installed on Pharaon or the use case with different hardware.

I did leave march alone in the make.conf file this time (see above), so I want to think that this installation of Gentoo may be able to run on Pharaon if I copy everything over.

Do you advise that at this time, and if so, how?

Thank you again for your time and energy!
Xevra

[xevra]

Running

Code: Select all

rc-service dhcpcd start

returns a warning:

Code: Select all

No permission to apply cgroup settings

.

This appears to be because way back when I installed the stage 3 tarball, I didn't use the "--xattrs='*.*'" flag.

I think I just ran

Code: Select all

tar [letters] stage3*.tar.xz

I'm not sure if this is connected to my issues with the initramfs, but I think this is a good time to start over with a fresh stage 3, to grab a new portage snapshot, and attempt to install 6.13.4 and ugrd (instead of dracut).

I'll get started on that.

[xevra]

Clarification: It only returns that warning while chrooted.

Edit: Further clarification: and no, it still doesn't find my ethernet devices.

[xevra]

Okay, so the good news is that tar-ing and un-tar-ing /var/db/repos/gentoo and /var/cache/distfiles from a functional build with 6.13.4 is much faster and less of a headache than wget-ing the files and copying them over one at a time as emerges fail.

More good news is that the 6.13.4 kernel compiles with no issue, and grub both compiled and installed successfully.

Grub loads on boot, and directs to the initramfs, just as it did before.

The bad news is that even with ugrd (instead of dracut), I'm still not booting with the new setup.

It's now complaining about a kernel panic (copied by hand, so there may be typos):

Code: Select all

md: autorun ...
md: ... autorun DONE.
/dev/root: Can't open blockdev
VFS: Cannot open root device "UUID=4643c03f-299a-4e28-b975-5c95b56244f0" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
List of all bdev filesystems:
 ext3
 ext2
 ext4
 xfs
 btrfs

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.4-gentoo-dist #1
Hardware name: Gigabyte Technology Co., Ltd. X870 AORUS ELITE WIFI7 ICE/X870 AORUS ELITE WIFI7 ICE, BIOS F2 08/14/2024
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 panic+0x155/0x327
 mount_root_generic+0x1ce/0x270
 prepare_namespace+0x1ec/0x240
 kernel_init_freeable+0x2d7/0x310
 ? __pfx_kernel_init+0x10/0x10
 kernel_init+0x1a/0x140
 ret_from-fork+0x31/0x50
 ? __pfx_kernel_init+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>
Kernel Offset: 0x22000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

How should I interpret this?

[NeddySeagoon]

xevra,

Code: Select all

VFS: Cannot open root device "UUID=4643c03f-299a-4e28-b975-5c95b56244f0" or unknown-block(0,0)

The last part, unknown-block(0,0), tells that the kernel cannot see the hardware for any of your block devices. Probably because you need to load modules.

Code: Select all

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) 

Tells that you are not using an initrd, even if you have one, or would would have been dropped to a shell.

The initrd will contain the modules that you need, so its one problem, initrd related.

[pingtoo]

xevra,

can you review the UUID=4643c03f-299a-4e28-b975-5c95b56244f0?

is the value 4643c03f-299a-4e28-b975-5c95b56244f0 belong to UUID or PARTUUID?

[xevra]

xevra,

can you review the UUID=4643c03f-299a-4e28-b975-5c95b56244f0?

is the value 4643c03f-299a-4e28-b975-5c95b56244f0 belong to UUID or PARTUUID?

This is the UUID (not PARTUUID) for /dev/nvme0n1p3, the root partition of my SSD.

It is a 4 Tb Crucial SSD.

When I run fdisk /dev/nvme0n1, and enter 'p', my output is

Code: Select all

Device Start End Sectors Size Type
/dev/nvme0n1p1      2048    2099199    2097152 1G EFI System
/dev/nvme0n1p2   2099200  270534655  268435456 128G Linux swap
/dev/nvme0n1p3 270534656 7814035455 7543500800 3.5T Linux root (x86-64)

My /etc/fstab is

Code: Select all

/dev/nvme0n1p1 /efi vfat umask=0077 0 2
/dev/nvme0n1p2 none swap sw 0 0
/dev/nvme0n1p3 / xfs defaults,noatime 0 1

blkid has this to say about the devices:

Code: Select all

/dev/nvme0n1p3: UUID="4643c03f-299a-4e28-b975-5c95b56244f0" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="6f7921b9-6801-4905-9a33-506de5659ba4"
/dev/nvme0n1p1: UUID="15DB-FB60" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3f2e48ee-5685-452d-a208-b85e0ecbd1ad"
/dev/nvme0n1p2: UUID="78233f8d-e2cd-4d60-8de1-ec3319bb2be5" TYPE="swap" PARTUUID="57f96436-1df3-466d-b76f-77496137dd66"

Thank you!

Edit: Correction to PARTUUID of nvme0n1p2.

[xevra]

xevra,

Code: Select all

VFS: Cannot open root device "UUID=4643c03f-299a-4e28-b975-5c95b56244f0" or unknown-block(0,0)

The last part, unknown-block(0,0), tells that the kernel cannot see the hardware for any of your block devices. Probably because you need to load modules.

Code: Select all

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) 

Tells that you are not using an initrd, even if you have one, or would would have been dropped to a shell.

The initrd will contain the modules that you need, so its one problem, initrd related.

Thank you for the explanation! I will take a look around and see if I can determine what is wrong with the initrd.

[NeddySeagoon]

xevra,

Does your initrd exist at all?
In it listed in grub?

You may have several initrds, Its common now for the CPU microcode to be in its own initrd.
They should be listed in grub in the same boot stanza.

[pietinger]

xevra,

maybe read this:
https://wiki.gentoo.org/wiki/User:Pieti ... %3DUUID%3D
to understand why you have a kernel panic when NOT having an initramfs AND using UUID (instead PARTUUID).

[pingtoo]

xevra,

Thanks for confirmation.

Now we know it is on /dev/nvme0n1p3. So new question, Do your kernel support nvme? is it configured static (builtin) or module (load by initrd)

[xevra]

xevra,

Does your initrd exist at all?
In it listed in grub?

You may have several initrds, Its common now for the CPU microcode to be in its own initrd.
They should be listed in grub in the same boot stanza.

NeddySeagoon,

When I run

Code: Select all

grub-mkconfig -o /boot/grub/grub.cfg

The output I get is

Code: Select all

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.13.4-gentoo-dist
Found initrd image: /boot/amd-uc.img /boot/initramfs-6.13.4-gentoo-dist.img
Found linux image: /boot/vmlinuz-6.13.4-gentoo-dist.old
Found initrd image: /boot/amd-uc.img /boot/initramfs-6.13.4-gentoo-dist.img.old
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

This leads me to believe that there is an initrd, and grub is finding it. I've also added "initramfs" to my use flags and tried to emerge --update --newuse sys-kernel/gentoo-kernel sys-boot/grub, and it found nothing to update. Is there something else I should check to verify that there is an initrd?

Thank you,
Xevra

[xevra]

xevra,

maybe read this:
https://wiki.gentoo.org/wiki/User:Pieti ... %3DUUID%3D
to understand why you have a kernel panic when NOT having an initramfs AND using UUID (instead PARTUUID).

Pietinger,

Thank you for pointing me at this. This is informative, and lends support to the current hypothesis that the initramfs installed on the machine is not being loaded for some reason.

I'm using a dist-kernel, so I do need an initramfs, and determining why the initramfs is not working seems to be the key issue here.

I did recently find viewtopic-t-1172671.html

So it appears somebody has successfully installed gentoo with a very similar motherboard before, but they configured the kernel manually, which I have not successfully done more than once before.

FWIW - this is now trivial. Edit /etc/default/grub and uncomment the line: GRUB_CMDLINE_LINUX="net.ifnames=0"

I did try this, and it didn't work for me. There's other stuff in this thread I could try too, but I don't understand all of it.

The most surprising thing about that thread to me, is that it seems like they got it working with version 6.6 of the kernel, when as you pointed out earlier: https://github.com/torvalds/linux/commi ... e2fc5db1df

Support for this hardware was added in 6.13.

It looks like there were 8 motherboards in this series: https://www.gigabyte.com/Motherboard/Al ... s?fid=3065

And all of them have "WIFI7", though they have different network speeds (and it's not the WIFI drivers I am trying to use; it's ethernet).

Is it possible that a web install would be possible if I used the most recent (Feb 16) livecd?

Edit: I have manually installed a kernel before on one of my broken laptops, but even though I got a successful boot, I couldn't then install xfce on it, so I trashed that partition and started over. It was before I had the confidence to ask the community for help, otherwise I might have tried harder with the manual kernel.

[xevra]

xevra,

Thanks for confirmation.

Now we know it is on /dev/nvme0n1p3. So new question, Do your kernel support nvme? is it configured static (builtin) or module (load by initrd)

I'm using a distribution kernel, and I'm not sure how to verify that nvme is supported.

There doesn't seem to be a sys-kernel/gentoo-kernel or sys-kernel/installkernel USE flag for nvme.

[pingtoo]

xevra,

Thanks for confirmation.

Now we know it is on /dev/nvme0n1p3. So new question, Do your kernel support nvme? is it configured static (builtin) or module (load by initrd)

I'm using a distribution kernel, and I'm not sure how to verify that nvme is supported.

There doesn't seem to be a sys-kernel/gentoo-kernel or sys-kernel/installkernel USE flag for nvme.

Were you able to see boot messages? there should be some lines refer to "nvme" (I am not sure about the exact string).

Another thing you can try is to change the kernel command line from "uuid=XXXX..." to "partuuid=XXXX..." where XXXX is your /dev/nvme0n1p3's PARTUUID,

It is ok to use UUID=XXXX... if your initrd support it. however to test, try PARTUUID=XXXX..., this way kernel can detect the rootfs partition directly without initrd (This is assume grub did not load initrd)

Last time from your post it is PARTUUID="6f7921b9-6801-4905-9a33-506de5659ba4"

If this work, it probably mean something wrong in your execution of setup ugrd or installkernel or grub that somehow not using generated initrd.

[pietinger]

xevra,

as far as I understand your "initial" problem was/is that your new machine has an ethernet card which is not supported in kernel version 6.6 (but in 6.13 or 6.14?) - is my understanding correct here?

I see you have managed to install Gentoo and also understand what an initramfs is (and for what its used). In my opinion the easiest way to solve your initial problem is:

* Boot with the newest LiveUbuntu and check if you are online. Proceed if you are online with:

* Install a very simple Gentoo with all defaults (you can change later everything you want) ... here is a shortcut where you have to deviate in some steps (because Ubuntu dont have "arch-chroot") ... dont use "ugrd" ... install the unstable Gentoo-distribution-bin-kernel (this kernel has EVERYTHING you need compiled in - of course also NVMe). ...

Changes to this steps: https://wiki.gentoo.org/wiki/User:Pieti ... EFI_System

* Instead "arch-root" you need this (at/instead step: https://wiki.gentoo.org/wiki/User:Pieti ... tem#Chroot):
https://wiki.gentoo.org/wiki/Handbook:A ... ilesystems
->

Code: Select all

cp -L /etc/resolv.conf etc
mount --types proc /proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --make-rslave /mnt/gentoo/dev
mount --bind /run /mnt/gentoo/run
mount --make-slave /mnt/gentoo/run
test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
mount --types tmpfs --options nosuid,nodev,noexec shm 
chmod 1777 /dev/shm /run/shm
chroot /mnt/gentoo /bin/bash

* Bevor emerging the dist-kernel-bin (at the beginning of https://wiki.gentoo.org/wiki/User:Pieti ... tem#Kernel) you add these steps (you have done this already BEFORE chrooting but you can do this also AFTER chrooting; then it is easier):

Code: Select all

# mkdir -p /etc/portage/package.accept_keywords
# nano /etc/portage/package.accept_keywords/gentoo-dist-kernel

-> (~amd64 is NOT necessary; there exist no app-text/ascii-doc ... only app-text/asciidoc; but we have only a stable version at the moment)

sys-kernel/gentoo-kernel-bin
sys-kernel/linux-headers
virtual/dist-kernel
dev-util/pahole

(Of course you change also mkfs.ext4 with mkfs.xfs if you want XFS)

(If you have a problem with "chronyd -q" please read 03 of: https://wiki.gentoo.org/wiki/User_talk: ... this_Guide)

After the reboot you will find out if 6.13.5 recognizes your new ethernet card ...

[xevra]

Were you able to see boot messages? there should be some lines refer to "nvme" (I am not sure about the exact string).

Another thing you can try is to change the kernel command line from "uuid=XXXX..." to "partuuid=XXXX..." where XXXX is your /dev/nvme0n1p3's PARTUUID,

It is ok to use UUID=XXXX... if your initrd support it. however to test, try PARTUUID=XXXX..., this way kernel can detect the rootfs partition directly without initrd (This is assume grub did not load initrd)

Last time from your post it is PARTUUID="6f7921b9-6801-4905-9a33-506de5659ba4"

If this work, it probably mean something wrong in your execution of setup ugrd or installkernel or grub that somehow not using generated initrd.

Pingtoo,

Thanks for the suggestions.

I tried changing these calls in the /boot/grub/grub.cfg file, and I still got the same kernel panic.

I tried changing the fstab to look at the PARTUUIDs as well, and that didn't work either.

I'm going to try Pietinger's suggestions next.

[pingtoo]

Were you able to see boot messages? there should be some lines refer to "nvme" (I am not sure about the exact string).

Another thing you can try is to change the kernel command line from "uuid=XXXX..." to "partuuid=XXXX..." where XXXX is your /dev/nvme0n1p3's PARTUUID,

It is ok to use UUID=XXXX... if your initrd support it. however to test, try PARTUUID=XXXX..., this way kernel can detect the rootfs partition directly without initrd (This is assume grub did not load initrd)

Last time from your post it is PARTUUID="6f7921b9-6801-4905-9a33-506de5659ba4"

If this work, it probably mean something wrong in your execution of setup ugrd or installkernel or grub that somehow not using generated initrd.

Pingtoo,

Thanks for the suggestions.

I tried changing these calls in the /boot/grub/grub.cfg file, and I still got the same kernel panic.

I tried changing the fstab to look at the PARTUUIDs as well, and that didn't work either.

I'm going to try Pietinger's suggestions next.

Thanks, and please go ahead to preceed with Pietinger's suggestion.

However I like to point out your SHOULD NOT get same kernel panic. At least the line that said

VFS: Cannot open root device "UUID=4643c03f-299a-4e28-b975-5c95b56244f0" or unknown-block(0,0)

would have changed to

VFS: Cannot open root device "PARTUUID=6f7921b9-6801-4905-9a33-506de5659ba4" or unknown-block(0,0)

I know I may be picky but since I am not set in front of the computer I have no way to judge what happen.

So if really come out exact same error messages then it mean your change to grub.cfg did not take effect, or you pick a wrong line to boot.

If PARTUUID=... still does not work then most likely your kernel have some problem detect nvme device.

[NeddySeagoon]

xevra,

The distribution kernel is fully modular. That makes sense in a boot anywhere kernel.
Being fully modular, it depends on the modules in the initrd to be able to mount root.
No initrd loading, no chance.

It will have NVMe support - as a module. If NVMe support was missing it the distribution kernel, that would be a bug.
A lot of people would be unhappy and it would be all over the forums.

Lets find out what happened to your initrd.
Post the output of

Code: Select all

ls -l /boot

That should show your kernels and initrds.

Post the content of /boot/grub/grub.cfg
That may be better an a pastebin.
It will show what grub loads.

The new Gentoo live media will have kernel 6.12.y as that has been stabled recently.

Going back to viewtopic-p-8853829.html#8853829 and that patch, it appeared in 6.13.0.
If you have RTL8125D you need 6.13.0 or newer, or to apply the patch to an older kernel, if you can.
That tells that the latest Gentoo Live media will not help.

[xevra]

Thanks all,

I still have more things to try, but while I'm doing those things, if I ls -l /boot, the output is:

Code: Select all

total 69124
-rw-r--r-- 1 root root 10948155 Feb 28 08:54 System.map-6.13.4-gentoo-dist
-rw-r--r-- 1 root root 10948155 Feb 28 08:16 System.map-6.13.4-gentoo-dist.old
-rw-r--r-- 1 root root   148480 Feb 28 08:54 amd-uc.img
-rw-r--r-- 1 root root   280404 Feb 28 08:54 config-6.13.4-gentoo-dist
-rw-r--r-- 1 root root   280404 Feb 28 08:16 config-6.13.4-gentoo-dist.old
drwxr-xr-x 6 root root      164 Mar  2 00:01 grub
-rw-r--r-- 1 root root  3763116 Feb 28 08:54 initramfs-6.13.4-gentoo-dist.img
-rw-r--r-- 1 root root  3763056 Feb 28 08:16 initramfs-6.13.4-gentoo-dist.img.old
-rw-r--r-- 1 root root 20316672 Feb 28 08:54 vmlinuz-6.13.4-gentoo-dist
-rw-r--r-- 1 root root 20316672 Feb 28 08:16 vmlinuz-6.13.4-gentoo-dist.old

[NeddySeagoon]

xevra,

That looks good. You have two kernels and two initrd that look to be matched sets

Code: Select all

-rw-r--r-- 1 root root  3763116 Feb 28 08:54 initramfs-6.13.4-gentoo-dist.img
-rw-r--r-- 1 root root  3763056 Feb 28 08:16 initramfs-6.13.4-gentoo-dist.img.old
-rw-r--r-- 1 root root 20316672 Feb 28 08:54 vmlinuz-6.13.4-gentoo-dist
-rw-r--r-- 1 root root 20316672 Feb 28 08:16 vmlinuz-6.13.4-gentoo-dist.old 

They should both be in the grub menu

One boot stanza in grub.cfg should say

Code: Select all

echo "Loading kernel ..."
kernel vmlinuz-6.13.4-gentoo-dist ...
echo "Loading initrd ..." 
initrd initramfs-6.13.4-gentoo-dist.img

I suppose you do have initrd support enabled in the kernel?

[xevra]

Going back to viewtopic-p-8853829.html#8853829 and that patch, it appeared in 6.13.0.
If you have RTL8125D you need 6.13.0 or newer, or to apply the patch to an older kernel, if you can.
That tells that the latest Gentoo Live media will not help.

Empirically, no, the latest Gentoo Live media does not help.

Neither Arch, nor Ubuntu, nor SystemRescue have boot media with 6.13 yet.

My first instinct was to look for a Sid image, but I had trouble finding one. I'm not sure Debian makes a bootable Sid live media.

Anyway, back to debugging the initramfs.