R32.2 after flash can't run jetson_clocks or nvpmodel? EPERM and ENOENT errors

sudo jetson_clocks /usr/bin/jetson_clocks: line 277: /sys/devices/17000000.gp10b/railgate_enable: Permission denied /usr/bin/jetson_clocks: line 278: /sys/devices/17000000.gp10b/devfreq/17000000.gp10b/min_freq: No such file or directory sudo nvpmodel -m 0
NVPM ERROR: Error opening /sys/devices/17000000.gp10b/devfreq/17000000.gp10b/available_frequencies: 2
NVPM ERROR: failed to read PARAM GPU: ARG FREQ_TABLE: PATH /sys/devices/17000000.gp10b/devfreq/17000000.gp10b/available_frequencies
NVPM ERROR: failed to set power mode!
NVPM ERROR: optMask is 1, no request for power mode

What did I do wrong?

Does the following command work, or does it give permission denied?

sudo ls

HAHAHAHAH! Yeah that works fine.

sudo is setup so user ‘nvidia’ doesn’t need a password.

EDIT: This maybe Leopard Imaging issue since they distribute now a prebuild kernel for Jetpack to enable their camera software. I am confirming this now.

I am curious as to what was done for:
“sudo is setup so user ‘nvidia’ doesn’t need a password.”

My reason for asking is based on how file system permissions were transferred to the TX2 during flash. If this was done correctly, then there will be an suid root bit, but if you’ve set this up in some modified fashion, then the “sudo ls” test may not reveal anything. What do you get as an exact answer for:

ls -l /usr/bin/sudo

The answer must start with (note the “s” for suid):

-rw<b><i>s</i></b>r-xr-x 1 root root

$ cat /etc/sudoers.d/nvidia

It works fine. It’s not sudo.

What do you see from (with and without sudo):

ls -l /sys/devices/17000000.gp10b/railgate_enable
sudo ls -l /sys/devices/17000000.gp10b/railgate_enable

The node isn’t there which is why I suspect there is an issue with the kernel image given to me by the vendor. I also see other weirdness with the nvargus daemon crashing occasionally (?).

I’m reflashing again to see if this was some kind of bad flash or my vendor instruction reading skills are just very weak.

The nodes are created by drivers, and often drivers (if they exist but don’t load) depend on device tree setup. So one of two things is occurring: Either the kernel is different and was not compiled with the correct configuration, or else the hardware is missing device tree or firmware setup such that the driver cannot load correctly.

Agreed. We’ll find out in another 15 minutes.