1
\$\begingroup\$

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  >
      /mnt/usbdrive/backup_image.img.gz
\$\endgroup\$
  • \$\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\$ – Marcus Müller Feb 15 '17 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\$ – Marcus Müller Feb 15 '17 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\$ – Wossname Feb 15 '17 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\$ – Wossname Feb 15 '17 at 8:30
  • \$\begingroup\$ OP might want to specify what /dev/nbd1 is! \$\endgroup\$ – Marcus Müller Feb 15 '17 at 19:07
2
\$\begingroup\$
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.

\$\endgroup\$
  • \$\begingroup\$ I stand corrected :) \$\endgroup\$ – Wossname Feb 15 '17 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\$ – Marcus Müller Feb 15 '17 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 Feb 15 '17 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\$ – Marcus Müller Feb 16 '17 at 9:37
0
\$\begingroup\$

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
...
nbd_seek_past_eof_errs=3
...
# 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.

\$\endgroup\$

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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