NVIDIA Tegra
NVIDIA Jetson Linux Driver Package Software Features
Release 32.3 | December 10, 2019

 
Flashing and Booting the Target Device
 
Before You Begin
Basic Flash Script Usage
Basic Flashing Procedures
Flash Script Usage
Flashing to a Flash Drive
Flashing to an SD Card
Flashing a Specific Partition
Flashing to Multiple Jetson Devices
Increasing Internal Memory Partition for Root File System
Determining the Success of a Driver Update
Reconfiguring a Jetson Device with oem-config
Use the flash.sh helper script to flash the board with the bootloader and kernel, and optionally, flash the root file system to internal eMMC.
Before You Begin
The following directories must be present:
bootloader: Bootloader plus flashing tools, such as NvFlash, CFG, BCT, etc.
kernel: A kernel Image /vmlinux.uimg, DTB files, and kernel modules
rootfs: The root file system that you download
This directory starts empty. You populate it with the sample file system.
nv_tegra: User space binaries and sample applications
Additionally, before running these commands, you must have the USB cable connected to the recovery port.
Basic Flash Script Usage
Locate the most up-to-date usage information by running flash.sh –h (using the flash.sh script included in the release). The basic usage is as follows.
sudo ./flash.sh [options] <target> <rootdev>
Where:
switches is one or more command line switches. All switches are optional. Switches are described in Flash Script Usage.
<target> specifies the type of target device to be flashed:
For Jetson Nano: jetson-nano
For Jetson AGX Xavier: jetson-xavier
For Jetson TX2: jetson-tx2
For Jetson TX1: jetson-tx1
<rootdev> specifies the type of device that is to be flashed:
For Jetson Nano development module QSPI RAM: mmcblk0p1
For Jetson Nano development module SD card: mmcblk0p1
For Jetson Nano development module eMMC RAM: mmcblk0p1
For Jetson AGX Xavier: mmcblk0p1
For Jetson TX2: mmcblk0p1
For Jetson TX1: mmcblk0p1
Basic Flashing Procedures
This section describes some common procedures for flashing one or more target devices.
To flash using USB
Use the USB device mode default configuration script and associated README that describes how the USB flashing port operates in device mode.
For details, see Quick Install Guide.
To flash the target device
1. Put the target device into reset/recovery mode.
1. Power on the carrier board and hold the RECOVERY button.
2. Press the RESET button.
2. Run the flash.sh script that is in the top-level directory of this release. The script must be supplied with the target board (e.g. jetson-xavier) for the root file system:
sudo ./flash.sh <target> <rootdev>
Where:
<target> specifies the target device’s type, as specified in Basic Flash Script Usage.
<rootdev> depends on where the root file system is located:
For a root file system, execute the script like this:
sudo ./flash.sh <target> mmcblk0p1
To flash the target device to mount a rootfs specified by UUID
Enter this command:
sudo ./flash.sh <target> internal
 
