Power off SOM after completion of flash.sh

We’d like to turn off the SOM immediately after completion of flash.sh, is there any known option or method to have the SOM turn off instead of automatically rebooting upon completion of flash.sh?

One thing we noticed was that turning off the SOM midway through the first boot may leave SSH keys in a corrupt state.

The Magic Sysrq key setup could in theory at least call sync and remount read-only prior to reboot, but I don’t think it would provide actual shutdown. However, unless you are sitting at the keyboard, the only way to do this is to be logged in with an account which has sudo privileges, and echo to the correct file ("/proc/sysrq-trigger").

Maybe if you shared more information about what it is you want to accomplish, and why you want to force shutdown, perhaps other ideas could be found. Otherwise it sounds like the “driver package” would need a modification to tell the flash to not reboot, and I don’t even know if that is possible.

More specifically we want to cold-boot the system after programming, for following reasons:

  • in a manufacturing setup the SOM needs to spend extra time completing first boot at the station running flash.sh when it could be first powered up independently in a prebuilt unit. If the SOM is powered off early during boot it will corrupt SSH identity generation
  • a software reboot is not the primary boot method and may require working around edge case bugs
  • generally reduced time spent preparing a SOM, whether by hand or in automated setups
  • no need to make a wrapper script to automate running flash.sh, waiting for USB device to appear, then executing software shutdown again

Are you speaking of first boot setup? Or ssh keys? More details on specifically what you mean by “corrupt ssh identity” would be useful.

You may be interested in a script available in this post:
https://forums.developer.nvidia.com/t/jetson-nano-all-usb-ports-suddenly-stopped-working/75784/37

The “l4t_create_default_user” script can add an account name to the image being flashed, along with password. As a result the home directory would exist and login possible prior to ever flashing, although I’d be careful about that if you are sending this out with a “default” to end users. If the home directory content exists, and if you mean ssh keys, then this could be added before flash ever starts.

I personally use an overlay directory tree I created with some home content, including ssh keys, network setup, some GUI setup, so on. If I flash using that content, then I can ssh in even on first boot using keys. Since my tree is separate from the default image (though I copy it recursively into the default image) it tends to work even after release versions change (for example, ssh keys and user name do not need to change for different releases).

That particular script, even if you don’t use it, is worth examining since it is human readable. The script uses QEMU to operate on the default image as if the image were in a running system. This wouldn’t help on some edge cases where something fails, but it would make it possible to automate a lot of other customizations. This is not actually a “wrapper script” to flash.sh as it merely gets installed once, and from then on generated images contain that information (wrappers to flash.sh tend to run each time, whereas QEMU is used once on the Linux_for_Tegra/rootfs/ content, which is inherited during a normal flash).

Hint: One can mount a loopback clone to replace “Linux_for_Tegra/rootfs/”, it doesn’t have to be the default Ubuntu reference install. Note that if content is on your image before flash, then there is no need to add content from the running system. You could in fact use a clone of a fully updated system with all of your software on it. A loopback mounted clone can also work on a PC with QEMU if you want to go that far.

Actually we’re already using that script (l4t_create_default_user.sh) to prepare a rootfs image.

The corruption I saw was of ssh host keys. I saw several 0-byte host keys in /etc/ssh/ (logged in through UART) on one instance, where I recall pulling power from the SOM shortly after flashing without sending a software shutdown command.

Maybe we just need to script a way to make sure those host keys are generated correctly before flashing and we can just ignore safe shutdown on first boot.

If you write to a file, and the journal has not marked flush to disk as complete, then at minimum content of the file will be missing. In some cases the whole file will be missing. In a more extreme case where the data exceeds the journal capacity, then actual unrecoverable corruption of the ext4 itself will occur.

After a flash the unit will self-reboot. If you are able to detect this and prevent the actual boot, then probably this would not be a problem (prior to reboot recovery mode essentially performs a safe shutdown, and when it comes back, then it is up to Linux to reboot correctly…e.g., the end user). However, I do not know how to cause a flash to halt instead of reboot.

Would anyone from NVIDIA know if flash completion can be set up to halt instead of reboot? Perhaps an option could be passed to the flash software, but I have not heard of it.

Otherwise the only option you have is to login during after the boot and either shut down properly or sync and remount read-only prior to cutting power. Your current method of cutting power causing disappearance of recently written content is working as intended to protect from a larger and more damaging corruption.

One hack, if serial console is available and if U-Boot is set to allow interrupt to U-Boot command line, then you could press and hold a key on serial console. Reboot would halt within U-Boot, and the filesystem would probably not have issues with cutting power.

1 Like