Unable to flash the Jetson AGX Xavier; Fail at File System and OS

I am running SDK Manager 1.6.1.8175 on Ubuntu 18.04, and it is able to detect the Jetson AGX without any problem, but everytime I try to install Jetpack, it fails.

I am seeing the following error:
0:23:08.682 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: current working directory is /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
10:23:08.682 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: exec_command [host]:
10:23:08.682 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: **********************
10:23:08.682 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: #!/bin/bash
10:23:08.682 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: set -e
10:23:08.683 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: sudo tar xpf /media/x1demo/DATA/Sal/jetson/sdkm_downloads/Tegra_Linux_Sample-Root-Filesystem_R32.6.1_aarch64.tbz2
10:23:08.683 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: cd …
10:23:08.683 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: sudo ./apply_binaries.sh
10:23:08.683 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: sudo mkdir -p rootfs/opt/nvidia/deb_repos
10:23:08.683 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: **********************
10:23:08.683 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: exec_command: /tmp/tmp_NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP.sh
10:26:27.409 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: Using rootfs directory of: /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: ||||||||||||||||||||||| ERROR |||||||||||||||||||||||
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: -----------------------------------------------------
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: 1. The root filesystem, provided with this package,
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: has to be extracted to this directory:
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: -----------------------------------------------------
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: 2. The root filesystem, provided with this package,
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: has to be extracted with ‘sudo’ to this directory:
10:26:27.420 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
10:26:27.421 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: -----------------------------------------------------
10:26:27.421 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: Consult the Development Guide for instructions on
10:26:27.421 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: extracting and flashing your device.
10:26:27.421 - info: NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP@JETSON_AGX_XAVIER_TARGETS: |||||||||||||||||||||||||||||||||||||||||||||||||||||

Does anybody know what is going wrong that the root filesystem keeps failiing?SDKM_logs_2021-09-02_14-24-41.zip (102.9 KB)

I see this:

Info: exec_command: /tmp/tmp_NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP.sh
Using rootfs directory of: /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
||||||||||||||||||||||| ERROR |||||||||||||||||||||||
-----------------------------------------------------
1. The root filesystem, provided with this package,
   has to be extracted to this directory:
   /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
-----------------------------------------------------
2. The root filesystem, provided with this package,
   has to be extracted with 'sudo' to this directory:
   /media/x1demo/DATA/Sal/jetson/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs
-----------------------------------------------------

The above reminds me of two possibilities, though it is speculating a lot.

The first is that JetPack/SDKM must be run as a regular user, but the user’s password has to be present to use “sudo” at times. This is one of those times, so perhaps the password is not working.

The second is that if the host PC’s Linux install is not correct, then the “sudo” command cannot work. For example, if the host PC Linux is on a Windows filesystem such as NTFS, then mandatory “suid” bits don’t exist. On the host PC, if you run command “ls -l /usr/bin/sudo”, then the first part of the reply (which shows permissions and ownership) should be:
-rwsr-xr-x 1 root root
…do those permissions and ownership show correctly? As a test, can you succeed at “sudo ls”?

Regarding Windows, the machine used to have Windows installed but I wiped it out to install Ubuntu (not dual boot - Windows is completely removed)

ls -l /usr/bin/sudo

-rwsr-xr-x 1 root root 149080 Jan 19 2021 /usr/bin/sudo

sudo ls

Pictures
Programs
Desktop
Public
Documents
SDKM_logs_2021-09-02_14-24-41.zip
Software
Miniconda3-latest-Linux-x86_64.sh
temp
Templates
nvidia-benchmarking-scripts-master
Videos
NVIDIA_CUDA-11.4_Samples
nvidia_tools

please make sure the file system is compatible.

Yes, I saw that article before posting (which is why I specifically mentioned I wiped out Windows completely), and that does not appear to be the issue with SDK manager in this case.

FYI:
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 32G 0 32G 0% /dev
tmpfs tmpfs 6.3G 2.6M 6.3G 1% /run
/dev/nvme0n1p2 ext4 234G 180G 42G 82% /
tmpfs tmpfs 32G 160M 32G 1% /dev/shm
tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/loop1 squashfs 2.3M 2.3M 0 100% /snap/gnome-system-monitor/148
/dev/loop4 squashfs 56M 56M 0 100% /snap/core18/2074
/dev/loop5 squashfs 165M 165M 0 100% /snap/gnome-3-28-1804/161
/dev/loop7 squashfs 2.5M 2.5M 0 100% /snap/gnome-calculator/748
/dev/loop0 squashfs 33M 33M 0 100% /snap/snapd/12704
/dev/loop8 squashfs 640K 640K 0 100% /snap/gnome-logs/106
/dev/loop9 squashfs 100M 100M 0 100% /snap/core/11420
/dev/loop11 squashfs 1.0M 1.0M 0 100% /snap/gnome-logs/100
/dev/loop13 squashfs 384K 384K 0 100% /snap/gnome-characters/550
/dev/loop12 squashfs 286M 286M 0 100% /snap/atom/282
/dev/nvme0n1p1 vfat 511M 7.9M 504M 2% /boot/efi
/dev/loop14 squashfs 63M 63M 0 100% /snap/gtk-common-themes/1506
/dev/loop16 squashfs 2.5M 2.5M 0 100% /snap/gnome-calculator/884
/dev/loop17 squashfs 66M 66M 0 100% /snap/gtk-common-themes/1515
/dev/loop20 squashfs 256M 256M 0 100% /snap/gnome-3-34-1804/36
/dev/loop18 squashfs 296M 296M 0 100% /snap/vlc/2344
/dev/loop21 squashfs 56M 56M 0 100% /snap/core18/2128
tmpfs tmpfs 6.3G 24K 6.3G 1% /run/user/121
/dev/loop22 squashfs 62M 62M 0 100% /snap/core20/1081
/dev/loop24 squashfs 2.5M 2.5M 0 100% /snap/gnome-system-monitor/163
/dev/loop25 squashfs 62M 62M 0 100% /snap/core20/1026
/dev/loop26 squashfs 219M 219M 0 100% /snap/gnome-3-34-1804/72
/dev/loop27 squashfs 243M 243M 0 100% /snap/zoom-client/155
/dev/loop28 squashfs 768K 768K 0 100% /snap/gnome-characters/726
/dev/loop29 squashfs 68M 68M 0 100% /snap/jupyter/6
/dev/loop30 squashfs 244M 244M 0 100% /snap/gnome-3-38-2004/39
/dev/loop31 squashfs 427M 427M 0 100% /snap/pycharm-community/248
tmpfs tmpfs 6.3G 2.7M 6.3G 1% /run/user/1000
/dev/sda2 fuseblk 932G 101G 831G 11% /media/x1demo/DATA
/dev/loop33 squashfs 242M 242M 0 100% /snap/gnome-3-38-2004/70
/dev/loop34 squashfs 214M 214M 0 100% /snap/code/72
/dev/loop3 squashfs 33M 33M 0 100% /snap/snapd/12883
/dev/loop23 squashfs 100M 100M 0 100% /snap/core/11606
/dev/loop2 squashfs 258M 258M 0 100% /snap/zoom-client/158
/dev/loop6 squashfs 427M 427M 0 100% /snap/pycharm-community/250
/dev/loop10 squashfs 67M 67M 0 100% /snap/netron/192
/dev/loop19 squashfs 217M 217M 0 100% /snap/code/73
/dev/loop15 squashfs 68M 68M 0 100% /snap/netron/193

What do you see from:
df -H -T
…and from:
lsblk -f

the output of
% df -h -T was the output above

% lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
loop0 squashfs /snap/snapd/12704
loop1 squashfs /snap/gnome-system-monitor/148
loop2 squashfs /snap/zoom-client/158
loop3 squashfs /snap/snapd/12883
loop4 squashfs /snap/core18/2074
loop5 squashfs /snap/gnome-3-28-1804/161
loop6 squashfs /snap/pycharm-community/250
loop7 squashfs /snap/gnome-calculator/748
loop8 squashfs /snap/gnome-logs/106
loop9 squashfs /snap/core/11420
loop10 squashfs /snap/netron/192
loop11 squashfs /snap/gnome-logs/100
loop12 squashfs /snap/atom/282
loop13 squashfs /snap/gnome-characters/550
loop14 squashfs /snap/gtk-common-themes/1506
loop15 squashfs /snap/netron/193
loop16 squashfs /snap/gnome-calculator/884
loop17 squashfs /snap/gtk-common-themes/1515
loop18 squashfs /snap/vlc/2344
loop19 squashfs /snap/code/73
loop20 squashfs /snap/gnome-3-34-1804/36
loop21 squashfs /snap/core18/2128
loop22 squashfs /snap/core20/1081
loop23 squashfs /snap/core/11606
loop24 squashfs /snap/gnome-system-monitor/163
loop25 squashfs /snap/core20/1026
loop26 squashfs /snap/gnome-3-34-1804/72
loop27 squashfs /snap/zoom-client/155
loop28 squashfs /snap/gnome-characters/726
loop29 squashfs /snap/jupyter/6
loop30 squashfs /snap/gnome-3-38-2004/39
loop31 squashfs /snap/pycharm-community/248
loop33 squashfs /snap/gnome-3-38-2004/70
loop34 squashfs /snap/code/72
sda
├─sda1
└─sda2 ntfs DATA 24E4EC74E4EC499E /media/x1demo/DATA
nvme0n1
├─nvme0n1p1 vfat BB48-01C4 /boot/efi
└─nvme0n1p2 ext4 05359067-2929-4ae9-9901-297dc0bb6529 /

So I see up in that last command “ntfs”, so I re-ran on the other disk, and sure enough, the issue was that disk was an NTFS disk. I can now get past the failing point.

Yes, that is why I said check the “file system” but not the OS.