Hey everyone. I’ve been trying to flash the Jetson TK1 for the last week or so, but it always hangs during the actual flash. Right now it’s stuck in this mode. Here’s a [screenshotl][/https://imgur.com/a/7O0e7l].
Sometimes It gets through this and it starts looking for the IP (in rare situations) of the board, but can never find it even if I plug the jetson board directly into the the host computer or into a router. I’m completely lost as to what I should do at this point.
The URL [url]https://imgur.com/a/7O0e7l[/url] does not appear to be valid.
There are a number of things to think about, although usually there is not a hang. Preparing the image to be flashed involves creating a very large file (15GB), formatting that file, and populating it with an entire Linux distribution (this can be very slow). Then the file is compressed (the raw format file is used to create a sparse file), which takes some time as well. Having that screen shot would help, as it would show whether flash is still preparing the image or whether some form of communications with the Jetson has begun at the moment of hang.
The uncompressed file of about 15GB is “bootloader/system.img.raw”, the sparse file is “bootloader/system.img”. Verify those exist, and give the exact byte size of system.img.raw so we can see if it is valid (the raw file has exact rules for byte size, the sparse file varies since it is compressed). If the file system filled up and truncated this could be a reason for hanging.
Also, if the host is a VM and not an actual native Linux install, then there are often problems requiring some sort of adjustment on the VM. What is the exact host setup, and does it use an ext4 file system type?
I apologize for the late response. A hackathon I’ve been planning was this past weekend. But I’ve reuploaded the images and verified that they work. (Jetson tk1 setup issues - Album on Imgur). How can I verify those exist? Where is jetpack creating/unpacking it? What byte size should I be expecting?
I used the ‘mount’ command to figure out my file system type and got this in the first line: /dev/sda1 on / type ext4 (rw,errors=remount-ro)
There were plenty other options but I think that means I have an ext4 file system? Would you recommend I dualboot linux instead of messing with a virtual machine? Also I’m using virtual box if that helps
Error codes are listed here, but of course powering down on the Jetson side would be the cause (listing just in case anyone is curious):
[url]https://devtalk.nvidia.com/default/topic/831539/embedded-systems/now-unable-to-flash-jetson-tk1/post/4528073/#4528073[/url]
The fact that sometimes you make it to system.img starting to write, but at most other times do not, tends to imply some sort of hardware issue. The issue can be with the USB pipe, rather than being caused by the Jetson (if the failure is always at the same address, then I’d suspect the Jetson…since the failure location can vary, I suspect the host or USB pipe). This is typical of VMs, and has been solved by many users of VMs by switching to a real non-virtual Linux host, and sometimes by adjustments to drivers and USB parameters in the VM. I do believe that this would work properly if not using a VM for this case.
Thanks @linuxdev! It worked. But now I’m faced with a new problem…
A lot of problems are occurring now. I can’t ssh into the board, because some file settings are blocking port 22 from being accessed. I can’t use sudo to edit those settings because every time I try to use sudo, I get
sudo: unable to mkdir /var/lib/sudo/ubuntu
. To fix this, I have to edit some file settings, which brings me to the root of all my problems!
The filesystem is mounted in read-only mode and I can’t do anything to fix it as only sudo commands can solve the situation. I’ve looked into fsck but that needs sudo to work. What should I do? Why did it boot in read-only mode? By the way, I’ve verified that it has internet connection and I’ve verified that my other computers can ping it. But other than that I’m dead in the water.
It sounds like the sample rootfs used to create the loopback image (the image actually flashed) may have incorrect permissions, such as if the underlying file system is not a native Linux file system (e.g., ext4 works for where the sample rootfs is unpacked, but NTFS or VFAT would fail). If you ran flash.sh by hand you’d also need to run this with “sudo”.
A second possibility is that the generated image was truncated, which would occur if the host did not have enough disk space. Between the actual image and the compressed image and temporary files you need a minimum of about 20GB of extra disk space prior to starting the flash (if you have an old “bootloader/system.img.raw” and “system.img” you could delete those to determine how much space you have available).
FYI, “df -H -T” will list your partitions type and how much space is available. Check to see if you used ext4 and had enough disk space.
So I did “df -H -T” and it says I’ve only used 2.3gb of /dev/root
But I can’t find bootloader/system.img.raw or system.raw …
Also I didn’t flash by hand. I flashed using the JetPack. I went out and bought an SD card with 32 gb of space. Can I flash it there easily so it’ll have enough space?
Here are some pictures so maybe you’ll see something I don’t
I tried following this
but the I can’t edit that file because it’s all in read only mode. I’m really lost as what to do. I reflashed using that command and I’m still stuck in the same place
EDIT: I tried to do “mount -o remount,rw /” with sudo and got this message
[ 1002.291288] EXT-fs error (device mmvblk0p1): ext4_remount: ext4_remount:460: Abort forced by user
mount: cannot remount block device /dev/root/ read-write, is write-protected
It looks like the “df -H -T” was from the Jetson. What is the full output of “df -H -T” when you are in the host’s “rootfs” subdirectory (where the flash software is installed there will be “Linux_for_Tegra/rootfs”? The type of host file system is rather important, it isn’t just about space. If the host uses the wrong file system type then there is no possibility of preserving permissions (non-Linux file systems do not understand Linux permissions and as such those permissions default to something invalid…which is one way to break sudo). Is the underlying host file system type ext4 at the point where “Linux_for_Tegra/rootfs/” exists?
Btw, I’d try to just flash without JetPack. You’d unpack the sample rootfs into the rootfs directory using sudo (and be sure that directory is ext4), then back out one directory and use sudo to run “./apply_binaries.sh”. Following this, if the Jetson is in recovery mode:
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
Once the flash works you could build an SD card alternate root from this and point extlinux.conf at that SD card.
Also, any “bootloader/system.img” or “bootloader/system.img.raw” are on the host side as a subdirectory of Linux_for_Tegra. The flash.sh script will create these each time you flash (unless you explicitly tell it to re-use what already exists).
What I have found is that I had to pass the correct cfg file for the memory to the flash utility in order to get past that point, this command is for a port of the tk1 but uses all the same packages to flash. I am using CEI TK1-SOM as opposed to the jetson tk1. The scripts used for the CEI TK1 is directly taken from NVIDIA’a Jetson TK1 package. Give it a try.
sudo env ROOTFS_TYPE=ext3 ./flash.sh -b /home/ghost/Desktop/ColoradoBoard/bsp/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_T124_Hynix_4GB_H5TC8G63AMR_PBA_792Mhz.cfg -L bootloader/ardbeg/u-boot.bin tk1-som mmcblk0p1