Why might a Recovery Boot get forced?

[pastap]

Hello, I am facing within the bootloader the issue that it is attempting a Recovery Boot instead of direct or GRUB boot.

I haven’t picked it in the UEFI and changing settings there under:
Device Manager>NVIDIA Resource Configuration>L4T Boot Mode
does not affect it.

I am using a JNX30D from AUVIDEA as carrier board and a NVMe SSD as install location (Jetpack 5.0.2).

My Serial dump:

**  WARNING: Test Key is used.  **
  Error: Could not detect network connection.
  Error: Could not detect network connection.
L4TLauncher: Attempting Recovery Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...

Same is displayed on the boot screen.

If there is anything happening afterwards (and in case it should boot up L4T/Ubuntu), I cannot tell as I have disabled nvgetty.

However, on the screen there is only a cursor blinking in the top left corner like there was no boot device found.

In the UEFI menu I can still find the SSD.

What might be the reason(s) for it to be triggered or where do I find documentation about this boot mode?

[JerryChang]

hello pastap,

are you going to flash to an external storage device?
please also change the Boot Order Selection.

[pastap]

Hello @JerryChang ,

I have not planned to flash.

Sorry, I should have mentioned explicitly, that I had a running system before.
So it booted successfully to Ubuntu on the SSD.

What I noticed changing was, instead of

L4TLauncher: Attempting GRUB Boot
L4TLauncher: Attempting Direct Boot

suddenly

L4TLauncher: Attempting Recovery Boot

was shown/printed to serial console.
And afterwards it was not booting successfully.

However, I now changed the boot order to put the SSD on top, what removed the network connection errors, but kept the rest as described before.

**  WARNING: Test Key is used.  **
L4TLauncher: Attempting Recovery Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...

[JerryChang]

@pastap

that I had a running system before.

hello pastap,

may I also know what’s the system it is?

[pastap]

Hello @JerryChang,

It is a Jetson Xavier NX module on a JNX30D carrier board from AUVIDEA running Jetpack 5.0.2 / L4T 35.1 / Ubuntu 20.04 (installed with the Nvidia SDK Manager)

[JerryChang]

hello pastap,

do you have specific flash configuration file?
default Nvidia SDK Manager to flash Xavier NX it’ll flash JetPack release image to internal eMMC (jetson-xavier-nx-devkit-emmc.conf) or SD (jetson-xavier-nx-devkit.conf).

[pastap]

Hello @JerryChang,

I could not find .conf files in the files I got from AUVIDEA to modify/add for installation.

As flashing is already a while ago, I checked the SDK Manager again to be sure.
One can pick NVMe beside the default EMMC/SDcard, like in my screenshot below
That is what I did instead of using a configuration file.

[JerryChang]

hello pastap,

please confirm the flash process has completed, but boot hang at UEFI?
please setup serial console to gather bootloader logs for reference, thanks

[pastap]

Hello @JerryChang,

I am afraid there is a misunderstanding.
I was hoping that I do not have to flash and can recover my previous installation.

So it was flashing, booting and running already for more than a month successfully until the boot mode changed as described above.

The previous logs are from the serial console/bootloader output.

Afterwards there is no more output (I have disabled nvgetty) and on screen I can only see a blinking cursor in the top left corner.

[JerryChang]

hello pastap,

it’s hard to distinguish the issue without failure messages.
so… what exactly the content of this SSD.

[pastap]

Hello @JerryChang,

Sorry, I found my mistake.

I was not using the debug UART. I used instead the UART on the GPIO header.
That is the reason for the little and not detailed “logs”.

The debug serial on this board is only accessible via a connector, I currently do not have, but I will provide the bootloader logs when I got it.