Jetson nano does not boot anymore problem with sd card

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

hi

my jetson nano was running smoothly the last couple of months and now it just does not boot anymore. i guess it is a problem with the sd card, since it boots up with an other sdcard with an old jetson image. i was wondering if there is the possibility to get the whole setup from the ‘broken’ sd card and transfer it to a new or back on this after formatting. Or is there an other way?!

i really appreciate help, i have unsaved work on this card :-|

cheers

2

Often you can use dd to recover an SD card, but only if the basic function is there. You might be missing some data, but on your host PC try what follows. Be certain you have a lot of spare disk space, e.g., via “df -H /where/ever/you/store/recovered/images/". If it works, then this will generally take a lot of time to complete (SD cards are slow). Also, on the host PC, be very very certain you are naming the right device...I am using an example name /dev/mmcblk0, but I don't know if this will be correct on your host PC. This will attempt to recovery the first partition ("p1" of "mmcblk0" is "mmcblk0p1`”).

cd /where/ever/you/store/recovered/images/
# Most of this requires root privilege, so go into a root shell:
sudo -s
# Verify partitions can be examined:
gdisk -l  /dev/mmcblk0
# More will have to be considered of the partition table cannot be read. If the
# table can be read via gdisk, then I think you are in luck. Now try to copy the
# first partition:
dd if=/dev/mmcblk0p1 of=clone_rootfs.img bs=512
exit

Note that a 512 byte block size is a default, and actual result does not usually change if you have a different block size…this is just a buffer and not part of the disk. However, in cases where you get a failure in a block you will find that the entire block will fail. If you were to do the same thing with a “bs=1” it would take much longer, and for a failing block, then you’d lose that specific byte only. If the SD card has a completely failed 512 byte block, then “bs=512” would be perfect in that it would be the fastest copy method and also failures would be fastest to work with. Personally, I would use 512 and if something fails, accept the 512 bytes and don’t bother with individual bytes.

If this works up to this point, then we can go over loopback mounting and repair. The basic loopback read-only mount to test is:
sudo mount -o loop,ro /where/ever/it/is/clone_rootfs.img /mnt
ls /mnt
sudo umount /mnt
(if there are ext4 errors, then you might end up correcting them here, but you could lose content, so you might want to save the original raw clone image and work with a copy of the clone)

3

Hi

Thanks for the very detailed answer.

I tried it and i have the problem now that it only sees 121.3 MiB, but it is a 64GB SD card. I try the dd anyway

Here the output of gdisk:

GPT fdisk (gdisk) version 1.0.3

Warning! Read error 5; strange behavior now likely!
Warning! Read error 5; strange behavior now likely!
Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.
Disk /dev/sdb: 248320 sectors, 121.3 MiB
Model: USB    CRW-SD   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B85E31EB-4E08-4994-A8CD-FA504E98D898
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 248286
Partitions will be aligned on 2048-sector boundaries
Total free space is 248253 sectors (121.2 MiB)
4

This is the dd output

dd: error reading '/dev/sdb': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 119.292 s, 0.0 kB/s
5

“dd” has an option “noerror”. Can you try with that? So something like this (adjust for your device name):
dd conv=sync,noerror if=/dev/mmcblk0p1 of=clone_rootfs.img bs=512

What this will do is continue reading even if there is error, and errors should be replaced with NULL bytes to preserve data length. If this is an electrical fault in the SD card then it may not help, although this is often very helpful on old style mechanical hard drives. Does this give you a full size image? If so, what do you see from gdisk list of the clone?

sudo -s
losetup --find --show ./clone_rootfs.img
gdisk -l whatever_the_loop_device_name_was
losetup -d whatever_the_loop_device_name_was
exit
1 Like