Hello,
I’ve been running into the issue since last week where I get an error “The manifest file is broken” when I try to install JetPack 3.3 onto a Jetson TX2i with an Ubuntu 1604 laptop. I tried the following without success:
Reinstalled the Jetpack 3.3
I tried it on Ubuntu 18
Different networks, so proxy and/or a firewall should not be a problem
Now my course of action is to try and upgrade the JetPack to 3.3.4 or newer via the SDKManager (v2.0.0.11402). Upgrading however has not been that successful.
The installation of the Jetpack 3.3.4 OS image for my Jetson TX2i works (with an error I will mention below) but the SDK components don’t. I can see it boot up the Ubuntu OS on a screen that is connected via HDMI. But from here I run into a lot of connection issues. I cannot access Jetson since keyboard/mouse inputs do not work (I tried different peripherals). We use a custom mainboard on which we mount the Jetson which might be part of the problem (this was no issue with the Jetpack 3.3). Trying SSH also hasn’t been successful when I set a static IP or when using the DHCP of the Ubuntu host. The laptop is broadcasting but the Jetson doesn’t seem to grab the IP.
I didn’t save the logging for the successful flash but this error always popped up.
Nvidia jetson ERROR: flash Jetson tx2i - flash: board ID(3489) version(301).
So now I’m a bit stuck and my plan is to try the newest available Jetpack 4.6.1, but any help on the manifest file error or the connection issues with Jetpack 3.3.4 would be greatly appreciated.
I flashed Jetpack 4.6.4 with the nvidia sdk manager and got the following errors:
11:20:59 INFO: Flash Jetson TX2 - flash: [ 8.5996 ] Applet version 01.00.0000
11:20:59 ERROR: Flash Jetson TX2 - flash: File “/usr/lib/python3.6/cmd.py”, line 217, in onecmd
11:20:59 ERROR: Flash Jetson TX2 - flash: UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xa4 in position 6: invalid start byte
11:20:59 ERROR: Flash Jetson TX2 - flash: command terminated with error 11:20:59 SUMMARY: Flash Jetson TX2 - flash: First Error: Installation failed.
Couldn’t find a fix that worked so I tried flashing by running flasher.sh script of jetpack 4.6.4 directory
sudo ./flash.sh -r jetson-tx2i mmcblk0p1
From there the flashing was successful and it boots up into Ubuntu. Then again I run into the same issue as mentioned with the Jetpack 3.3.4 where peripherals don’t work and I can’t SSH into it. But I guess this version of JetPack doesn’t work for some reason with our custom board.
Well, that’s expected.
The default BSP is only meant to work with DevKits from NVIDIA.
If you are making your own custom carrier boards, then you should know how to play with stuff like device tree and pinmux.
Incidentally, if you go to the host PC’s “Linux_for_Tegra/” directory, and examine this: ls -l *.conf
…then what you’ll find is that all available flash targets are just those files without the “.conf” extension. The ones which start with “jetson-” are just symbolic links/aliases for the ones named after module and carrier board (technical names, versus more human naming). These are human readable, and often are modular in the sense of using include statements for subcomponents. If you have a custom target, then you could start with the .conf which matches this most closely, and copy it, then edit the copy where it differs; you can leave the include statement for parts which are the same. Then your new target would be named directly on a command line flash and it would contain your customizations so far as target specs go.
I managed to build a complete Jetson with a custom device tree and software where everything worked successful. However after making a copy of the APP partition and copying it over to a new Jetson I still run into a kernel panic issue on boot.
I don’t know if this is the case, but long ago (during the days of 28.x?) the 64-bit extensions for ext4 could not be used on the rootfs. The host PC which creates that rootfs has default options in “/etc/mke2fs.conf”, and also did not use the 64-bit extensions. Then, when people started using a newer Linux host PC release, the 64-bit extensions started showing up in “/etc/mke2fs.conf”. This resulted in flash without error, but boot failed. If you’ve gone far enough back in time with this older release, but still use a newer host PC release, then it is quite possible you’re running into the ext4 64-bit extensions.
You could temporarily change the options for default ext4 to not use those extensions, or you could modify your flash.sh file to name only non-64-bit options (this latter is probably preferred). Are you using command line flash.sh for flashing?
Assuming you are using flash.sh, then you could find the line which is similar to: mkfs -t ${__rootfs_type} "${loop_dev}" > /dev/null 2>&1;
You could then modify it (if not the problem, then this won’t help, and you should revert). Older mkfs might have different options or syntax, but I’m guessing it’ll be something like this: mkfs -t ${__rootfs_type} "${loop_dev}" -O ^metadata_csum,^64bit > /dev/null 2>&1;
The above says to not use metadata_csum, nor 64bit. If you look inside of “/etc/mke2fs.conf”, then you can find a block for “ext4 = {...}”, and within that, the two features you would remove (temporarily while testing) are “metadata_csum” and “64bit”. If you flash with those removed, then those features won’t be there by default. The possible edit I gave for flash.sh uses the “-O ...” to remove those features.
This of course might not be what is going on, but R28.x is so old I would not be surprised if this is from the days when desktop had transitioned fully to 64-bit ext4, but prior to the Jetson boot code being able to handle that.
After a bit of testing I managed to find the problem. Using the backup_APP_parition.img created with sudo ./flash.sh -r -k APP -G APP_CUSTOM.img jetson-tx2i mmcblk0p1 does not work for some reason.
In order to copy the rootfs I used the backup.img.raw and mounted it so that I could access all the directories. I copied this into my Linux_for_Tegra directory that I built with the Linux packages that I mentioned in an earlier post.
sudo -s
mount -o loop backup.img.raw /mnt
# copy over the directories to a clean tegra_for_linux/rootfs folder (WITH sudo because of apply_binaries.sh)
umount /mnt
Next up I performed a sudo ./apply_binaries.sh to apply the tegra binaries to my custom rootfs. After this I flashed the jetson like normal sudo ./flash.sh -r jetson-tx2i mmcblk0p1. For me as a final step I installed my custom device-tree for the connectorboard I use with the Jetson.
I tried out the steps from the reply above this one and for me they did not work. I still want to thank you @linuxdev for commenting not only on my post but also on others because all of these snippets of info helped me a lot with creating a solution.