Corrupted SD cards

This card has not been subjected to any power cycles without proper shutdown so I suspect that it’s a hung task. Is there a good way to check this?

Over the last 10 years I’ve seen jetsons survive 10s if not 100s of hard power cycles without a single filesystem corruption on the SD card. So it seems odd that it suddenly happens frequently. Perhaps it’s a bad batch of SD cards. I’ll see if I can rule that out by testing some other batches.

If you go to your host PC where you flashed the content, you will have this directory:
~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/

Within that, go to subdirectory “rootfs/sys/”. Run ls. Is there content there? This is what creates any actual disk content during a flash. Anything not there should be dynamically generated at runtime. The runtime content is in RAM and does not exist on the disk.

If for some reason there does happen to be a file in “/sys”, then if one mounts another filesystem there (regardless of whether it is real, e.g., ext4, or virtual, e.g., tempfs), then the old content is hidden until umount of that filesystem which sits on top of it. Did your flash software on the host PC have content in the “rootfs/sys/”?

Please take a second to understand what I said. I know that sysfs is a virtual filesystem and is not backed on storage, but the /sys directory itself is. Not its contents. The /sys directory is what got corrupted.

If something were written to “/sys” before the pseudo filesystem was mounted there, then this could corrupt the SD card part of it. As soon as “/sys” mounts, that part of the SD card would become invisible. It isn’t possible for the pseudo “/sys” to become corrupted unless the actual kernel code is altered. The part which I have never considered before is that if (A) the underlying ext4 filesystem of the SD card is corrupted, and then (B) a pseudo filesystem is mounted over this, what would happen if “/sys” were mounted over a corrupt ext4 mount point? I could see the latter appearing as a corrupt “/sys” via the corrupt mount point, but otherwise the only way I could see “/sys” being corrupt is through altering of the kernel itself.

If you were to monitor “dmesg --follow” on a different Linux host PC, and then insert the SD card, does it show corruption? If so, does it show this as repairable? If repair is successful, does use as an SD card on the Jetson cause it to recorrupt (I’d get a full serial console boot log the first time a repaired SD card is used on the Jetson)?

In this case I’ll reiterate what is very important: The mount point of “/sys” exists on the ext4 filesystem, and is part of the sample rootfs (which on the host PC which flashes is “Linux_for_Tegra/rootfs/sys/”). This should be empty on any SD card. This does serve as a mount point for the pseudo filesystem. Somehow we have to distinguish between whether the empty mount point is corrupt, and thus causing “/sys” to inherit that corruption, versus whether something is saying “/sys” itself is corrupt. The pseudo filesystem is not ext4, and some of the concepts of ext4 corruption are alien to the sysfs filesystem type. In no case is anything from a sysfs filesystem ever saved to disk. I do not know if a corrupt mount point which a sysfs filesystem is mounted to would inherit corruption.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.