Jetson AGX Xavier boot failure

I’m using the Jetson AGX Xavier Developer kit with Ubuntu 18.04.
The other day, when I ran a Python program, I got an error indicating something like insufficient memory.
So I restarted Jetson, and after the following screen appeared, it went completely dark and I couldn’t operate it anymore.

iwlwifi 0003:01:00.0: Direct firmware load for iwlwifi-8265-24.ucode failed with error -2
iwlwifi 0003:01:00.0: Falling back to user helper
iwlwifi 0003:01:00.0: Direct firmware load for iwlwifi-8265-23.ucode failed with error -2
iwlwifi 0003:01:00.0: Falling back to user helper
thermal thermal_zone8: failed to read out thermal zone (-5)

Is there a solution to this problem? Thank you.

I am wondering if it ran out of eMMC disk space (which can fail in odd ways like this). Does your Python program ever write to disk? Also, can you provide a serial console boot log?

I used Teraterm to connect to COM Port.
The following message was displayed when Jetson started.
Are these related?

Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.9.140-tegra aarch64)

To restore this content, you can run the ‘unminimize’ command.

332 個のパッケージがアップデート可能です。
91 of these updates are security updates.
To see these additional updates run: apt list --upgradable

Traceback (most recent call last):
File “/opt/ros/melodic/_setup_util.py”, line 295, in
sys.stdout.flush()
IOError: [Errno 28] No space left on device
Failed to run '"/opt/ros/melodic/_setup_util.py" ': return code 1

I don’t think the python program will write to disk.

The “unminimize” is unrelated and not an error…it is just pointing out that man pages are not installed as a way to save space, but can be installed.

This part confirms space is filled:

...
File “/opt/ros/melodic/_setup_util.py”, line 295, in
sys.stdout.flush()
IOError: [Errno 28] No space left on device
...

Note carefully that this is listing function “sys.stdout.flush()”. If stdout is going to the terminal, then you are correct that the device does not write, but if there is any sort of file redirect, then this may actually require write to disk.

You might be surprised at the number of programs which do not write to disk, but would fail, if disk is full. This is because often authentication or other parts of the process require lock files or other zero-content files to run as temp content. Despite no content in such temp files the file name itself uses an inode (at least 512 bytes), so lock files, auth files, so on, will fail.

Basically you have to delete some unused content. Serial console is good for this if it allows login. You can view space via “df -H /” and you will find you’ve run out of space, or “df -H -i /” for inode use.

After deleting unnecessary files, I was able to start it.
Thank you very much.