I am trying to backup my system that is running on emmc memory on my embedded device. The problem is that I keep getting input/output errors when trying. I have tried at 4M, 1M, and 64K, but still getting them. is this normal?

dd if=/dev/nbd1 conv=sync,noerror bs=64K |
   gzip -c  >
  • \$\begingroup\$ are you a) sure that /dev/nbd isn't damaged and b) that there are no "black holes" in the memory layout of the underlying storage device (which might very well be an MTD device, not a block device, see linux-mtd.infradead.org/faq/general.html) \$\endgroup\$ Commented Feb 15, 2017 at 8:16
  • \$\begingroup\$ WAAAAAIT. NBD is Network Block Device. You're definitely not backing up your EMMC, but something you've mounted via network \$\endgroup\$ Commented Feb 15, 2017 at 8:22
  • \$\begingroup\$ EMMC storage has a limited number of write cycles. Typically you'd write your bootable OS image to it and only ever use it in read only mode from that point onwards. For developent purposes it's probably a good idea to boot from a USB stick instead if you board supports it. \$\endgroup\$
    – user98663
    Commented Feb 15, 2017 at 8:25
  • 1
    \$\begingroup\$ @MarcusMüller, well not always. Many embedded systems (such as ones from the TS-4712 family) have one NBD device on the same PCB as the CPU and it is indeed the eMMC. I think Beaglebone Black devices have this arrangement too. \$\endgroup\$
    – user98663
    Commented Feb 15, 2017 at 8:30
  • \$\begingroup\$ OP might want to specify what /dev/nbd1 is! \$\endgroup\$ Commented Feb 15, 2017 at 19:07

2 Answers 2

dd if=/dev/nbd1 …

/dev/ndbX is a Network Block Device. You're not backing up your EMMC, but something you've mounted via network; I'm almost sure that's not what you want to do.

I presume this means you run an NBD daemon on the embedded device, and mounted the shared volume on your PC. That is a possible approach, but I'd really just go for ncat here; run

ncat -l … > backup_image.img

on your PC, and

ncat … < /dev/mmblk0

on your embedded system (assuming mmblk0 is your EMMC).

Note: Many embedded systems do not run off self-managing flash devices that offer a block device interface such as MMC/SD cards/USB flash drives/SATA SSDs, but off raw flash ICs. These are NOT block devices (but MTDs) and don't offer a contiguous access method. Backing these up as physical layout to a file is hence (logically) not possible. Backing up the contents is.

If you'd try to export your MTD using a NBD daemon, things will go very wrong.

  • \$\begingroup\$ I stand corrected :) \$\endgroup\$
    – user98663
    Commented Feb 15, 2017 at 10:36
  • \$\begingroup\$ about what? I just saw your Beaglebone/NBD comment, and I plainly didn't know that, and it seems reasonable \$\endgroup\$ Commented Feb 15, 2017 at 19:06
  • \$\begingroup\$ Hmmm....not sure how to answer that. I am using this board: link It has the ability to run from emmc or from an sd card. The emmc is emmc /dev/nbd1 sdcard /dev/nbd0 It is actually running busybox on the embedded device. Also, the busybox I have, doesn't include the ncat command, so I am thinking this is a different case. \$\endgroup\$
    – wegunterjr
    Commented Feb 15, 2017 at 21:53
  • \$\begingroup\$ hm, I just skimmed through sdctl.c of your board's manufacturer. It looks like this might actually be a network thing. Anyway, I strongly think you should ask Technologic Systems about this. Might simply be an issue with their software. \$\endgroup\$ Commented Feb 16, 2017 at 9:37

You are almost there, but blocksize is only part of the equation.

The trouble here is that the nbd generally has no idea how big it is, so using dd as the example displays will happily try marching right off the end of the device and produce an I/O error. On Technologic Systems devices using sdctl, a nbd is generally pointed at a local eMMC, SD, or other local storage resource.

One thing you can do to confirm this is what happened on TS hardware is to run a couple diagnostic commands with sdctl. You will probably see something like this:

# sdctl --stats
# sdctl --dmesg
Jan  1 01:38:57 Access beyond EOF, sec=3776488, len=256, req=0
Jan  1 01:38:57 Access beyond EOF, sec=3776744, len=256, req=0
Jan  1 01:38:57 Access beyond EOF, sec=3776504, len=8, req=0

The way to avoid the I/O (ran past EOF) error is to always give your dd a constraint when dealing with nbd-using storage drivers, such as:

dd if=/dev/nbd1 of=/my/backup.dd bs=1M count=1024 conv=fsync

By providing a count of the blocks you want to read, you can avoid falling off the edge of your media. Blocksize and count can be almost anything, so long as bs*count <= actual media size.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.