Last active
June 8, 2024 10:19
-
-
Save cpuuntery/d382cf43ea046ba597ba2fe4732a6c3f to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The [count] and [skip] parameters scale with the [bs] parameter the default bs value is 512 bytes | |
you can use 1K or 1M, but it uses the binary units | |
and use [iflag=fullblock] to copy the fullblocks | |
The skipped size is [bs * skip] | |
The output size is [bs * count] | |
[fullblock] and [sync] are mandatory to be used. more info about the flags at the end | |
[skip] is optional, it is only used when you want to image a partition in the middle of the disk | |
1-gnome-disk-image-mounter --writable file.img | |
2-open gnome disks to get the device block of the mounted image. it is usually like this /dev/loop1 | |
3-delete any unnecessary files to make the disk image smaller. After you finished deleting the files, unmount the partition so gparted resize it | |
4-sudo gparted [device block from step 2] | |
5-resize partitions using gparted | |
6-The sector count starts from 0. | |
So if the unallocated space is at the end. You will need to added 1 to the sector count. If you are using the default bs that is 512 bytes, you just need to add 1 without the multiplication because it is the default 512 bytes | |
(sector count+1) | |
count = (last sector in gparted) +1 | |
but if the bs is not the default 512 value, the number of count or skip Wil be | |
(sector count+1)*non default bs | |
if you are copying a partition in the middle of the disk, you do not need to add 1 to the sector count for [skip] | |
skip= first sector in gparted | |
count = (last sector in gparted) +1 | |
if=[Can be the block device of the mounted image, the same one you used with gparted] | |
dd if=/dev/sdb iflag=fullblock of=disk.img count=1000000 conv=sync status=progress | |
Or alternatively you can | |
1- write the image to disk using gnome disks | |
2- update the files | |
3- run sudo fdisk -l /dev/sdx | |
4-sudo dd if=/dev/sdx iflag=fullblock of=/path/my_image.img count=From the end sector from fdisk +1 conv=sync status=progress | |
dd if=/dev/sdb iflag=fullblock of=disk.img count=1000000 conv=sync status=progress | |
dd if=/dev/sdb iflag=fullblock of=disk.img skip=12345 count=1000000 conv=sync status=progress | |
5-write my_image.img to disk using gnome disks | |
6- use gparted to fix gpt Partition Table | |
7-Create an image from the fixed partition | |
there is important caveat when using count dd can copy partial blocks, so when given count it will stop after the given number of blocks, even if some of the blocks were incomplete. You may therefore end up with fewer than bs * count bytes copied, unless you specify iflag=fullblock. | |
conv=sync tells dd to pad each block to the left with nulls, so that if, due to error, the full block cannot be read, the full length of the original data is preserved, even though not all of the data itself can be included in the image. that way you at least know how damaged the data is, The shorter block at the end when reaching the end of file or disk will be padded with zeroes or blanks | |
Caching of data is a kernel process. That means if you copy a file (no matter via a file manager or via dd), the write cache gets filled and in parallel the real writing to the flash drive starts. To make sure that the writing process is finished (cache completely flushed) it makes sense to use sync. You may have noticed that when you transfer data to an USB flash drive, your desktop environment tells you that the copy is finished. But you are still not able to eject the flash drive safely. Thats because the background kernel process is still flushing the content of the write cache to the flash drive. With the sync operater you will see when the write process is really finished. | |
conv=fdatasync should be enough and best performing (no file metadata is added after all, and only syncing at the end of the process is really needed), but oflag=sync (complete data + metadata sync after each write) in other words waiting for all temporary caches to empty after submitting each block of data | |
using oflag=sync, so progress outputs the real transfer speed and not the cached one but could be significantly slower. You can mitigate this, by increasing the block size |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment