How to do factory reset for both Xavier modules on DRIVE AGX? Drive OS reinstall at least does not change the nvidia password

Please provide the following info (check/uncheck the boxes after creating this topic):
Software Version
[*] DRIVE OS Linux 5.2.6
DRIVE OS Linux 5.2.6 and DriveWorks 4.0
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other

Target Operating System
[*] Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
[*] NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.7.0.8846
other

Host Machine Version
[*] native Ubuntu 18.04
other

Let me clarify the question.
While learning the DRIVE AGX features I was playing with remote access and at some point was able to use XRDP to access Xavier A from my Window laptop. At some point I decided to start all over again and used SDK Manager to install Drive OS 5.2.6 using “Flash Xavier A+B” operation on SDK Manager.

However, after restart I still see the differences between Xavier A and B (they should identical SW after flashing, right?). More than that, the password for nvidia user which we select prior to flashing was not changed.

I repeated this scenario couple of times with the same result. Every time, I’m using poweroff/poweron command with 15 seconds interval from MvShell and can see that both board are going through the boot process.
Any help would be appreciated.

Dear @user28207,
Please confirm what was on Tegra A/B before flashing DRIVE OS 5.2.6. What difference you notice between Tegra A/B? Also, could you attach the latest flashing logs?

Dear @SivaRamaKrishnaNV,
It was a new system so I don’t know what exactly was installed there from the factory. I installed OS 5.2.6 and clearly remember initial dialog on both Tegra A/B modules when I logged in via ttyUSB2/6.
Then I added gdm3 and a remote desktop on Tegra A. The next step was to figure out how to configure the Tegra without the HDMI display connected to it and by playing with different packages and scenarios I decided to start all over.
So I used SDK Manager to flash the same OS 5.2.6 to both Tegras again and the operation was successful but the new password didn’t work and the old one did. I repeated this process couple of times to make sure I didn’t forget to power cycle the boards and no errors were reported.
I will share the logs after another flash operation.

Dear @SivaRamaKrishnaNV ,
Here are the logs:
SDKM_logs_DRIVE_OS_5.2.6_SDK_Linux_for_DRIVE_AGX_Developer_Kit_2021-11-11_06-39-56.zip (188.2 KB)

The password was not replaced.
Before the update I installed gdm3 on Tegra B and after the update it was gone which is expected.
However, I cannot install gdm3 on Tegra A:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gdm3 : Depends: libcanberra-gtk3-0 (>= 0.25) but it is not going to be installed
        Depends: libgtk-3-0 (>= 3.0.0) but it is not going to be installed
        Depends: gnome-session-bin (>= 3.10) but it is not going to be installed
        Depends: gnome-settings-daemon (>= 3.24) but it is not going to be installed
        Depends: gnome-shell (>= 3.19.92) but it is not going to be installed
        Depends: librsvg2-common but it is not going to be installed
        Depends: libglib2.0-bin (>= 2.35.0) but it is not going to be installed
        Recommends: zenity but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

But on Tegra B it is installing just fine and this is right after update.
I suspect something was left in persistent storage and this is why I’m wondering if there is a way to do a factory reset for a Tegra A or/and B.

Dear @SivaRamaKrishnaNV ,

Sorry to bother you, but do you need any extra info?

Thanks
Igor

Here is the conclusion: since the /etc folder is stored in a dedicated file system (/persistent) it will preserve everything on the next flash. If you want to have identical behavior between two Tegras then make sure the /persistent folders have the same content prior to flashing the AGX.

Perhaps NVIDIA has a hidden comment about it somewhere deep inside but it would be really nice to have a check mark on the SDK manager GUI which would also clean up /persistent file system.

Hi, @user28207
I also observed the issue that the target still used the password set in my first flashing.
I always set the same password so hadn’t encountered the issue before.
Thanks for raising the issue here.

May I know where is the persistent folder you were talking about? I would like to check the issue you found with our team.

Per DRIVE OS 5.2.6 Release Notes (PDF) and below from https://developer.nvidia.com/blog/nvidia-drive-os-5-2-6-linux-sdk-now-available/, it’s a new feature. Thanks for the suggestion.

image

May I know where is the persistent folder you were talking about? I would like to check the issue you found with our team

I was talking about the folder which holds all configuration files for almost any Linux distro: /etc which is stored in a different block device /dev/vblkdev2

nvidia@tegra-ubuntu:~$ mount |grep persistent
/dev/vblkdev2 on /persistent type ext4 (rw,relatime,data=ordered)
overlay on /etc type overlay (rw,relatime,lowerdir=/etc/,upperdir=/persistent/driveos/security/etc,workdir=/persistent/driveos/security/tmp/etc/)

This is the folder which stores the passwords too so I suspect if we delete the content of /persistent/driveos/security/etc and flash both A/B Xaviers then we’ll get the desired “factory reset” effect. But I wouldn’t recommend to rush into such drastic experiment without figuring out how are you going to restore everything if you won’t be able to flash the system after that ;)

… it’s a new feature:

Persistent storage of user login on the target (i.e., username/password, SSH keys)

Let me point out that this folder includes much more than listed things. For example, it stores the list of sources for “apt install” command, systemd services recipes, and other configuration files.

No doubts, it is very convenient feature in some cases (for example, when a tiny configuration file required for XRDP to work - /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf - was preserved over reinstallation).
But it might be a nightmare, and first of all to the AGX support team, to figure out why the the same version of system behaves differently for different customers. NVIDIA needs to add a factory reset option on the main GUI of the SDK manager ASAP.

Dear @user28207,
Could you check methods to reset persistent partition at https://docs.nvidia.com/drive/drive-os-5.2.6.0L/drive-os/index.html#page/DRIVE_OS_Linux_SDK_NGC_Development_Guide/Interfaces/sys_components.html#wwpID0E2HA. you should get the oem-config screens(https://docs.nvidia.com/drive/drive-os-5.2.6.0L/drive-os/index.html#page/DRIVE_OS_Linux_SDK_NGC_Development_Guide/config_setup.html#wwpID0E0SG0HA) on the console to accept EULA and set username/password as with a pre-flashed system.

Dear @SivaRamaKrishnaNV , thank you very much for the info. I’m wondering why this article didn’t pop up when I was searching for any info on “persistent”, “factory reset” but perhaps the starts were not at the right place :(
Sorry, I don’t have time to test these instructions.

How to force factory reset when flash DRIVE AGX.

Disclaimer: take the following steps at your own risk.

Persistent storage content is available under /persistent mount point. If you don’t see it using mount | grep persistent (which happened to me after apt-get upgrade) then mount it manually: mount /dev/vblkdev2 /persistent

Find folder /persistent/driveos/security/etc/nvidia/ and you will see the following files:

  • drive-templates-setup.done
  • driveos_fs_eula_accepted.stamp
  • persistence_init_done
  • primary_usersetup_completed.stamp
  • skip-oem-config.stamp

Remove all of them and the flashing script will treat the system as just out of box.

1 Like