I have the same problem. When I restart the device, the changes I do is removed and the deleted files are recovered.
Does this happen to any kind of file or just some specific file?
Any log or video to prove or shown what you saw?
Are you shutting down normally with a software command?
Yes! I am shutting down with the power off button on the top right of the screen.
- What are the specific files in question?
- What do you see from “
df -H -T”? - By what method are you deleting them?
- Does this occur for just specific files, or does this occur for all files?
In part I’m looking to see what kind of journal is used (likely it is just an ext4 journal, but I don’t know what else is mounted). I’m also interested in knowing permissions and locations of those files, and so if you can get an “ls -l” on all such files (or at least a good sample size), this would help.
Then, before rebooting, start a serial console log session. Keep the serial console logging going until reboot is finished and you’ve logged in and run “ls -l” on the file names which were restored.
This occurs for any file. I am able to delete files and change them but it becomes the older version after every reboot. For example, if I add one line in A.txt first and that line disappears after I reboot the device. Also, if I delete a file, it is recovered after reboot. I used the jetson for 4 months then this happened. If I add a python code, I am able to run it and do whatever I want but after rebooting, it disappears. If I forget the network it is connected, after rebooting, it is connected again.
Are you using the rm command to delete?
If you know of a file which you can safely delete, but which will reappear, run this before delete to see what its inode number is (I’ll pretend the file name is “deleteme”):
ls -il /where/ever/it/is/deleteme
(write this down so you can post it later)
Then run this command and see if other files appear (I’m pretending the inode shows as 123456789, but use the inode number which appears in the “ls -li” command):
sudo find / -inum 123456789
Write down and post how many files show up. If there is more than one then we’ve found some cross linked files which are likely a result of some form of corruption. If there is more than one, then you could log it like this and attach the log:
sudo find / -inum 123456789 2>&1 | tee log_inodes.txt
(this will take some time since it is searching every inode in the system; some filesystems related to dbus might be unreadable, that is to be expected)
Then reboot and perform the same operation on the file which has reappeared. It is important to have the “before” and “after” results for a single file which has this happening.
ext4 can restore content if the journal is triggered and if there is sufficient journal size. Cross linking could imply there was a write while the filesystem was corrupt and can no longer be saved. Depending on what happens, we might get an strace of the file delete operation. We’ll want to use the same file very time.
It is getting more interesting. The inode is not using multiple hard links, which suggests not being corrupt. At least not for that file (perhaps for a containing directory somewhere though). What about the timestamp? When it is recreated, is the timestamp unchanged, or does the timestamp appear to be updated for (A) time of shutdown, or (B) time of new boot? Basically, delete the file, wait a few minutes, then shutdown. Wait a minute. Then start. Does the timestamp follow (A) no change, (B) change during shutdown, or (C) change during boot?
1 Like
No change. Google Chrome history has no new input after August 23 when it is rebooted. It looks like the system recovers itself with every restart.
please share the boot up log from uart.
I will suggest that if you use “ls -l” to check a specific file, and then provide the serial console boot log suggested by @WayneWWW (including shutdown, and not just boot), followed by the ls -l of that same file after reboot, that the log file would be more valuable. You might even run the sha1sum command on the file before and after to see if content changes (the serial console program should capture that).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.