Few days ago I mistake of deleting a system lib file called “libc.so.6” and I can’t start my TX2 system.So I want to create an image of TX2 which is installed by sdkmanager and recover it manually . Can I use “flash.sh” in Linux_for_Tegra document to create the image of TX2. Or any other way can help . Thanks a lot.
This is the information my monitor displayed at the last time I boot my system.
How can I deal with it.
hello 905122781,
assume you download Jetpack release via SDKManager to flash the target.
so, it’ll also download release image to your local host machine. the default path as following, ~/nvidia/nvidia_sdk/JetPack_<version>_Linux_<platform>/Linux_for_Tegra/
if you only delete this library by accident, you may find it under rootfs folder, please have a try to copy it to your target if you’re able to perform this step.
otherwise, you should re-flash the target to recover this.
you should enter the folder and execute flash.sh to re-flash your target.
partition update could helps to flash only corrupted partition.
please refer to Flashing a Specific Partition session for using the command line option ‑k to flash a specific partition.
since it’s /lib/aarch64-linux-gnu/libc.so.6, you need to flash APP partition to recover it, which means all your user-space contents will flashed.
Hi@JerryChang Thanks you for your reply. May I ask this massage for details
I can find this library under ‘rootfs’ folder.But I can’t even enter the system on my board, how to copy it to my target.
so, you need to re-flash your target.
Hi@JerryChang Can I create an image of the system on board now and copy the library to the image file . Then reflash the system with recovered image? Because I have some important data on my board, when I use partition update , I don’t know which part of usrdisk will lost.
hello 905122781,
you may try To clone a Jetson device and flash to back-up your filesystem partition.
then, you could mount this back-up image to your host machine and edit all necessary things. finally, repacked the image into a new system.img to flash APP partition.
please note that you should add -r options when you restore APP partition.
because this command option will skips building system.img and reuse the existing one to do image flashing.
for example, $ sudo ./flash.sh -r -k APP <board> mmcblk0p1
One possibility to consider is that you could clone the Jetson, put the file back in from the location @JerryChang mentions, and then flash with that repaired clone (knowing you can flash how he suggests, but using a custom image from a repaired system means you wouldn’t lose anything, but it does take a lot of time and a lot of disk space).
A clone creates both a “raw” image (the size of the entire partition, e.g., 28 GB is typical), plus a “sparse” image (depending on how full the filesystem is it could be anywhere from around 2 GB to the full partition size). Thus you could approach writing around 50 GB to the host PC (it takes a long time just to clone that, plus a long time to copy the clone, and then to flash it with that). A typical clone would be:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1
In that case “my_backup.img.raw” is the raw image, and “my_backup.img” is the sparse image. Sparse images are only good for flashing, and you need to edit, so I recommend delete “my_backup.img”. Once you edit “my_backup.img.raw” you could convert it to sparse for faster flashing, but it isn’t necessary if you don’t mind a slower flash. Typically you would put your repaired “my_backup.img.raw” in as:
Linux_for_Tegra/bootloader/system.img
And then flash:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
(use the exact same L4T flash software release as the system originally used)
Note that the “-r” says to reuse whatever “system.img” is there, and to not overwrite it with a fresh new image. If you wanted to limit this to just flash the rootfs, and to leave other content alone, then:
sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1
The “APP” partition label is the root filesystem. Note that in both of the above cases it says to “reuse” the rootfs, and that neither of those two cases uses “-G filename”. The “-G” is for cloning. I’m not positive, but in theory, if you flash only the rootfs using the “-k APP”, then probably it wouldn’t be necessary to use an exact match of flash software.
On your Linux host PC you can loopback mount the raw image for editing. Example:
sudo -s
mount -o loop ./my_backup.img.raw /mnt
cd /mnt/lib/aarch64-linux-gnu
ls -l libc.so*
Note that on the PC, in the “Linux_for_Tegra/rootfs/”, you will also have the original content (which might not be exactly correct now if it turns out you ran any kind of system update which updated libc, but the old version probably works). Note that “libc.so.6” is a very special file, and that directly or indirectly every single non-static program on the system uses this. The file name “libc.so.6” is most likely a symbolic link pointing at the hard link. Example on a rootfs from “rootfs/lib/aarch64-linux-gnu/”:
$ ls -l libc.so.6
lrwxrwxrwx 1 root root 12 Dec 7 2020 libc.so.6 -> libc-2.27.so*
In this case, *if and only if just the symbolic link is missing, but the hard link (libc-2.27.so) is present, you would not need to copy any files…you’d simply recreate the symbolic link:
sudo ln -s libc-2.27.so libc.so.6
However, if the hard link is missing, then you’d need to restore both the hard link and the symbolic link (you’d copy the hard file in, and then perform the same “ln -s” command).
Then you need to cd out of the loopback mount point (“/mnt” in the example), and end the loopback mount:
sudo umount /mnt
At this point you could copy “my_backup.img.raw” to “bootloader/system.img”, and flash as shown above. If you want to know how to make a sparse version of this file using mksparse (“0” fill pattern), then go ahead and say so, but if flashing it only once, then it probably isn’t worth your time. Copying around that huge file will take quite some time. It might be worthwhile keeping that raw image as a backup for future use if you have critical content on it. This would take quite some time, but to later reduce the backup for size you could “bzip2 -9 ./my_backup.img.raw” and this would reduce to about the same size as a sparse image (but it could be uncompressed and edited or updated with rsync).
1 Like
Hi@linuxdev @JerryChang Thanks for your kind reply. I decide to try to clone a image of the system on board. But now I meet with a new problem.
The terminal report “CPU Bootloader is not running on device”.“tegrarcm_v2 --isapplet"and"tegradevflash_v2 --iscpubl" have always been cycling. My host PC (not VM)is ubuntu18.04.4 . The “lsusb” command show that the host machine can detect NVIDIA Crop. How to deal with it?
hello 905122781,
please setup serial console and gather the complete UART logs for reference,
you may see-also Serial Console - NVIDIA Jetson TX2 - JetsonHacks for wiring.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.