Hello,
We are experiencing operating system problems with the two Jetson AGX Orin Developer Kits we own. The screen was closed due to the “sudo service gdm stop” code we wrote in the terminal in the first Orin, and afterwards we could only access the opening screen but not the operating system. The problems we get on this screen are as follows: ** WARNING: Test Key is used. ** L4TLauncher: Attempting Direct Bood OpenAndReadUntrustedFileToBuffer: Failed to open \boot\initrd: ExtLinuxBoot:sds Failed to Authenticate \boot\initrd (Not Found) L4TLauncher: Unable yo bootvia extlinux: Not Found L4TLauncher: Attempting Kernel Boot We get the same error in the second Orin, although we don’t understand why. What method can you suggest solving these problems?
Hi,
How did you confirm that it’s due to this?
Have you tried re-flashing?
Looks like the file system itself is corrupted.
Some added notes…
“Test key is used” is not a problem, nor a bug. Any partitions used during boot, aside from the rootfs/APP, are signed. Only signed partitions are allowed to be used. It just happens that when security fuses are not burned, a NULL key is used. A NULL signing of those partitions is still valid, it is just warning that you did not burn security fuses and set up something truly private.
GDM is the Gnome Display Manager. If you are using Gnome, then when Linux is running, and when Linux reaches the graphical display mode, GDM runs. It is the target of the X server, and its only job is to accept a login for the GUI, and if valid, overwrite itself with whatever desktop manager is chosen by that user. The rest of the system would still run without this, e.g., serial console would still work, so would ssh if you are using an IP address which doesn’t require GUI login (Wi-Fi tends to run its boot setup upon GUI login, wired does not have this requirement). You really need a serial console boot log to debug this.
Incidentally, these days we use systemctl to start and stop services. The service command is deprecated, but still exists for compatibility. What goes on behind the scene is that the compatibility version calls systemctl. Regardless, if you truly did only stop the service, then at the next boot it would come back. To cause some effect at the next boot you would also have to disable the service. Did you just stop the service? Or did you also disable the service? Considering that it is likely just a stopped service, and not a truly disabled service, I would have to agree that most likely you are seeing an effect of a corrupt filesystem and that this is not related to GDM. If you stopped GDM, and you did not properly shut down via command line, it is quite possible that an improper shutdown could cause such corruption. Normally I would think the journal would stop that degree of corruption, so I think something else is going on.
A serial console boot log (which runs during boot stages as well, and has no dependency on video or network drivers) is likely needed for any debugging. Even with this log it is probably going to end up needing flash if the filesystem is that corrupted. If you want to find out what happened, then there is no way around needing the serial console log; plus you would want to describe how the system was shut down after stopping GDM.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.