A Jetson is very similar to any desktop PC. The Linux ext4 filesystem originally (when it was ext2) did not have a journal. Any time ext2 lost power with unwritten changes, then the filesystem would have to be repaired. It is a tree structure, and depending on what was corrupt, it might end up missing files or even entire directories. Some more extensive failures would be uncorrectable. When a repair (fsck) actually does remove something, and the tool does not know where that “something” belongs, it’ll put it in the “lost+found/” directory of that partition. This at least gave a “repaired” filesystem a way to hint to the administrator what was lost (assuming fsck could figure it out).
Once the filesystem evolved beyond ext2 it gained a journal (and is now ext4). That journal is synchronous, and it is written exactly at the time anything is told to write to it. It is very slow, but it is also very tiny, and so it doesn’t have a lot of impact. The rest of the filesystem is buffered or cached, and takes a moment to actually write once told to write. Once that write is complete the journal entry is removed. When shut down improperly, if the amount of entries being written does not exceed the journal size, then changes are just backed out by reverse order. No damage, no removed nodes, nothing needs to go to “lost+found/”. However, if the amount of changes exceeds the size of the journal, then you are essentially back to the old days of not having a journal. fsck would be used to repair, and this might mean the tool having to guess, and also might end up putting some content in “lost+found/”.
Once any corruption exceeds journal size it is unsafe to perform any kind of write operation. Thus, only in cases where the amount of damage and nature of damage is simple, would the system be able to recover. In more extensive cases the system will demand to only work on that partition in read-only mode. The administrator would have to manually run fsck.ext4 on the partition (in your case, if you have a USB drive and can work on it from another Linux system, this would be the perfect way to do it…otherwise you need a rescue mode capable of running fsck.ext4 while the partition is read-only). There is no guarantee that whatever needs to be trimmed from the filesystem tree will leave the system bootable.
Do you have another Linux host PC system? If so, then:
- Monitor “
dmesg --follow” from the host PC.
- Then insert the USB cable for the drive, and note which device it is (probably something like “
/dev/sdb”).
- This should not be mounted, and if there are enough errors, then the host PC won’t mount it. This is how you want things during a repair (unmounted).
- Note that the device as a whole might have the name “
/dev/sdb”. The first partition would be “/dev/sdb1”. You’ll need to know which partition is involved. If the device sdb, then this command would provide some details about its layout:
lsblk -f /dev/sdb
- Attempt automatic repair (I assume the name is “
/dev/sdb”, and that the ext4 partition is “/dev/sdb1”, adjust for your case to name the ext4 partition):
sudo fsck.ext4 -p /dev/sdb1
If the above worked, then make sure it is not mounted when you unplug it. After a successful repair it is possible it might auto mount. You can use “lsblk -f /dev/sdb” to see (after done) if it mounted and needs “sudo umount /dev/sdb1”.
If damage was sufficient, then you might need to force check. Automatic repair might refuse. This is an indication that damage is more extensive. Any repair (once done) will have hints as to what was removed by examining the “lost+found/” subdirectory at whatever mount point the partition is mounted on.
If you must force check, then you might try this (assuming the “-p” option does not do the job; I am also assuming it is “/dev/sdb1”):
sudo fsck.ext4 -fvy /dev/sdb1
Usually what gets corrupted is the content which was being written. Damage is not necessarily limited to this though since writing to a file in a directory might update the directory entry, and the directory itself might have been caught mid-write during the power loss.
Incidentally, if your Jetson boots to SD card, then it works as a host PC during the above rescue since attaching it after boot, without mounting it, leaves the drive read-only when damaged. This is one case where the Jetson itself could be used as a host PC (though likely the drive would change to name “/dev/sda”…just watch “dmesg --follow” as you plug in the USB drive).
There are ways to backup a corrupt partition via “dd” if something valuable is on it and repair might damage something. One could work on the loopback mounted backup and leave the original drive untouched until you are certain what you want to do. Repair tools don’t know the difference between an actual partition and a loopback file (via dd backup) pretending to be a partition.
Good luck, and just ask if you have more questions.
