Thanks for the log. We found a board-identification mismatch in our bootloader installation flow. We’ll investigate internally and post an update here when we have more information.
I ran into the same issue with my AGX Orin Developer board. If I go into the shell and edit the file in /target/etc/nv_boot_control.conf to change the 0005 values to 00000, then I can repeat the install command for nvidia-l4t-bootloader successfully. But then I’m still stuck in an interrupted install. Is there any way to resume the subiquity process that was running the install?
Please try the following workaround from your installed Jetson system.
If you can only access the shell after the ISO installation fails, please let us know before proceeding.
In /etc/nv_boot_control.conf, replace jetson-orin-nx-devkit-16gb with jetson-orin-nano-devkit in both TNSPEC and COMPATIBLE_SPEC. Keep all other values unchanged.
The error during install is “E: Internal Error, No file name for nvidia-l4t-bootloader:arm64”, if I run dpkg manually with the package I get a little more info:
Warning: Cannot get compatible board name.
3701–0005–1–p3737-0000-p3701-0005-
TNSPEC 3701-500-0005-R.0-1-0-p3737-0000-p3701-0005-
COMPATIBLE_SPEC 3701–0005–1–p3737-0000-p3701-0005-
TEGRA_BOOT_STORAGE mmcblk0
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701–0005–1–p3737-0000-p3701-0005-.
Info: The esp is already mounted to /boot/efi.
INFO. Dump slots info:
Current version: 39.2.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal
INFO. Dump nv_boot_control.conf:
TNSPEC 3701-500-0005-R.0-1-0-p3737-0000-p3701-0005-
COMPATIBLE_SPEC 3701–0005–1–p3737-0000-p3701-0005-
TEGRA_BOOT_STORAGE mmcblk0
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
ERROR. 3701–0005–1–p3737-0000-p3701-0005- does not match any known boards.
I was wondering: is there any way to force the board-spec string from the bootloader of the installer? Any variable to set that overrides the detection? Then we might be able to work around this issue until a fix is released.
I checked the installer scripts in the r39.2.1 ISO you are using. There is no built-in GRUB/kernel command-line parameter to override the board-spec string.
The steps below are a possible workaround from an existing bootable Jetson system; they do not resume the interrupted Subiquity installation.
The documented configuration name for your AGX Orin is jetson-agx-orin-devkit. Replacing the rejected board name with this may address the matching error, but this workaround has not yet been verified on your setup.
Please try the following only if you can boot your installed Jetson system. If you can only access the failed ISO installer’s shell, please let us know before proceeding.
Back up the configuration:
sudo cp -a /etc/nv_boot_control.conf /etc/nv_boot_control.conf.before-board-name-change
In /etc/nv_boot_control.conf, replace only p3737-0000-p3701-0005 with jetson-agx-orin-devkit in both TNSPEC and COMPATIBLE_SPEC. Preserve all other fields, including the original SKU 0005; do not change it to 00000.
Sadly I don’t have a bootable Jetson system anymore. This whole journey upgrading JetPack has made me reflash the board a few times.
I figured out that I can basically restart the subiquity process by running subiquity-shell. What I’ve done: at the point where the installation fails, I’ve entered the shell and edited /target/etc/nv_boot_control.conf to use the value jetson-agx-orin-devkit you provided and then run subiquity-shell.
The subiquity process seems to be re-evaluating all installation steps, because it runs very fast and ends up at the exact same error: error while installing nvidia-l4t-bootloader. I have again entered the shell to verify the configuration was not changed by subiquity and the corrected board name is still in the config files.
Yesterday I changed the 0005 strings to 0000 and ran subiquity-shell, it then seemed to be proceeding with installation until the very last step and then it failed with an error where I could not find any additional information. If it helps, I could do that again and share more logging there?
ERROR. 3701--0005----jetson-agx-orin- does not match any known boards.
It picks up the changes, but this feels like an invalid string interpolation.
Update: my bad. I forgot the devkit postfix on the COMPATIBLE_SPEC. Added it and reran subiquity again. Now it runs all the way to the step where it writes:
logger -p info "[..........] 100% Step 13/13 Finished Installation"
But then it ends with this output:
preseed: blocking geoip.ubuntu.com (geoip=false)
+ echo '127.0.0.1 geoip.ubuntu.com'
+ false
+ false
+ false
+ cp -f /ai/jetsoniso_orin-ai.yaml /autoinstall.yaml
++ type -t oem_early_commands
+ '[' '' == function ']'
+ exit 0
An error occurred. Press enter to start a shell
Thanks for the update. Could you share the full crash report from the attempt that reached Step 13 after you corrected the board name to jetson-agx-orin-devkit? The final output alone does not show the cause of the failure.
In the installer’s shell, outside any /target chroot, run:
ls -lt /var/crash/*.install_fail.crash
Please upload the report corresponding to that latest failed attempt. If no report is found, please let us know.
Thanks for the screenshots. The earlier workaround requires a Jetson system that can boot into Linux. Using chroot /target edits the installation target, but does not confirm that the system is bootable or that the EFI board-spec has been updated.
Please first check whether you can boot from your NVMe SSD:
Restart the device and press Esc when the NVIDIA logo appears.
Open Boot Manager.
If an entry corresponding to your NVMe SSD is listed, select it and let us know whether Linux starts.
If no NVMe boot entry is listed, or selecting it returns to the UEFI Shell, please share a photo of the Boot Manager screen. Also, do you have an Ubuntu host PC available for reflashing, and is there any data on the NVMe SSD that needs to be preserved? Reflashing can overwrite existing data.
Please select UEFI WD Blue SN5100 500GB … in Boot Manager, below the Ubuntu entry, and let us know whether Linux starts. If it does not, please share a photo of the screen you reach.
@wichiu when I click in UEFI WD Blue SN5100 500GB, it just come back to the same boot manager screen after a blank screen for a few seconds. Same behaviour for Ubuntu also