This command stores the UUID used for the root file-system partition in the file bootloader/l4t-rootfs-uuid.txt. You may specify your own UUID by writing the UUID to this file before executing the command above.
To clone a Jetson device and flash
1. Copy system.img from the filesystem partition you want to flash from. Enter this command:
sudo ./flash.sh -r -k APP -G <clone> <target> mmcblk0p1
Where:
<clone> determines the names of the copies.
<target> specifies the type of the target device:
This step creates two copies of <clone> in the <top> directory: a sparsed image (smaller than the original) named <clone>, and an exact copy named <clone>.raw.
For example, if <clone> is original.img, flash.sh creates a sparsed image named original.img and an exact copy named original.img.raw.
3. Copy <clone>.img to the <L4T>/bootloader/system.img directory. Enter this command:
sudo cp <clone>.img bootloader/system.img
4. Flash the image to the target board.
If the target board has already been flashed, reflash the clone image to the APP partition. Enter this command:
sudo ./flash.sh -r -k APP <target> mmcblk0p1
If the target board has never been flashed, flash all of the board’s partitions. Enter this command:
sudo ./flash.sh -r <target> mmcblk0p1
To RAM boot to NFS (Jetson AGX Xavier only)
1. Put the device into reset/recovery mode.
Power on the carrier board and hold the RECOVERY button.
Then press the RESET button.
5. Execute the command:
sudo ./flash.sh -N <ip-addr-of-linux-host>:/<path-to-NFS-rootfs> --rcm-boot <target> eth0
Where:
<ip_addr> is the IP address of the host system
<root_path> is the path to the NFS rootfs
<target> is the type of the target device as specified in the section To flash Jetson developer kit operating software in the topic Quick Start Guide
Flash Script Usage
This section complements Basic Flash Script Usage by providing detailed information about flash.sh command line switches and other aspects of flash.sh usage.
Command line switch
Description
-b <bctfile>
Pathname of a boot control table configuration file.
-c <cfgfile>
Pathname of a flash partition table configuration file.
-d <dtbfile>
Pathname of a device tree file.
-e <emmc size>
Target device's eMMC memory size. Applies only to target devices that use eMMC.
-f <flashapp>
Name of the flash application to be used. Flash applications are stored in the bootloader directory. The default flash application is bootloader/tegraflash.py.
-h
Prints descriptions of the command line syntax and command line switches.
-k <partition_id>
Partition name or number specified in flash.xml or flash.cfg.
-m <mts_preboot>
Name of the MTS preboot file to be used, such as mts_preboot.
-n <nfs_args>
Static NFS network assignments: <Client_IP>:<Server_IP>:<Gateway_IP>:<Netmask>.
-o <odmdata>
ODM data.
-p <bp_size>
Total eMMC hardware boot partition size.
-r
Skips building system.img; reuse the existing one.
-s <PKC_ key_ file>
Pathname of a file containing the PKC key used for signing and building bl_update_payload. (Obsolete)
-t <tegraboot>
Pathname of a tegraboot binary such as nvtboot.bin.
-u <PKC_key_file>
Pathname of a file containing the PKC key used for an ODM fused board.
-v <SBK_key_file>
Pathname of a file containing the Secure Boot Key (SBK) used for an ODM fused board.
-w <wb0boot>
Pathname of a warm boot binary such as nvtbootwb0.bin.
-x <tegraid>
Processor chip ID. The default value is:
Jetson Nano and Jetson TX1: 0x21
Jetson Xavier: 0x19
Jetson TX2: 0x18
-y <fusetype>
PKC if secureboot is used, or NS otherwise.
-z <sn>
Serial number of the target board.
-B <boardid>
Board ID.
-C <args>
Kernel command line arguments. If this switch is specified, it overrides the default values defined for flash.sh. If two or more arguments are specified, they must be enclosed in quotation marks and separated by spaces.
In the case of NFS booting, use this switch to set NFS booting related arguments if the -I option is omitted.
-F <flasher>
Pathname of a flash server such as cboot.bin.
-G <file_name>
Reads the boot partition and saves the image to the specified file.
-I <initrd>
Pathname of the initrd file. The default value is null.
-K <kernel>
Pathname of a kernel image file such as zImage or Image.
-L <bootloader>
Pathname of a Bootloader such as cboot.bin or u-boot-dtb.bin.
-M <mts boot>
Pathname of an MTS boot file such as mts_si.
-N <nfsroot>
NFS root address, such as <my_IP_address>:/my/exported/nfs/rootfs.
-P <ppt_end_plus1>
Deprecated. End of the PPT plus 1; primary GPT start address + size of PPT + 1.
-R <rootfs_dir>
Pathname of the sample rootfs directory.
-S <size>
Size of the rootfs in bytes. Valid only for an internal rootdev. KB/MB/GB suffixes represent units of 1000, 10002, and 10003. KiB/MiB/GiB suffixes represents of 1024, 10242, and 10243. For example, 2GiB represents 2×1024×1024×1024 bytes.
--bup
Generates Bootloader update payload (BUP).
--clean-up
Cleans up the BUP buffer when ‑‑multi-spec is enabled.
--multi-spec
Enables support for building a multi-spec BUP.
--no-flash
Performs all steps except physically flashing the board. The script creates a system.img file.
--no-systemimg
Prevents creation or re-creation of system.img.
--usb-instance <id>
USB instance to connect to; <id> is an integer ID (e.g. 0, 1), a bus/dev (e.g. 003/091), or a USB port path (e.g. 3-14). The last is the recommended form.
Flashing to a Flash Drive
The Jetson AGX Xavier can be booted from a USB device with mass storage class and bulk only protocol, such as a flash drive. Hot plugging is not supported; the flash drive must be attached before the device is booted.
This procedure uses CBoot, and flashes only the kernel and kernel DTB to the USB device. The kernel uses the file system in the target device’s internal eMMC. The target device must be flashed at least once before the procedure is performed to ensure that the file system is available.
To set up a flash drive for booting
1. Connect the USB stick to host computer.
6. Check the USB device’s device name (e.g. /dev/sdb, /dev/sdd, or /dev/sdc):
sudo lshw -quiet -short -c disk
7. Create a new GPT.
sudo parted /dev/sdb mklabel gpt
If the device name is /dev/sdb. The device name fetches it at runtime.
8. Add the kernel partition and allocate 64 MB to it:
sudo parted /dev/sdb mkpart kernel 0MB 64MB
9. Add the kernel-dtb partition and allocate 1 MB to it:
sudo parted /dev/sdb mkpart kernel-dtb 64MB 65MB
10. Print the start, end, and size in sectors of the partitions:
sudo parted /dev/sdb unit s print
11. Write the kernel image to the kernel partition:
sudo dd if=bootloader/boot.img of=<dn>1
12. Write the kernel-dtb image to the kernel-dtb partition:
sudo dd if=bootloader/<dtbname> of=<dn>2
In this procedure:
<dn> is the device name of the USB device, e.g. /dev/sdb.
<dtbname> is the filename of the .dtb file. For the Jetson AGX Xavier it is:
tegra194-p2888-0001-p2822-0000.dtb
To prepare files to boot from a flash drive with Secureboot implemented
With Secureboot implemented, both boot.img and tegra194-p2888-0001-p2822-0000.dtb must be signed and encrypted if they are to be used on a system that is booted from a flash drive (USB or SD Card) or from TFTPboot.
Enter these commands to generate signed, encrypted files:
For boot.img:
sudo ./flash.sh --no-flash -k kernel jetson-xavier mmcblk0p1
For the .dtb file:
sudo ./flash.sh --no-flash -k kernel-dtb jetson-xavier mmcblk0p1
Flashing to an SD Card
Applies to: Jetson Nano development module (P3448) only
This section describes procedures for flashing and utilizing an SD card for a Jetson Nano development module (P3448). This module is used only as a component of Jetson Nano Developer Kit.
Prerequisites
Download Etcher for Linux. Etcher is the tool you will use to copy an image to an SD card. It is available at:
https://www.balena.io/etcher/
Download Etcher for Linux x64 (64-bit) (AppImage). Make the downloaded file executable.
Note
NVIDIA recommends using Etcher to copy an image to an SD card because it is an easy and foolproof method. If you prefer, you can also perform this operation with the Linux dd command. If you use this method, you need not download Etcher.
To generate an image to be flashed to an SD card
1. If you have not already done so, expand the archive linux_for_tegra.tbz2.
13. Go to the directory Linux_for_Tegra.
14. Enter this command:
./jetson-image-disk-creator.sh -o <blob_name> -s <blob_size> -b <board> -r <revision>
Where:
<blob_name> is a filename; the script saves the raw image with this name.
<blob_size> specifies the size of the blob. It is a number suffixed with an optional unit code, for example, 3120M. The unit code may be:
G for GiB
M for MiB
K for KiB
B bytes (the default if no unit is specified)
<board> specifies the type of Jetson device the SD card is to be flashed for. Because an SD card currently may be used only to boot Jetson Nano, the value of <board> must be jetson-nano.
<revision> is the revision number of the Jetson Nano module to be used:
100 for revision A01
200 for revision A02
300 for revision B00 lr B01
This command generates a raw image with partitions per Min-SPI profile.
For example, to create a 5 GiB raw image file named sd-blob.img for use on a Jetson Nano development module revision A01:
./jetson-image-disk-creator.sh -o sd-blob.img -s 5G -r 100
The jetson-image-disk-creator.sh script supports use of a modified rootfs. Thus you can create an SD card image with a specified rootfs directory:
ROOTFS_DIR=<MODIFIED_ROOTFS_PATH> ./jetson-disk-image-creator.sh -o <blob_name> -s <blob_size> -b <board> -r <revision>
To flash the image to an SD card with Etcher
1. Insert the SD card into an SD card slot on your host system. If your system does not have an SD card slot, you may use an external SD card reader.
2. Launch Etcher and select the SD blob image file created by the jetson-image-disk-creator.sh script.
3. Select the SD card to be flashed.
4. Click Flash to write the SD blob image to the SD card.
To flash the image to an SD card with dd
Enter the command:
sudo dd if=<sd_blob_name> of=/dev/mmcblk<n> bs=1M oflag=direct
Where:
<sd_blocb_name> is the name (with pathname, if necessary) of the blob image file created by the jetson-image-disk-creator.sh script.
<n> is the SD card block number detected by your Linux host. e.g. 0 or 1.
For example, to copy an image blob file named sd-blob.img from the working directory to SD card block number 1:
sudo dd if=sd-blob.img of=/dev/mmcblk1 bs=1M oflag=direct
To resize the root partition to fill available SD card space
The root partition is always created at the end of the boot device. This allows you to change its size without having to move other partitions.
You change the size of the boot partition with the resize2fs tool, which is run by oem-config the first time a newly copied image blob file is booted from an SD card.
When a freshly initialized SD card is first booted it runs oem-config, one of whose functions is to set the APP partition’s size. It does the following things:
1. Moves the backup GPT header to the end of the disk
15. Deletes and re-creates the root partition
16. Informs the kernel and OS of the change in the partition table and root partition size
17. Resizes the filesystem on the root partition the expected partition table and root partition size
Flashing a Specific Partition
You can flash a specific partition instead of flashing the whole device by using the comand line switch ‑k.
To flash a specific partition
Enter the command:
sudo ./flash.sh -k <partition_name> [--image <image_name>] <target> <rootdev>
Where:
<partition_name> is the name of the partition to be flashed. Possible values depend on the target device. For details, see the section Default Partition Overview in the topic Bootloader.
<image_name> is the name of the image file. If omitted, flash.sh chooses the image file that was used to flash whole device.
<target> is the type of target device as specified in the section To flash Jetson developer kit operating software in the topic Quick Start Guide.
<rootdev> is the device name of the root file system, for example emmcblk0p1.
Examples
To flash the kernel on Jetson AGX Xavier using the default file <L4T>/kernel/Image:
sudo ./flash.sh -k kernel jetson-xavier mmcblk0p1
To flash mb1 bct on Jetson AGX Xavier using a predefined list of configuration files:
sudo ./flash.sh -k MB1_BCT jetson-xavier mmcblk0p1
To flash CPU bootloader on Jetson TX2 by using a user-specified image file <user_path>/cboot.bin:
sudo ./flash.sh -k cpu-bootloader –-image <user_path>/cboot.bin jetson-tx2 mmcblk0p1
Notes on the “-k kernel” option
Since U‑Boot is required for Jetson Nano and Jetson TX1, and is the default bootloader for Jetson TX2, the image flashed to the kernel partition is actually a U‑Boot image. U‑Boot loads the Linux kernel from /boot/Image in the root file system.
For this reason you cannot update Linux kernel image using the ‑k kernel switch. You may update /boot/Image by either of these means:
Modify /boot/extlinux/extlinux.conf to add a new boot entry.
Follow the instructions and example provided in /boot/extlinux/extlinux.conf. By this means you can always use cp or scp to replace /boot/Image with a custom-built kernel and launch it with U‑Boot.
On T210 (Nano and TX1) devices only, connect the Jetson device’s recovery USB port to your host. Enter this command at the U‑Boot command prompt:
ums 0 mmc 1
This connects eMMC (or the Jetson Nano SD Card) to the host as a set of USB mass storage devices (each partition as a device). You then can copy your custom kernel to /boot/Image directly.
Flashing to Multiple Jetson Devices
NVIDIA provides a tool and instructions for flashing Jetson devices efficiently in a factory environment. This tool is part of the Linux BSP package and is available in the Linux_for_Tegra folder. Instructions for using the tool are included in README_Massflash.txt, located in the same folder.
Increasing Internal Memory Partition for Root File System
The suggested rootfs partition size for Jetson AGX Xavier is 15 gigabytes (GB). It is specified by default in the <target_board>.conf file used by the flash.sh script.
Use the -S <size-in-bytes> argument to flash.sh to change the partition size.
To flash for a larger partition
Execute the following command:
$ sudo ./flash.sh -S <size> <target> <rootdev>
Where:
<size> is the desired size for the partition, such as 8589934592 (or 8 GiB) for 8 GB, if you want to decrease the size of the partition.
<target> is the type of the target device as specified in the section To flash Jetson developer kit operating software in the topic Quick Start Guide
<rootdev> is the rootfs partition internal memory, for example mmcblk0p1.
Determining the Success of a Driver Update
After updating drivers on a target board, verify that the update completed successfully. You can determine the success or failure of a driver update by using the following commands.
To determine the success of a driver update
Execute the following command on a booted target device:
$ sha1sum –c /etc/nv_tegra_release
If the driver update succeeded, the output displays the word OK after the file name. A typical success message looks like this:
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
The driver update fails if the file is missing. A typical error message looks like this:
sha1sum: /usr/lib/xorg/modules/drivers/nvidia_drv.so: No such file or directory
/usr/lib/xorg/modules/drivers/nvidia_drv.so: FAILED open or read
The driver update also fails if the new file is different from the existing file, producing an error such as:
/usr/lib/xorg/modules/drivers/nvidia_drv.so: FAILED
Reconfiguring a Jetson Device with oem-config
 
