jetson-agx-orin-devkit-crashlog.tar.gz (485.4 KB)
Here’s the crashlog you asked for.
Yesterday I managed to get the system to boot after using Grub to initialize the bootloader. But the installer had probably not run it’s final tasks, because I could not login with any sensible default credentials and no first-run stuff popped up either. So I’ve got a booting Ubuntu, but I can’t get into it 😅. (That’s fixable, but I’m probably missing other post-install stuff too)
Hi @kramor,
Thanks for the log. It shows the Step 9 failure with the old board name p3737-0000-p3701-0005, rather than the later failure you described.
Do you still have the crash report or installer logs from the attempt that reached Step 13 after changing the name to jetson-agx-orin-devkit? Please share those so we can check why installation did not complete.
Thanks.
It seems the crash-logs are not updated when I run subiquity-shell after the fix. I have the /var/logs/subiquity-* files for you here:
subiquity_logs.tar.gz (36.4 KB)
Hi,
I will check both your issue with our internal team.
However, the department responsible for this issue is currently on a national holiday, so it may take some time before an update is available.
Sorry for the inconvenience.
I’m working on a customized iso to try and fix the board resolution. It’s quite a bit of trial and error to get it to work, but if I get it to work, I should be able to tell if the rest of the installer works. Probably going to be busy with this over the weekend.
@wichiu Any update from the team?
@venkatgig They are OOO until today. And will be back tomorrow.
Thanks for the update. Really appreciate it.
Hi @venkatgig,
Could you please try reinstalling the bootloader package after confirming the board-name correction? This may address the original board-spec rejection, although successful reinstallation alone does not confirm that the system is ready to boot.
Since you have rebooted, please first check the current ISO environment rather than assuming the previous target-system mounts are still available.
Check the current installer environment. Boot from the ISO USB and open the installer shell, outside any chroot. Do not start a new installation for this check. Run:
findmnt -R /target
sudo cat /target/etc/nv_boot_control.conf
Proceed only if /target is your installed system and its /dev, /proc, /sys (including EFI variables), and EFI partition are correctly mounted. A reboot does not preserve the previous mounts. If anything is missing or you are unsure, please share the output and stop here.
Enter the target system:
sudo chroot /target /bin/bash
Check /etc/nv_boot_control.conf inside the chroot. Back up the file before editing. Ensure both TNSPEC and COMPATIBLE_SPEC use jetson-orin-nano-devkit instead of jetson-orin-nx-devkit-16gb. Change only the board-name field; preserve all other fields and hyphens, including the trailing hyphen. If both names are already correct, leave them unchanged.
Reinstall the bootloader package inside that chroot:
unset SNAP
apt-get reinstall nvidia-l4t-bootloader
Please share the full reinstallation output and the resulting TNSPEC and COMPATIBLE_SPEC lines before rebooting.
Thanks.
Hi @kramor,
Could you please try the board-name correction plus bootloader reinstallation below? This may address the original board-spec rejection, but it does not automatically complete the remaining installation or resolve the login issue.
If you already successfully reinstalled nvidia-l4t-bootloader with both specs using jetson-agx-orin-devkit and the original SKU 0005, please share that result instead of repeating the procedure.
Check the current installer environment. Boot from the ISO USB and open the installer shell, outside any chroot. Do not start a new installation for this check. Run:
findmnt -R /target
sudo cat /target/etc/nv_boot_control.conf
Proceed only if /target is your installed system and its /dev, /proc, /sys (including EFI variables), and EFI partition are correctly mounted. A reboot does not preserve the previous mounts. If anything is missing or you are unsure, please share the output and stop here.
Enter the target system:
sudo chroot /target /bin/bash
Check /etc/nv_boot_control.conf inside the chroot. Back up the file before editing. Ensure both TNSPEC and COMPATIBLE_SPEC use jetson-agx-orin-devkit for the board-name field. Preserve all other fields and hyphens, including the original SKU 0005.
Reinstall the bootloader package inside that chroot:
unset SNAP
apt-get reinstall nvidia-l4t-bootloader
Please share the full reinstallation output and the resulting TNSPEC and COMPATIBLE_SPEC lines before rebooting.
Thanks.
You have reached the ISO rescue shell. The empty findmnt output indicates that the target system is not mounted at /target yet.
Please run the following command in the same shell and share the output so we can identify the NVMe partitions:
lsblk -o NAME,SIZE,FSTYPE,LABEL,PARTLABEL,MOUNTPOINTS
Please hold off on the chroot and bootloader reinstallation steps for now.
Thanks.
Thanks. Your screenshot shows the APP partition at /dev/nvme0n1p1. Please run these commands one at a time in the same rescue shell and share the output:
sudo mkdir -p /target
sudo mount -o ro,noload /dev/nvme0n1p1 /target
sudo cat /target/etc/nv_boot_control.conf
If any command fails, stop and share the error. Please do not proceed with chroot or bootloader reinstallation yet.
Thanks. Both board names in the configuration file are correct. Please run these commands in the same rescue shell and share the output so we can check the board names stored in UEFI:
sudo xxd /sys/firmware/efi/efivars/TegraPlatformSpec-781e084c-a330-417c-b678-38e696380cb9
sudo xxd /sys/firmware/efi/efivars/TegraPlatformCompatSpec-781e084c-a330-417c-b678-38e696380cb9
No further changes to the configuration file are needed for now.
Thanks.
Thanks for the output. The incorrect board name is still stored in UEFI, even though the configuration file is correct.
Our engineering team has provided two recovery options:
uefi_variables, uefi_ftw, and reserved_partition partitions. This allows TegraPlatformSpec to be reconstructed on the next successful boot or during ISO installation. Device-specific instructions are needed before proceeding with this option.Both options require an Ubuntu host PC. We understand that you do not currently have one, so you would need access to one or assistance from someone who can perform the recovery. We do not currently have a confirmed ISO-only recovery procedure for this case.
Thanks.
I’m sorry we don’t currently have a recovery solution that works with your available setup.
Thanks for the quick response. I really appreciate the quality of support you guys are proviging.
As it is the bug which is affecting all the NVIDIA jetson nano 8GB board, are you guys trying to fix it soon? If yes, any timelines?
At least you guys should not have removed the option to flash the microSD and boot it. And if you guys have mentioned that ubuntu is necesary in the website, I would not have bought the board
TBH, i am kind of disappointed that i bought nvidia board. I used to be Raspberry pi user (have couple of it), only this time I made a wrong decision to buy NVIDIA board . I have never need to spend so much time to get it up and running.
Sorry for the inconvenience.
But I want to confirm one thing: Do you use the DevKit or the custom board?