I have an TI DaVinci-based (ARM architecture kin to OMAP) system which netboots using TFTP and NFS-mounted root filesystem, and am trying to make it boot standalone without a netboot server.

The basic approach is to copy the kernel image to the NAND flash and the root filesystem to a connected SATA disk (NAND flash is nowhere near big enough for the whole system), then configure u-boot to load the kernel from NAND flash and pass an appropriate root= argument.

I'm stuck on the step of copying the filesystem. This question is relevant, but none of the recommendations work because I have only busybox versions of the cp and cpio tools, and the --one-file-system option is unsupported by busybox.

How can I clone the root filesystem when I only have the tool capabilities provided by busybox? Would it help to run archive creation commands on the NFS server (x64 architecture running Ubuntu) and then unpack on the target?

  • When you say "clone" do you mean the entire drive or just the data on it from a filesystem perspective?
    – slm
    Jul 30 '13 at 20:01
  • @slm: I mean that I get all the files and special files, so the result can be used as a root filesystem. There isn't really any concept of entire drive here, because the existing filesystem is mounted on NFS, so its physical representation is as a subset of a filesystem and partition on the NFS server.
    – Ben Voigt
    Jul 30 '13 at 20:03

BusyBox's find supports the -xdev option, so you can make a cpio archive of the root filesystem that way. Unlike tar, cpio does not archive a directory's contents when it archives that directory.

find . -xdev | cpio -H newc -o |
{ cd /mnt && cpio -m -i; }

I don't quite understand why you're building the image from a device though. I'd expect to build a filesystem image using your build scripts on a development machine, and deploy that image.

  • The problem with find+cpio under busybox isn't find, it's cpio, which is badly hobbled. "Extract or list files from a cpio archive". No options to create an archive or pass-through. I have customizations of an image originally built by others. But yes, making a disk image from the NFS server turned out to be much easier.
    – Ben Voigt
    Jul 31 '13 at 13:29
  • @BenVoigt Oh. BusyBox cpio can build archives, but like almost everything in BusyBox it's an optional feature, which apparently wasn't turned on in your build. In any case I do think building the image on the server is the better solution for your scenario. Jul 31 '13 at 15:50
  • Still, yours is the correct answer to the question I asked, which is how to copy a root filesystem using busybox without descending into mountpoints, even thought it wasn't what I actually ended up doing.
    – Ben Voigt
    Jul 31 '13 at 16:07

I'd think you'd be able to do what you want using cp. From the busybox.net website:


           or: cp [OPTION]... SOURCE... DIRECTORY

Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.


            -a      Same as -dpR
            -d      Preserve links
            -p      Preserve file attributes if possible
            -R      Copy directories recursively


$ cp -a / /mnt/newroot


If cp can't handle any devices such as /dev/zero which I'm pretty sure it can't you might be able to use tar which is also included with BusyBox.

$ (cd /; tar cf - .)|(cd /mnt/newroot; tar pxvf -)
  • Mounting is not a problem. The NFS share is mounted, I am currently using it as the root filesystem. I want to migrate (non-destructively to the NFS share) the entire content of / to a local SATA disk and begin using it as the root filesystem instead of the NFS share.
    – Ben Voigt
    Jul 30 '13 at 20:10
  • @BenVoigt - why can't you use cp -a? This does a cp -dpR.
    – slm
    Jul 30 '13 at 20:13
  • I'm not sure if that handles special files correctly. The cp commands I see offered as solutions usually involve -ax options, and -x is not supported by busybox cp.
    – Ben Voigt
    Jul 30 '13 at 20:14
  • Working on it. In your new answer though, you're copying into the root, and I want to copy from / to a newly initialized filesystem at /mnt/newroot. But regardless of the mountpoint for the source, I expect problems from e.g. /nfs/mnt/share/dev/zero. Will -p cause creation of a special file instead of opening dev/zero and reading its (infinite) content? Having /sys and /mnt/newroot mountpoints in the source tree also seems problematic.
    – Ben Voigt
    Jul 30 '13 at 20:22
  • I think you could use tar to do this: (cd /; tar cf - .)|(cd /mnt/newroot; tar pxvf -) I always forget about this trick, had to think for a sec to recall it.
    – slm
    Jul 30 '13 at 20:26

It seems that using busybox-crippled tools for this is far more trouble than it's worth, because single-filesystem processing really is needed for this and it's missing from busybox cp. Possibly find could be used to copy files individually and avoid recursing into mountpoints, but that would involve a lot of individual processes and be very slow.

Preparing the filesystem on the NFS server is a much more viable alternative. Calculate the partition size in bytes using fdisk -l, then

truncate -s N the-root-image
mkf.ext3 the-root-image
sudo mount -o loop the-root-image /mnt/somewhere

Now copy the content using this command found in the linked question

sudo rsync --archive --inplace --hard-links --acls --xattrs --devices --specials --one-file-system --8-bit-output --human-readable --progress path/to/nfs/share /mnt/somewhere

Put the image in a network location where the target can access it:

sudo umount /mnt/somewhere
mv the-root-image path/to/nfs/share

Finally, from the target place the image onto the destination disk

dd if=/the-root-image of=/dev/sda1 bs=16M

You should mount (or bind mount) to some directory :

mount /dev/mmcblk0p1 /mnt
cd /mnt
tar cjf /otherdisk/archive.tar.bz2 *

You can also send the result by ssh (if enabled in your busybox config) instead of storing locally, and by the way use the target host computing power/installed tools to perform compression :

tar cf - * | ssh user@host "bzip2 | cat > archive.tar.bz2"

Adapt compression tool, archive name and so on to your wishes :)

  • Yes, it seems like I should have used mount / /mnt/srcsystem -o bind and that would have had the single-filesystem effect because "Note that when you mount a filesystem somewhere else, any filesystems that were mounted to mount points inside the bind-mounted filesystem will not be moved along"
    – Ben Voigt
    Oct 16 '19 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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