About Communication Through the Debugging Port
Headless Mode Flow in oem-config
A target device that is flashed by SDK Manager runs the oem-config tool automatically the first time it boots after it is flashed. You can use this tool to change some parts of the device’s configuration.
The oem-config tool is useful for custom configuring production devices. In a typical use case you flash a default configuration and clone it to many production devices. The purchaser of each device can use oem-config to set their own username and password, language, time zone, and so on.
On a headed target device (one equipped with a display), oem-config runs as a GUI application. On a headless target device (one without a display), it runs as a character interface application.
After the target device runs oem-config on first boot, it disables the tool so that it will not run on subsequent boots. If you install your own package and flash the target device manually (outside SDK Manager), you must re-enable oem-config manually if you want it to run on the first subsequent boot. Again, the target device disables oem-config after running it once.
To re-enable oem-config manually on a flash drive
1. Select a source device of the same type as the target device(s), on which all necessary packages have been installed.
2. Install these packages on the source device to enable oem-config for the next reboot: ubiquity, oem-config, and oem-config-gtk. Enter this command:
$ sudo apt-get install --no-install-recommends ubiquity oem-config oem-config-gtk
18. Remove the package nvidia-l4f-oem-config:
$ sudo dpkg --purge nvidia-l4t-oem-config
19. Clone the source device's APP partition to backup.img and backup.img.raw. For details, see To clone a Jetson device and flash.
20. Mount backup.img.raw (an ext4 image file) on the host a mount point of your choice.
21. Apply any Jetson-specific binaries to the image file. The nv-oem-config setup files are included in the apply_binaries script. To run this script, enter:
$ cd Linux_for_Tegra
$ sudo ./apply_binaries.sh -r <root>
Where <root> represents the backup.img.raw mount point.
22. Set nv-oem-config.target as the default.target:
$ cd $root/etc/systemd/system
$ sudo rm default.target
$ sudo ln -s /lib/systemd/system/nv-oem-config.target default.target
23. Unmount the device mounted in step 18:
$ umount $root
24. Make a sparse version of the updated image file backup.img.raw and name it system.img:
$ cd Linux_for_tegra/bootloader/
$ sudo ./mksparse -v –fillpattern=0 /path/to/backup.img.raw system.img
25. Flash system.img to the target device(s). For details, see To clone a Jetson device and flash.
To re-enable oem-config manually on an SD card
1. Select a source device of the same type as the target device(s) on which all necessary packages have been installed.
26. Enter this command to install the following packages on the source device to enable oem-config for the next reboot: ubiquity, oem-config, and oem-config-gtk:
$ sudo apt-get install --no-install-recommends ubiquity oem-config oem-config-gtk
27. Remove the package nvidia-l4f-oem-config:
$ sudo dpkg --purge nvidia-l4t-oem-config
28. Power off the source device and remove the SD card from it, then insert it into in the host system.
29. Mount partition #1 of the SD card (an ext4 filesystem) on the host, using a mount point of your choice.
30. Apply any Jetson-specific binaries to partition #1 of SD card. The appropriate files are listed in nv-oem-config, and are applied by the apply_binaries script. Emter tjos cp,,amd to run the script:
$ cd Linux_for_Tegra
$ sudo ./apply_binaries.sh -r <root>
Where <root> represents the partition #1 of SD card mount point.
31. Set nv-oem-config.target as the default.target:
$ cd $root/etc/systemd/system
$ sudo rm default.target
$ sudo ln -s /lib/systemd/system/nv-oem-config.target default.target
32. Run jetson-disk-image-creator.sh to create a new SD card image with modified rootfs:
$ cd Linux_for_Tegra/tools
$ sudo ROOTFS_DIR=<root> ./jetson-disk-image-creator.sh -o sd-blob.img -s 4G -b jetson-nano -r 100
Where <root> represents partition #1 of the SD card on its mount point. For details, see To generate an image to be flashed to an SD card.
33. Enter this command to unmount the device mounted in step 29:
$ umount $root
34. Flash sd-blob.img to the new SD card. For details, see Flashing to an SD Card.
About Communication Through the Debugging Port
The serial application on the host computer customarily communicates with oem-config through the host computer’s tty device and the target device USB port that is used for flashing. (See Assumptions in the Quick Start Guide.)
Some Jetson developer kits also have a UART port on a 40‑pin header. You can edit the oem-config configuration file to make oem-config use this port instead. You must make this change before you flash images on the target device.
Jetson Nano supports use of the micro USB connector as a debugging port. This is the easiest way to control a headless Jetson Nano device, since a USB to TTL adapter is not required.
To configure oem-config to use a 40‑pin header UART port
1. Locate the appropriate configuration file on the host computer:
For Jetson Nano and Jetson TX1: <top>/etc/nv-oem-config.conf.t210
For Jetson AGX Xavier: <top>/etc/nv-oem-config.conf.t194
For Jetson TX2 series devices: <top>/etc/nv-oem-config.conf.t186
35. Open the configuration file and file the line that defines the property:
nv-oem-config-uart-port=ttyGS0
36. Change the value of this property from ttyS0 to ttyTHS1.
37. Save and close the configuration file.
38. Proceed to flash the target device as described elsewhere in this topic.
Headless Mode Flow in oem-config
Before the target system boots for the first time, you must start a serial application on the host computer. You may use putty, screen, or any other serial application that communicates through the host computer’s tty device and supports the UTF‑8 character set.
Note
NVIDIA does not recommend using minicom for this application because it has some issues dealing with UTF‑8.
When the target device boots for the first time after flashing and finds no display device, it runs oem-config in headless mode. Use the following procedure to reconfigure the target device.
To reconfigure the target device with oem-config
1. oem-config displays a welcome screen. To advance to the next screen, press Tab, then Enter.
2. oem-config displays the license that governs its use. Read the license, then accept it by pressing Tab, then Enter.
A screenshot of a cell phone Description automatically generated
3. oem-config displays a screen that lists languages. Use the up and down-arrow keys to select the language you want to use for the installation process. Then press the left and right-arrow keys to select “OK,” and press Enter.
A screenshot of a cell phone Description automatically generated
Note
To go back from any screen to the preceding one, select “Cancel” and press Enter. You can go back more than one screen by doing this more than once.
4. oem-config displays a screen that lists locations in which the language you selected is used. Select your location; then select “OK” and press Enter.
A screenshot of a cell phone Description automatically generated
5. oem-config displays a screen that lists keyboard layouts. Select your keyboard’s layout, then select “OK” and press Enter.
A screenshot of a cell phone Description automatically generated
6. oem-config displays a screen that lists time zones that exist in the location you select. Select your time zone, then select “OK” and press Enter.
A screenshot of a cell phone Description automatically generated
If your time zone is not listed, select “Cancel” as many times as necessary to go back to the screen that lists locations, and choose a different location.
7. oem-config asks whether you want to set the system clock to Universal Coordinated Time (UTC, or Greenwich Mean Time). Linux expects the system clock to be set to UTC; therefore, NVIDIA recommends that you select “Yes” and press Enter. If you are using another operating system that expects the system clock to set to local time, however, select “No.”
A screen shot of a smart phone Description automatically generated
8. oem-config asks you to specify your name. Enter your full name (e.g. John Smith), then select “OK” and press Enter.
A screenshot of a cell phone Description automatically generated
9. oem-config asks you to specify a username for your user account. oem-config creates a user account for this name. then select “OK” and press Enter.
NVIDIA suggests using your first name, using lower case letters only. Use this account instead of the root account for non-administrative activities.
A screenshot of a cell phone Description automatically generated
10. oem-config asks you to specify a password for your user account. Enter a password, then select “OK” and press Enter.
NVIDIA recommends that you specify a strong password, i.e. one that is more than eight characters long and contains at least one each of upper and lower case letters, numerals, and punctuation characters. If you enter a weak password, oem-config will ask you to confirm that you want to use it.
A screenshot of a cell phone Description automatically generated
11. oem-config asks you to enter your password again to confirm that you entered it correctly. If you enter the same password both times, it sets the password and goes on to the next step. If not, it prompts you to specify a password again.
A screenshot of a cell phone Description automatically generated
12. oem-config prompts you to specify the desired size of the APP partition in megaytes. To request the maximum possible size, leave the field empty or enter 0 (zero).
A screenshot of a cell phone Description automatically generated
13. oem-config displays a list of interfaces which it can use as the primary network interface during installation.
If you are using Ethernet as the primary network interface, make sure the Ethernet cable is connected. Then select the eth0: Ethernet option, select “OK,” and press Enter.
A screenshot of a cell phone Description automatically generated
Note
Note: NVIDIA does not recommend choosing the wireless network interface at this time. Use Ubuntu NetworkManager utility to configure the wireless network after oem-config is run. For more details see https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/configure-wifi-connections.
14. oem-config prompts you to enter your host computer’s hostname. If you don’t know the host’s name, ask your network administrator. If you are setting up a dedicated network, you may choose any name. Enter the hostname, then select “OK,” and press Enter.
A screenshot of a cell phone Description automatically generated
15. oem-config reconfigures the system with the selections you have made, then proceeds to the system’s log-in prompt.