This is really a question rather than a problem.

If you dd an image it 'preserves' the boot ability of that image, if you copy it it does not.
If you rsync a directory where an image might reside, it mirrors that directory but does it include boot ability?
If you archive the file or directory, with tar, does it preserve its bootable qualities?

fred.

All these tools, dd, rsync and tar, copy exactly what is in the image. If the "bootability" of that image is expressed by data inside the image, the bootability will be copied. If not, it won't.

For example, if you dd a bootable disk partition to a file, the boot flag will not be copied, since it is contained in the partition table, not the partition itself.

To be honest, I don't quite understand what scenarios you are alluding to:

The early stages of booting depend on data being located at exact disk addreses. Some of that data is typically located in "unallocated" space that follows the MBR. That data is not part of any filesystem and won't be seen by anything that copies files from the filesystem. Beyond that, need for preservation of absolute disk addresses depends on what boot loader is used. Simple boot loaders like lilo and syslinux use the absolute disk addresses of the kernel and initrd, and require that the physical location of those files not change. Copying with tar or rsync won't preserve that. More advanced boot loaders become filesystem-aware at an earlier stage, and can locate and look inside the filesystem for the files they need.

1 members found this post helpful.

Tar is Tape Archive.

It was and still is used to take file by file and put on tape.

It's use is more toward making backups of data not backups of system files or loaders.

Tar does not backup boot information. It isn't supposed to.

It copies the contents of filesystems (or parts of filesystems). It processes the directory tree - as such it has the capability of copying all data in a system (backing up /) unless some limits are placed on it.

Boot blocks, filesystem headers, even partitions are not copied. Only the data within files and directories.

To restore a tar archive you must first have a filesystem (either already existing, or using mkfs on a partition, then mounting that filesystem) BEFORE you can restore.

As an archive of files you can migrate data from one type of filesystem to another, which you cannot do with most other archive formats.

Thanks for replies.

Sorry, perhaps I should have been more clear. I was thinking of images that reside within a file system, such as, an iso, raw image, even an image of an alien file system type you might download for use on an Android device. My understanding is that dd does an exact copy of the original in a way a straight copy does not, or at least I have had more success moving images (.iso, .img, .image) with dd than with copy.
I take it that tarring or compressing does not offer any extra preservation.

Fred.

correct.
None - just the data contained within the files, the directory structure, and (depending on the filesystem) extra attributes/ACLs assigned to the files.

It's still not clear just what you have tried. To make a bootable device, you have to copy the image to the raw device, not to a filesystem on that device. There is simply no way to do that with tar or rsync. The most common tool for that is dd, but you can really accomplish the same thing with cp or even cat:All of the above will do the same thing. With dd there are options such as "bs=" to gain efficiency with a larger blocksize and others to copy just a portion of the data or place it somewhere other than the beginning of the device.

Tar is generally used with some compression. You may have seen tgz files.

Tar is a file by file copy of what you tell it to copy. It puts files in contiguous order end to end into a file. Not one byte or bit is changed.

Tar doesn't care what the file is.

so,
if I was to cp a tar archive containing a .img file, under normal circumstances, it would be an exact copy?
However, if I was to copy it to a fat32 pendrive and then copy it to ext4 file system it might be corrupted?
I have done the above and it was corrupted but when I dd the image separately (but within the archive, ie copy each bit separately and just dd the .img) it is ok.

Fred.

If you get copying errors... then you have a hardware problem.

The only thing limiting copies to a fat32 is the file size limit of 4GB. I would suggest any file less than 3GB should be fine. I've had problems with longer ones, but I think that is due the 4GB limit (maybe including the necessary metadata for storage).

There are tools for splitting large files into smaller ones, to retrieve the data, just use a "cat part1 part2 part 3...| tar -xf -", as the tar utility will only see a single input from the pipe.

1 members found this post helpful.

Tar archive doesn't care what file is in it. You don't even have to have files on a filesystem for it to work.

Tar is as old as dirt.


You'll have to explain exactly what you are doing. I don't get it.

It would seem the common factor was using the same pendrive, it is the same one I use to copy between computers. It seems so simple but would explain a lot. Not least because I needed to reformat it recently due to errors I thought were due to other things. Best to heave it into the long grass!

jefro,

I had extracted a tarball and was copying the contents to a directory to find out why the .img had failed so I copied the others and dd'd the .img, it succeeded. This might have just been luck.

Perhaps not the standard way to do it but I was looking for what had gone wrong with a straight forward copy.

Perhaps I should look again at what exactly tar does.

Tar just streams the input files one after the other with each preceded by a descriptive header that holds the original file name and other attributes. It's about a simple an archive format as you're going to find.

If compression is used, the whole stream is piped through a compressor without regard for the structure of the archive. You can run gunzip on a .tgz file, and the result will be an ordinary, uncompressed tar file.

Then my guess is there is a file integrity issue with this iso rather than the flash drive.

dd doesn't care what it copies. There is a switch for tar to not care but by default it cares. Try that option switch and see if it succeeds.

Guess it still could be any number or ram or other issues maybe even this drive. Guess some timing issue with how your usb connects and it's driver.