Flashing R19.3: mapping system.img to loop device failed.

Not sure if there is a jetson support email, all I could see was CUDA. I’d successfully flashed a new kernel in R19.2 jetson, and decided to flash R19.3 as a whole (not just a kernel). I ended up with this after a few attempts (since none of the attempts worked):

R19.3/Linux_for_Tegra# ./flash.sh -S 15GiB jetson-tk1 mmcblk0p1
copying dtbfile(/home/dan/Documents/embedded/L4T/R19.3/Linux_for_Tegra/kernel/dtb/tegra124-pm375.dtb) to tegra124-pm375.dtb... done.
Making system.img... /home/dan/Documents/embedded/L4T/R19.3/Linux_for_Tegra/rootfs 16106127360
mapping system.img to loop device failed.

One attempt used the u-boot option, another without any size (no -S). So far, no listings found for mapping system.img failure. Is there an L4T/jetson support email at nVidia, or does the CUDA one handle L4T/jetson?

I invoked the following to simultaneously flash 19.3 and U-Boot:

sudo ./flash.sh –L bootloader/ardbeg/u-boot.bin -S 8GiB jetson-tk1 mmcblk0p1

Seems to have worked. :)

./flash.sh -S 15GiB jetson-tk1 mmcblk0p1

-S 15GiB is an overkill. -S 14580MiB is the most we can have.

mapping system.img to loop device failed.

Check with flash.sh code. I used to receive this error message on Fedora 19 build host until I realised that Fedora doesn’t like losetup command. I’ve created loopback0:0 device manually, as a work around

I rearranged so the -S and -L are prior to jetson-tk1 and mmcblk0p1. Results remain the same. I’ve also tried this with the fastboot.bin, no change. And I’ve rebooted and tried from a fresh boot in case it was something related to using too many loop devices. No change.

I have noticed that “mapping system.img to loop device failed” is part of the flash.sh script, and in particular it is using losetup on /dev/loop0 to access system.img. What it is really saying is that my loopback is failing. I do have losetup on the system, and I have no reason to believe loopback was disabled. However, most people are using ubuntu, I’m using fedora 19.

Perhaps loopback itself needs some kind of setup? If I run losetup manually, it tells me /dev/loop0 does not exist. Indeed, looking in /dev/ a recursive find shows only /dev/loop-control. Right now I’m trying to investigate why my fedora 19 differs from older losetup (it has been a long time since using losetup, it appears that the syntax and setup has changed…I’m suspicious that it is a udev thing).

For those who succeeded in flashing to R19.3, what do you get from “ls /dev/loop*”? What linux distribution are you using?

1 Like

BINGO! flash.sh, line 284 is incorrect for some distros.

Ok, I have not actually used this yet for flash, but syntax in flash.sh is indeed incorrect for fedora 19. The proper command is now:


losetup --find --show system.img


<s>losetup /dev/loop0 system.img > /dev/null 2>&1</s>

The --show is for my own test use, it lists it as /dev/loop0…but without --find it never has a loop0. The loop devices seem to now be dynamically generated (again, I’m not positive, but this seems like it is something done for udev). I’ll modify the flash.sh this weekend and post if it works. Manual creation of the loopback works and creates a new /dev/loop# as needed. Script to be adapted.

But, word of warning: Before running flash.sh for anything other than just kernel (I’ve previously kernel flashed with no issues on fedora 19) make sure you have a /dev/loop0. The old style flash.sh losetup script is manually enumerating this, and it may not exist on your system…jetson will no longer be bootable.

1 Like

Just an update for a temporary workaround which was successful, along with a note on flash.sh.

On my fedora 19 system, which by default never has /dev/loop0 (required during flash.sh installation of R19.3), manually creating /dev/loop0 will work (until reboot):

losetup --find

Once that command has been issued to find the first unused loopback device, /dev/loop0 should exist. Once loop0 exists, installation of R19.3 can be completed.

