Hello,
I would like to modify rootfs before flashing (with flash.sh) in order to create a new user.
On a working TX2i, I added a user with: adduser.
Then I copied the files: group, group-, passwd, passwd- to rootfs\etc in the host PC that flashes the TX2i.
Flashing was completed successfully.
But after boot, when I tried to change to the new user, I got “invalid password” error.
Can you please tell what is wrong in my procedure?
Thank you,
Zvika
You probably need to copy shadow files as well. If permissions were incorrect, then this will also cause some failures.
Here is a script which has worked in the past, and I don’t see why it wouldn’t work with a TX2i as well:
https://forums.developer.nvidia.com/t/jetson-nano-all-usb-ports-suddenly-stopped-working/75784/37
Direct link to script:
https://forums.developer.nvidia.com/uploads/short-url/xMF6uijxdcBfNYWQxDNcQEWEmOJ.gz
You can chroot/proot into the rootfs provided by nvidia before running flash.sh and do that, yes. You can also update the system and install software provided you modify the apt sources appropriately.
Assuming you want to add a user to just run an a dedicated app, you probably want to use the --system option. Otherwise the user will be visible at the login screen. Nvidia also provides a script to set the default user if you want a bypass it’s creation at first boot.
I see linuxdev has linked to it above. It is linked to in the Nano FAQ as well but is crossed out for some reason. As such it may be advisable to ask in that thread before running it. It may be it’s not compatible with the latest release since Nvidia has made some recent changes to the first boot scripts.
Interesting thought…I’ve not tried to use chroot with the sample rootfs. I’ll try this some time for passwords and user name addition. If this works it is one of those “aha!” moments…such a simple workaround. Better than coffee!
It works. Just make sure to copy or bind mount the qemu static binary for aarch64 as well as any requisite special filesystems. Here is a script that does it. It’s good enough to run apt, build stuff, and add users. I have only tested it with system users, however ( < uid 1000).
There is also my tegrity python package, which has a similar chroot scripts and some smarter handling of mounts.
Just do:
sudo tegrity-qemu --enter path/to/rootfs
The rest of the package is targeted towards Nano exclusively for the moment, but I plan on supporting more boards in the future. In any case, those are two options for editing the rootfs.
Lastly, for apt to work, you’ll want to ensure apply_binaries.sh has already been run (installs the key and some other stuff) and this file looks like this:
$ cat ...rootfs/etc/apt/sources.list.d/nvidia-l4t-apt-source.list
deb https://repo.download.nvidia.com/jetson/common r32 main
deb https://repo.download.nvidia.com/jetson/t194 r32 main
It will say <SOC> on the default file, which is filled in on first boot by /etc/systemd/nvfb.sh on first boot, but it doesn’t hurt to fill it in beforehand. The values for each board are as follows:
... rest of /etc/systemd/nvfb.sh ...
# Update chipid to apt source list file
SOURCE="/etc/apt/sources.list.d/nvidia-l4t-apt-source.list"
if [ -e "${SOURCE}" ]; then
CHIP="$(cat /proc/device-tree/compatible)"
if [[ "${CHIP}" =~ "tegra210" ]]; then
sed -i "s/<SOC>/t210/g" "${SOURCE}"
elif [[ "${CHIP}" =~ "tegra186" ]]; then
sed -i "s/<SOC>/t186/g" "${SOURCE}"
elif [[ "${CHIP}" =~ "tegra194" ]]; then
sed -i "s/<SOC>/t194/g" "${SOURCE}"
else
logger "nvfb: Updating apt source list failed with exit code: 1"
fi
fi
eg. for tegra210 replace <SOC> with t210. Then save, run apt-get update and so on and so forth. It’s possible to update the system and install stuff like deepstream this way before first boot, saving update time, and your network if you’re deploying a whole bunch of devices at once.
Hi linuxdev,
Thank you very much for your reply.
I copied also shadow, shadow- to rootfs/etc
It works great.
Best regards,
Zvika
Just a note: if you copy /etc/shadow, you probably want to make sure to copy /etc/passwd as well, just to make sure the usernames exist. That’s another way of doing this. Also double check /etc/shadow is not world readable. Conversely, I think /etc/passwd does need to be world readable. If you double check the permissions from source to target you should be golden. cp also has a --preserve=all flag to preserve permissions, ownership, attributes, etc.