i’m using two devkit for this test . One as the server, and the other as the client for booting. I’ve already gone through this document. The network card I’m using is not the one that comes with the devkit(RJ45), but one that’s connected via an M.2 E slot(the wifi slot,i replace it) . Do I need to add the driver(ko) for this network card in the initrd? Even after I added it(I decompressed the initrd using gunzip and confirmed that the module is included under /lib/modules/.../updates/....), it still failed. I think the network card node is definitely not eth0. I tried eth1 and eth2, but neither worked.It still doesn’t work even when I use its Predictable Network Interface Names.I want to know the cause of the blockage. From what I can see, it has already reached the kernel and initrd loading stages, so DHCP and TFTP should be fine.
It sounds like it is waiting for a kernel or filesystem image over the network. Your initrd does require all modules needed to reach that point, e.g., if the kernel or filesystem are on the remote server, then you should see a log message on the server which mentions the request (along with whether the request succeeded or was denied). If you lack that log from the server, then it implies the Jetson never asked. Never asking might be for boot software requesting a kernel, but it is unlikely an initrd would be loaded if there is no kernel. The odds are that a module for networking must exist in the initrd; if this is the case, and if that module is lacking, then no PXE request will occur for the filesystem (it is possible for the kernel to be loaded differently than the filesystem; the filesystem implies an additional requirement above and beyond data access…it has to also understand ext4 or anything to read the filesystem).
A lot depends on whether or not you see requests logged on the server. Note that the only moment when this truly matters is when loading the initrd and then when the kernel itself takes over reading (in the initrd) via network.
I added earlycon to the kernel parameters and found that more logs are visible, but it gets stuck at the kernel panic here.The grubnetaa64.efi.signed, grub.cfg, Image, and initrd have all been sent to the boot endpoint.
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; preset: enabled)
Active: active (running) since Thu 2025-11-13 09:06:02 CST; 17min ago
Process: 1953 ExecStartPre=/usr/share/dnsmasq/systemd-helper checkconfig (code=exited, status=0/SUCCESS)
Process: 1993 ExecStart=/usr/share/dnsmasq/systemd-helper exec (code=exited, status=0/SUCCESS)
Process: 2033 ExecStartPost=/usr/share/dnsmasq/systemd-helper start-resolvconf (code=exited, status=0/SUCCESS)
Main PID: 1998 (dnsmasq)
Tasks: 1 (limit: 150286)
Memory: 66.7M (peak: 67.2M)
CPU: 6.326s
CGroup: /system.slice/dnsmasq.service
└─1998 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dp>
Nov 13 09:15:14 localhost.localdomain dnsmasq-tftp[1998]: error 8 User aborted the transfer received from 192.168.137.55
Nov 13 09:15:14 localhost.localdomain dnsmasq-tftp[1998]: sent /var/ftpd/efi/grubnetaa64.efi.signed to 192.168.137.55
Nov 13 09:15:15 localhost.localdomain dnsmasq-tftp[1998]: sent /var/ftpd/efi/grubnetaa64.efi.signed to 192.168.137.55
Nov 13 09:15:15 localhost.localdomain dnsmasq-tftp[1998]: file /var/ftpd/grub/arm64-efi/command.lst not found for 192.168.137.>
Nov 13 09:15:15 localhost.localdomain dnsmasq-tftp[1998]: file /var/ftpd/grub/arm64-efi/fs.lst not found for 192.168.137.55
Nov 13 09:15:15 localhost.localdomain dnsmasq-tftp[1998]: file /var/ftpd/grub/arm64-efi/crypto.lst not found for 192.168.137.55
Nov 13 09:15:15 localhost.localdomain dnsmasq-tftp[1998]: file /var/ftpd/grub/arm64-efi/terminal.lst not found for 192.168.137>
Nov 13 09:15:15 localhost.localdomain dnsmasq-tftp[1998]: sent /var/ftpd/grub/grub.cfg to 192.168.137.55
Nov 13 09:15:36 localhost.localdomain dnsmasq-tftp[1998]: sent /var/ftpd/Image to 192.168.137.55
Nov 13 09:15:39 localhost.localdomain dnsmasq-tftp[1998]: sent /var/ftpd/initrd to 192.168.137.55
[ 19.454869] Ethernet interfaces: eth1ernet: mgbe3_0 (HW ver: 42) created with 4 DMA channels
[ 24.697541] ERROR: initrd: ifconfig fail...
[ 24.698669] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
I want to stay in initrd without mounting NFS. How can I modify grub.cfg? I want to check if the network card driver loads properly and whether the network interfaces are created.
The above is likely from the driver not being found. ifconfig with no result is what you’d see if the network was not configured; if instead there is an actual error, then it implies the hardware driver is not installed.
Knowing how the initrd is designed might be useful to you. When booting directly the bootloader will load the kernel and then begin its execution; the kernel image must be from some form of storage, e.g., it can be a binary image in a partition, or it could be a file in an ext4 filesystem. The only way the partition binary content works is if the bootloader knows how to read the drive, which will always be the case if it is a mainstream technology (there is no filesystem and so no filesystem driver is required for that case). As soon as you put the kernel into a file on a filesystem, then the bootloader must understand that as well (first the bootloader must access the hardware storage, then it must find the kernel in the logic of the filesystem, a second driver). Rather than put an infinite number of filesystems into the bootloader the initrd was invented. It is an adapter between boot stages.
The initrd is just a very simple filesystem type which the bootloaders will all understand. If a kernel is loaded, and if the initrd is present, then it is possible to put things like custom filesystem drivers into the initrd for the kernel to load during boot. Had the initrd not been there, but had instead been trying to load a filesystem module from a filesystem the kernel does not understand, then you’d get a failure. Your PXE boot is a similar case, it is loading an initrd, and the kernel is loaded, and now the kernel needs the driver for the network card. Had that driver been directly embedded in the kernel, then you wouldn’t need the driver as a module, but there are sometimes good reasons to not burden a kernel with all integrated (non-module) drivers. It seems that the NIC driver is missing from your initrd. This is why you’d have an error from ifconfig instead of complaining about the PXE server.
Have you changed anything about the kernel? If there is a module in the initrd for the NIC, and if the main kernel does not itself have the NIC driver, then a failure to load the module (regardless of cause) would imply you can’t use the NIC to read PXE. It also says your PXE server won’t see any log messages about attempting to access its content (if the Jetson wanted content, then even if the content fails to load the server would have logged the attempt). It very much looks like the driver is missing or failing to load, and if a kernel is modified incorrectly, then the previous modules will be invalidated and fail to load. This, or simply not having the module in the initrd, is probably what is going on.
thank you very much for the reply. i have modprobe the driver now and I think there’s still an issue with the system driver in my NFS system; it crashed. Here’s the log:
[ 40.923035] NVRM: devm_reset_control_get failed, err: -2
[ 40.930371] NVRM: mipi_cal devm_reset_control_get failed, err: -2
[ 40.936685] ------------[ cut here ]------------
▒▒[ 68.906084] nvidia 0000:01:00.0: Direct firmware load for nvidia/580.00/gsp_ga10x.bin failed with error -2
[ 68.906239] NVRM: RmFetchGspRmImages: No firmware image found
[ 68.907596] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x61:0x56:1893)
[ 69.088247] nvidia 0000:01:00.0: Direct firmware load for nvidia/580.00/gsp_ga10x.bin failed with error -2
[ 69.088396] NVRM: RmFetchGspRmImages: No firmware image found
[ 69.096916] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0
[ 69.276764] nvidia 0000:01:00.0: Direct firmware load for nvidia/580.00/gsp_ga10x.bin failed with error -2
[ 69.276913] NVRM: RmFetchGspRmImages: No firmware image found
[ 69.285434] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0
▒▒INFO: END TASK:MB▒▒
INFO: enter idle task.
I’ve now switched to the Realtek network card that comes with the devkit to boot, and when using Samplefs for NFS, it also hangs.I don’t understand why there are the above errors. The contents in the lib/modules directory for both NFS and SampleRootfs are the same. Also, I don’t have a discrete GPU, so why is the GSP firmware for the GPU being loaded?
The system has booted, but there is no serial console. Pressing Enter has no response, and I cannot log in.The monitor is also showing a black screen.Even after selecting the boot option, the system still crashes when the HDMI cable is unplugged.
In addition to other errors I did see some “nvethernet a808d10000.ethernet” errors. Is this a developer’s kit? If not, then it needs a different device tree, but also, if you’ve changed the kernel itself, then it needs all new modules as well unless it was compiled with the correct matching configuration to the old kernel.
Incidentally, if the Jetson dropped into a bash shell, then it is very likely it is in the initrd and failed to find the next filesystem. You might be able to run “ifconfig” or “ip -s addr” in that shell. Should networking be up, then you might also be able to attempt to ping the PXE server. If networking is not up, then all else (other than failing to load modules which should be within the initrd and also valid for that kernel) is more or less just a side effect of failing to find the filesystem. --openrm was mentioned, and that could be part of incorrect modules, although it isn’t likely the full story.
I’ve replied above, it’s the BSP on the NVMe that is being used as NFS.Right now, I only have the power and Type-C debug serial cable plugged in, but it still crashes with this error. The serial console can print, but I can’t input. We urgently need to verify the feasibility of the connection. Could you provide a temporary patch?
yes.the rootfs used for nfs is the same with NVME which flashed to the devkit.the same Image as NVME rootfs /boot/Image，and the same initrd except add one more ethernet ko . however the totally same initrd result in the same crashed error