For those that have been through flash once, you will find in the boot loader section a file which is equal in size to the -S size option: system.img. This file is formatted and accessed under loopback. Once created, you can use this again and save time if you re-use via the -r option to flash.sh. If you want to save disk space on the host, you can delete this file after install. It is plausible that disk space of an entire install might be an issue for some people…the resources of the file plus whatever loopback coverage requires is significant. Should you want to re-use this, you might also consider compressing the file between uses.

Another side note: Using -S 15GiB exceeded eMMC capacity. Using -S 14GiB worked.

1 Like

By the way thanks a lot linuxdev! I was having problems with the flashing of my Jetson TK1 and I found this thread.

losetup --find --show system.img

It printed /dev/loop1, so I changed all of the /dev/loop0 to /dev/loop1 in flash.sh and now the system is back and running perfectly. Thanks a lot!

1 Like

There’s a good chance the next L4T release will directly use the “–find” option…then it’ll be too easy!

1 Like

Trying to reflash jetson tk1 from Fedora linux WS. Always get a “USB Device not found” (indeed, not present even in lsusb):

[CdAB@localhost Linux_for_Tegra]$ lsusb Bus 002 Device 003: ID 0a5c:219c Broadcom Corp. Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 2232:1008 Silicon Motion Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Just posting output (just noticed that GPT parameters has a “Target Device Name: none”:

sudo ./flash.sh –L bootloader/ardbeg/u-boot.bin jetson-tk1 mmcblk0p1


*** GPT Parameters ***
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
sector size -------------- 4096
Partition Config file ---- flash.cfg
Visible partition flag — GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[ BCT] BH 0 16383 8.0MiB
[ PPT] UH 0 4095 2.0MiB ppt.img
[ PT] UH 4096 8191 2.0MiB
[ EBT] UH 8192 16383 4.0MiB u-boot.bin
[ LNX] UH 16384 49151 16.0MiB
[ SOS] UH 49152 61439 6.0MiB
[ NVC] UH 61440 65535 2.0MiB
[ MPB] UH 65536 77823 6.0MiB
[ MBP] UH 77824 90111 6.0MiB
[ GP1] UH 90112 94207 2.0MiB
[ APP] UV 94208 29454335 14336.0MiB system.img
[ DTB] UV 29454336 29462527 4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[ EFI] UV 29462528 29593599 64.0MiB
[ USP] UV 29593600 29601791 4.0MiB
[ TP1] UV 29601792 29609983 4.0MiB
[ TP2] UV 29609984 29618175 4.0MiB
[ TP3] UV 29618176 29626367 4.0MiB
[ WB0] UV 29626368 29630463 2.0MiB
[ UDA] UV 29630464 30773247 558.0MiB
[ GPT] UH 30773248 30777343 2.0MiB gpt.img
copying flasher(/home/CdAB/Downloads/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)… done.
Existing flashapp(/home/CdAB/Downloads/Linux_for_Tegra/bootloader/nvflash) reused.
*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
USB device not found
Failed flashing ardbeg.

What comes to mind is that the right type of USB cable has to be used, plus Jetson must be in recovery mode. The mini USB cable provided allows Jetson to become a “device” instead of a “host” because of its connector type (going to an A/B socket). Next, the Jetson must be started with the recovery button held down (before flashing software is started). Is this the case? If all of this is correct then you may have a genuine failure of some sort.

1 Like

Great !
Also this problem that mapping system.img to loop device failed can also happen even if you’ve changed the line 284 of flash.sh and the case is that the loop device (/dev/loop0) is being used by your own host machine and the flash script is unable to unmount what ever is inside the loop device (/dev/loop0) to be able to use it !!

So if this happened you have also two other Solutions :
1 : Reboot your host machine and try flashing again !
2 : Change flash.sh in a way to be able to find a free loop device to work with :
Find this line in flash.sh :
local loop_dev="/dev/loop0"
Change it like this :
local loop_dev=$(losetup --find)

This will make it to be able to set the loop_dev to a free loop device !
Thanks everybody and my Dear friend @linuxdev with the best answers !