fails with no space left on device while creating image

I’ve updated the DeviceTree and am trying to create a new SD card image. I’ve performed the following steps:

  1. Updated the device tree files
  2. Re-build the kernel using the following commands:
export CROSS_COMPILE=${NVGCC}/bin/aarch64-linux-gnu-
make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8
  1. This appears to update the DTB file located <SDK_install_directory>/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader

  2. I then ran (not really sure what this does)

  3. I then ran

sudo ./ -o sd-blob.img -s 16G -r 200

This runs for a while and then prints out the following messages towards the end:

EALLY setting name!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully. - write partitions - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/nvtboot_cpu.bin.encrypt
127+1 records in
127+1 records out
65504 bytes (66 kB, 64 KiB) copied, 0.0265649 s, 2.5 MB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/tegra210-p3448-0000-p3449-0000-a02.dtb.encrypt
395+1 records in
395+1 records out
202592 bytes (203 kB, 198 KiB) copied, 0.0277523 s, 7.3 MB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/cboot.bin.encrypt
964+1 records in
964+1 records out
493632 bytes (494 kB, 482 KiB) copied, 0.0396792 s, 12.4 MB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/warmboot.bin.encrypt
7+1 records in
7+1 records out
3952 bytes (4.0 kB, 3.9 KiB) copied, 0.0324017 s, 122 kB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/sc7entry-firmware.bin.encrypt
6+1 records in
6+1 records out
3344 bytes (3.3 kB, 3.3 KiB) copied, 0.0205323 s, 163 kB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/tos-mon-only.img.encrypt
105+1 records in
105+1 records out
54208 bytes (54 kB, 53 KiB) copied, 0.0346139 s, 1.6 MB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/eks.img
2+1 records in
2+1 records out
1028 bytes (1.0 kB, 1.0 KiB) copied, 0.0277207 s, 37.1 kB/s - writing /home/nlbutts/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3448/Linux_for_Tegra/bootloader/signed/boot.img.encrypt
dd: writing to '/dev/loop0p9': No space left on device
1281+0 records in
1280+0 records out
655360 bytes (655 kB, 640 KiB) copied, 0.0210966 s, 31.1 MB/s
umount: /tmp/tmp.g2BETj5kbD: not mounted

I should have plenty of room to create this image. Any ideas?

For some reason, my boot.img is 34 MB, the only allocates 655360 bytes for that partition.

Somewhere along the line some script grew the boot.img. I can’t find what would create that image. appears to take the zImage and Image and puts them into the rootfs. But I can’t find what creates the boot.img.

Has anyone else seen this problem?

hello Shadowmind,

the script file generate the system image as a blob and save locally.
could you please run below commands to check if “–no-flash” options works.

$ sudo ./ --no-flash jetson-nano-qspi-sd mmcblk0p1

I can’t run this because I can’t get the Jetson LT4 installed. I removed everything and started with a clean slate, but now when I try and reinstall everything through the SDK Manager I get the following error messages:

09:15:25 ERROR : Drivers for Jetson Nano :
09:15:25 ERROR : Drivers for Jetson Nano : tar: Unexpected EOF in archive
09:15:25 ERROR : Drivers for Jetson Nano : NV_L4T_DRIVERS_NANO_COMP command /tmp/ finished with error
09:15:25 ERROR : Drivers for Jetson Nano : command terminated with error
09:28:01 ERROR : Drivers for Jetson Nano :
09:28:01 ERROR : Drivers for Jetson Nano : tar: Unexpected EOF in archive
09:28:01 ERROR : Drivers for Jetson Nano : NV_L4T_DRIVERS_NANO_COMP command /tmp/ finished with error
09:28:01 ERROR : Drivers for Jetson Nano : command terminated with error

You might be running into an Ubuntu bzip2 update bug. Haven’t verified it myself, but take a look here in case this is the issue:


I don’t want to reopen this issue, but just share my experience.
I’m preparing a Jetson Nano SD card image inside a ubuntu18.04 docker container.
I download all the packages via sdkmanager cmdline and run inside it.
This is working fine.
But, when I run

tools/ -o sd-blob-b01.img -b jetson-nano -r 300

I get the following error:

dd: writing to '/dev/loopXp1': No space left on device

I run the container with --privileged.
I don’t know why (my host is running an up to date ubuntu 18.04 too), but “losetup -f -P” inside the script is not showing correct size when I do gdisk -l /dev/loop20p1, it’s something like 62MB instead of 4.7GB.

So my solution has been to patch the script with:
losetup -f instead of losetup -f -P
and use kpartx -a that will map the partitions to /dev/mapper/loopXpY
and kpartx -d /dev/loopX before losetup -d /dev/loopX

This solution is working inside my docker container and I can generate an image that is working fine on my jetson nano devkit.

Running on my host directly is working fine without any patch.

Here is my simple Dockerfile for people who are interested:

FROM ubuntu:18.04

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        pigz \
        lbzip2 \
        python \
        gdisk \
        sudo \
        kpartx \
        patch \
        zip \
        qemu-user-static && \
    # Cleanup
    rm -rf /var/lib/apt/lists/* && \
    rm -rf /var/log/* && \
    rm -rf /var/tmp/* && \
    rm -rf /var/cache/apt/archives/*.deb && \
    rm -rf /tmp/*
RUN useradd -m docker && echo "docker:docker" | chpasswd && usermod -aG sudo docker
RUN echo 'docker ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

USER docker
CMD /bin/bash

“I am not a docker guy”, but once the image is covered by loopback (using the “-P”) you might want to run “lsblk -f” and see what it thinks of the device as a whole.

@tvai @Shadowmind

/dev is out of space

check by

df -h

you can increase /dev tmpfs by command for example:

mount -o remount,size=2G /dev