It's because you're doing it wrong.
You're using bs=1M but reading from stdin, pipe, will have smaller reads. In fact, according to dd, you didn't get a single full read.
And then you have conv=sync which complements incomplete reads with zeroes.
0+15281 records in
15280+0 records out
dd received 0 full and 15281 incomplete reads, and wrote 15280 full ...
If it was a hard-drive image with a MBR partition table, I would fdisk the image to find the offset for the partition I need to mount.
fdisk -lu /path/disk.img
Then I would mount it passing the offset.
mount -o loop,offset=xxxx /path/disk.img /mnt/disk.img.partition
The offset value is in bytes, whereas fdisk shows a block count, so you should multiply ...
The -drive option takes parameters that look like this:
qemu-system-x86_64 -drive format=raw,file=x86-64.img
... you need to use commas between its "sub"-options, not spaces.
For example, here is one I tested to boot a Debian Installer CD:
qemu-system-x86_64 -drive format=raw,media=cdrom,readonly,file=debian-8.2.0-amd64-DVD-1.iso
How is that? Shouldn't gzip manage to compress all those zeros?
Yes, if they were zeroes.
Unused disk space does not mean it contains zeros; it means it is unused, and may contain anything.
There are programs that wipe unused disk space to zeroes. I suggest you use those before making the disk image. (I don't recall any offhand; in Linux, I'd just use dd ...
On most modern GNU system the mount command can handle that:
mount -o loop file.iso /mnt/dir
to unmount you can just use the umount command
If your OS doesn't have this option you can create a loop device:
losetup -f # this will print the first available loop device ex:/dev/loop0
losetup /dev/loop0 /path/file.iso #associate loop0 with ...
All of the following commands are equivalent. They read the bytes of the CD /dev/sr0 and write them to a file called image.iso.
cat /dev/sr0 >image.iso
cat </dev/sr0 >image.iso
tee </dev/sr0 >image.iso
dd </dev/sr0 >image.iso
dd if=/dev/cdrom of=image.iso
pv </dev/sr0 >image.iso
cp /dev/sr0 image.iso
tail -c +1 /dev/sr0 >image....
You can access the disk image and its individual partitions via the loopback feature. You have already discovered that some disk utilities will operate (reasonably) happily on disk images. However, mkfs is not one of them (but strangely mount is).
Here is output from fdisk -lu binary.img:
Disk binary.img: 400 MiB, 419430400 bytes, 819200 sectors
In general it is not safe. The FS assumes that operations are written in certain order so it can write new data of file and then make a pointer to it from other data, the exact details depend on filesystem. Imagine if following happens:
dd reads from location X which contains garbage or some data
Filesystem writes to location X
Filesystem writes to location ...
Since you haven't shut down the VM, then the process using that image file still has the file open and it hasn't actually been deleted yet. As long as the process keeps running, you should be able to recover it.
For this answer I have a kvm image called testdelete. The VM is up, but I have deleted the file.
First you need to find the process using the ...
So recently I wanted to do this with tar. Some investigation indicated to me that it was more than a little nonsensical that I couldn't. I did come up with this weird split --filter="cat >file; tar -r ..." thing, but, well, it was terribly slow. And the more I read about tar the more nonsensical it seemed.
You see, tar is just a concatenated list of ...
You could pipe through SSH. Example using dd:
dd bs=1M if=/dev/disk | ssh -C target dd bs=1M of=disk.img
If the network connection breaks during transfer, you can resume if you know how much was copied. For example if you're sure at least 1000MiB were transferred already (check the file size of disk.img):
dd bs=1M skip=1000 if=/dev/disk | ssh -C target dd ...
You backed up the whole disk including the MBR (512 bytes), and not a simple partition which you can mount, so you have to skip the MBR.
Please try with:
sudo losetup -o 512 /dev/loop0 disk-image.img
sudo mount -t ntfs-3g /dev/loop0 /mnt
Edit: as suggested by @grawity:
sudo losetup --partscan /dev/loop0 disk-image.img
sudo mount -t ntfs-3g /dev/loop0 /...
losetup (the command normally used to set them up) will tell you:
$ /sbin/losetup --list
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0 0 0 0 0 /var/tmp/jigdo/debian-7.6.0-amd64-CD-1.iso
Note that with older versions you may hat to use use -a instead of --list, and this outputs in a different and now deprecated format.
It depends on what exactly the partition is for, and what the purpose of the copy is. However, I will say that in general dd is an inappropriate tool for backing up filesystems. That's not what it was intended for, either.
It will waste a lot of time copying empty sections of the partition.
It may lead to inconsistencies if the filesystem is currently ...
This is possible for syslinux:
The syslinux installer contains enough magic to be run on an unmounted filesystem. (In fact, it is designed to do that.) The extlinux installer expects to be run on a mounted filesystem, though.
It is almost certainly possible to split off the extlinux installer into a part that copies the files (...
There is another way to do this in general, use kpartx (not kde related)
sudo kpartx -a binary.img
and now you should have all partition devices defined under /dev/mapper as loop0p1, loop0p2, ...
sudo mkfs.ext4 /dev/mapper/loop0p1
Optionnaly, when you are done, you can run also
sudo kpartx -d binary.img
to get rid of the loop0p? deivce
After some research, I found that ext4 is apparently quite usable on SSDs, so I went with the clone approach. Here is what I did, step by step:
Install the SSD
Boot from a USB and clone the HDD to SSD with dd
Change the UUID of the new filesystem. I missed that one at first, which caused funny results as grub and other software got confused
Update the fstab ...
The fdisk equivalent is gdisk, which is commonly available in the gptfdisk package via package manager. You'd do much better to use it, in my opinion. I don't trust anything *parted, personally - any partition tool that simultaneously partitions and formats is not a partition tool.
some unix partitioner, are deperecated and GPT partition table is new and some tools doesn't work GPT. GNU parted is new and gparted is GNOME Parted
root@debian:/home/mohsen# parted -l /dev/sda
Model: ATA WDC WD7500BPVT-7 (scsi)
Disk /dev/sda: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start ...
You should never run dd on a mounted file system, because that can corrupt the image, esp. if you want to do a backup. You may want to use tar instead.
If you are sure that the device is not failing, you may use the seek (for seeking N blocks into the output file) and skip=N (for skipping N blocks of the input) flags. On a Linux system, you can use the ...
losetup -P automation for multi partition images
How to mount a disk image from the command line? | Unix & Linux Stack Exchange mentioned losetup -P, and here are some handy Bash functions to further automate things. Usage:
$ los my.img
$ ls /mnt/loop0p1
$ sudo losetup -l
According to the simplest converter, I have found, 7.4 GiB equals approximately 7.9 GB.
As you haven't written any specific commands to output the actual size, this could be it.
GiB = GibiByte = multiples of 1024.
GB = GigaByte = multiples of 1000.
Some applications could still confuse these units.
Snippet from the comments:
7927234560 bite (7,9 ...
apt install liblz4-tool
Then you can compress with lz4 command and decompress with lz4 -d.
It defaults to the fastest compression mode.
500 GB from internal hard drive to an external drive over USB 3.0 is estimated to take between 2 and 3 hours:
mint Backup # dd if=/dev/sda bs=100M | pv -ptera -s500G | lz4 > Lenovo-Win8-sda.dd.lz4
Yes, it is perfectly possible to mount partition images made with dd. You should add a -o loop (i.e., use a loopback device) to the mount command.
The final command should look like:
mount -oloop -t vfat ~/part.img /mnt
Of course, you should have dd'ed from a valid and previously formatted vfat filesystem in the original partition.
If you add a line in /etc/fstab saying something like:
/dev/loop0 /mnt ext4 defaults,user 0 0
you can then mount/unmount /dev/loop0 as a regular user.
And if you do chown youruser:youruser <MOUNTPOINT> <LOOPDEVICE> then extlinux , losetup, mkfs, etc can be done as youruser.
Annoyingly, btrfs filesystem show returns an approximate value if the size isn't a multiple of 1MB. It also requires a loop device, btrfs filesystem show img.btrfs doesn't work (as of Debian jessie). I can't find another btrfs subcommand that would help.
But file img.btrfs helpfully returns the desired size.
$ truncate -s 16684k /tmp/img.btrfs
When the .iso file was burnt to the DVD, it was unpacked, so it's not a .iso file any more but probably a Joliet file system by now.
What your question probably means is
How do I make an .iso file from a DVD?
and then the answer is:
sudo cat /dev/sr0 > /path/to/dvd.iso