Solved Truncate dd img to remove unused space without corrupting GPT header?

Samuel Venable

Samuel Venable

I've tried doing this with qemu-img to resize down a bit and other things like dd'ing to a flash with less space but enough to fit space actually being used/allocated, and I'm hesitant to spend several more weeks trying to figure out another means but one that does not corrupt the GPT header, ultimately preventing it to boot.

I have another topic requesting help here I posted recently on a different matter but once I found out I was distributing a img that won't fit on 32gb flash drives due the GPT corruption I need to get this addressed as it's bit more urgent and effects more users. Sorry for making so many help topics recently.

The 32gb flash I wrote it to still works with my Mac Mini since it uses EFI, but using the same USB I wrote it to won't boot on Legacy BIOS machines due the corrupt header.

Thanks for the help!
Samuel
 
Wouldn't you just find the sector of the end of your data and dd to that point?
So if you have 1000 sectors, each 512b, then set count to that, 1000.
If you don't know what the end is, then prepare the disk by zeroing it out before writing data and then dd-ing the resultant data.
 
Do I still need to zero the filesystem even though the space unused that I am truncating is not a part of any file system? I'm not referring to unused space within the ufs, but rather completely unallocated space that shows up as "(free space)" when you enter gpart show daX on the drive.

If so, how do i zero that? I'm familiar with zeroing feespace reserved within a ufs, but not space that has no gpart index (unallocated).

Thank you for quick and helpful response. This sounds much easier than I thought it would be.
 
So, to get this clearer than mud, you're producing an image of an entire drive (hard disk, USB,SSD etc) and only want used partitions?

If the space is unused and not part of a file system, then only image the file system partition, nothing else. I think I'm missing something here?

Perhaps show what you're doing? dd command?
 
This is what I'm currently trying, after running "gpart recover da0" on FreeBSD, now I'm doing this from my Mac:
sudo dd if=/dev/disk2 of=/Users/macintosh/Desktop/FreeBSD-12.1-RELEASE-amd64-ENIGMA.img bs=1m count=22000

It disk2/da0 has 3 partitions, freebsd-boot, freebsd-ufs, and freebsd-swap, and the filespace total is less than 22GB, the rest is free space, as in not the free space allocated to the ufs.

I can copy and paste the output of "gpart show da0" if I need to. The command I am trying on my Mac hasn't finished yet. But I didn't zero the filesystem, because I didn't know how to do that in this context.
 
Samuel Venable said:
It disk2/da0 has 3 partitions, freebsd-boot, freebsd-ufs, and freebsd-swap, and the filespace total is less than 22GB, the rest is free space, as in not the free space allocated to the ufs.
Click to expand...
Have a look at sysutils/ufs_copy. Here the description from the man page with examples (README = download link):

Code: 
DESCRIPTION
    The ufs_copy copies a UFS filesystem image like dd(1).
    It doesn't copy free blocks for speed and it generates
    a sparse destination file or a compressed file for saving space.
You could install FreeBSD and the program on a USB stick, boot up, make a copy, no worry about removing unused space (free blocks).
 
Ok, so /dev/disk2 is your FreeBSD disk mounted on an Apple Mac and it contains 0,1,2,3 etc for FreeBSD using UFS as the file system? OK.

What is the status of the file system mounted on /dev/disk2. In other words, is it a brand new system or one that has been worked on. The key here is that if it's brand new, you're guaranteed it's compressed up. If it's old, then data can be spread all over the disk.

The only way I can see to properly do this is use dump/restore on a FreeBSD system.

You need to ditch freebsd-swap (use a file, see: Swap file adding ). This then leaves the last partition as freebsd-ufs. Now, dump that to another disk, wipe the freebsd-ufs partition (dd /dev/zero) and then restore back to that partition. This will be all compacted up. The size of the dump will be the size of the partition. Then when you boot from it, use growfs to expand it to whatever size you require.

(You could drop the /dev/zero step)
 
sudo dd if=/dev/disk2 of=/Users/macintosh/Desktop/FreeBSD-12.1-RELEASE-amd64-ENIGMA.img bs=1m count=22000

The command finally finished and I also tried writing the resulting img to a new usb of a different size and the GPT backup header was not corrupted. So I guess I sort of answered my own question. The problem was before I wasnt using the count=XXXX and thus it used the entire drive's potential space for the created img.

Thanks everyone!
 
You must log in or register to reply here.
Back
Top