L4t_initrd_flash.sh and l4t_backup_restore.sh generate identical /etc/machine-id on cloned Jetson devices

Robotics & Edge Computing Jetson Systems Jetson Orin NX
1

Hi,

I am deploying multiple Jetson Orin NX devices and noticed that both flashing and backup/restore workflows result in identical /etc/machine-id values across all devices.

Environment

JetPack 6.2 / L4T R36.4.3

Reference documentation:

Jetson Linux download:

Flash workflow

I use l4t_initrd_flash.sh with NVMe rootfs:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_t234_nvme.xml \
  -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0 \
  jetson-orin-nano-devkit internal

Backup/restore workflow

I also tested backup and restore using:

sudo ./tools/backup_restore/l4t_backup_restore.sh \
  -e nvme0n1 \
  -b jetson-orin-nano-devkit

Restore:

sudo ./tools/backup_restore/l4t_backup_restore.sh \
  -e nvme0n1 \
  -r jetson-orin-nano-devkit

After restoring the image onto multiple devices, all boards still share the same:

  • /etc/machine-id
  • /var/lib/dbus/machine-id

Observation

On the host side:

cat ~/Linux_for_Tegra/rootfs/etc/machine-id
cat ~/Linux_for_Tegra/rootfs/var/lib/dbus/machine-id

Content:

5dbfb12414a3456d9014d88183e338b1

It appears that both flashing and backup/restore workflows copy the entire rootfs directly, including:

/etc/machine-id
/var/lib/dbus/machine-id

As a result, all deployed devices end up with the same machine identity.

Questions

  1. Is this expected behavior in JetPack 6.2?
  2. Does NVIDIA officially recommend removing /etc/machine-id before flashing or backup?
  3. Is there an official first-boot initialization mechanism for regenerating unique IDs?
  4. Should oem-config or cloud-init regenerate machine-id automatically?
  5. What is the recommended mass-production workflow for Jetson devices?

Current workaround

Currently I manually regenerate machine-id on first boot:

sudo rm -f /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo systemd-machine-id-setup

Would appreciate any official guidance or recommended production workflow.

Thanks!

2

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing with identical /etc/machine-id values across all deployed Jetson Orin NX devices is due to the way the flashing and backup-restore workflows handle the root file system. Both workflows copy the entire root file system, including the /etc/machine-id file, which contains a unique identifier for the device.

This behavior is expected in JetPack 4.6.2, as the documentation does not explicitly mention regenerating the /etc/machine-id file during the flashing or backup-restore process.

NVIDIA does not officially recommend removing /etc/machine-id before flashing or backup. However, it is a common practice to regenerate the /etc/machine-id file during the first boot to ensure uniqueness across devices.

There is no official first-boot initialization mechanism for regenerating unique IDs. However, you can use the oem-config or cloud-init tools to automate the process of regenerating the /etc/machine-id file during the first boot.

oem-config is a tool provided by NVIDIA that allows you to customize the first-boot experience for your devices. You can use oem-config to run a script that regenerates the /etc/machine-id file during the first boot.

cloud-init is a tool that allows you to automate the initialization of your devices during the first boot. You can use cloud-init to run a script that regenerates the /etc/machine-id file during the first boot.

The recommended mass-production workflow for Jetson devices involves using the l4t-initrd-flash.sh script to flash the devices, followed by a script that regenerates the /etc/machine-id file during the first boot. You can use oem-config or cloud-init to automate this process.

Here is an example of how you can use oem-config to regenerate the /etc/machine-id file during the first boot:

  1. Create a script that regenerates the /etc/machine-id file:
#!/bin/bash

# Regenerate the /etc/machine-id file
rm /etc/machine-id
dbus-uuidgen > /etc/machine-id
  1. Save the script to a file, for example, regenerate_machine_id.sh.
  2. Add the script to the oem-config configuration file:
sudo oem-config configure
  1. Select the “Run a script during first boot” option and enter the path to the regenerate_machine_id.sh script.
  2. Save the changes and exit the oem-config configuration tool.

Alternatively, you can use cloud-init to regenerate the /etc/machine-id file during the first boot. Here is an example of how you can do this:

  1. Create a cloud-init configuration file:
#cloud-config
bootcmd:
  - rm /etc/machine-id
  - dbus-uuidgen > /etc/machine-id
  1. Save the configuration file to a file, for example, cloud-init.yaml.
  2. Add the cloud-init configuration file to the l4t-initrd-flash.sh script:
sudo l4t-initrd-flash.sh -c cloud-init.yaml
  1. Flash the device using the l4t-initrd-flash.sh script.

In both cases, the /etc/machine-id file will be regenerated during the first boot, ensuring that each device has a unique identifier.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Hi,

  • Is this expected behavior in JetPack 6.2?

Yes, this is expected behavior when using the backup and restore process.

  • Does NVIDIA officially recommend removing /etc/machine-id before flashing or backup?

Yes, it is recommended to remove this file before flashing or creating a backup.

  • Is there an official first-boot initialization mechanism for regenerating unique IDs?

Yes, the system will automatically generate new IDs during the first boot.

  • Should oem-config or cloud-init regenerate machine-id automatically?

No.

  • What is the recommended mass-production workflow for Jetson devices?

As mentioned above, it is recommended to remove such files before flashing or creating backups for mass production.

Thanks