If you have a full dd image of the disk, you can just do losetup -Pf /path/to/your/image.img and that will pick a loopback device and perform the partprobe on it automatically.
Thanks, not OP but that looks useful to me. For context, I've used the strategy in OP to debug a small linux system running on an SD card, if I have one version that has a bug and one that doesn't, and I don't know the difference, I can image them both, mount them and diff the whole system (i.e. with meld.) And it can be done with the same card over time. I'd like to figure out how to do this with VM disks as well but I've never had a pressing need.
I commonly use loopdevs to create and partition bootable disk images for clonezilla. I like that I can create them sparse so that they take up less space.
I'm not sure. All I can think is that partprobe is provided by parted and I have noticed people tend to gravitate towards using fdisk or parted and ignoring the other. Notice the author of the article is an fdisk guy.
I might be mis-remebering but I think parted used to be considered lame before fdisk lagged to support GPT.
Personally I’d call myself an fdisk/gdisk person - I like the safety net those programs provide by staging disk changes prior to committing to the MBR/GPT, if I’m doing things by hand this is my preferred tool.
I don’t like how parted will automatically commit your changes as you go, though this is useful for scripting your changes and is my preferred method for disk geometry modifications when preparing maintenances etc
Right tool for the job and all that.
From what I remember partprobe has had a history of occasional unreliable behaviour under RHEL - but I understand it works properly under RHEL 7.3+
There's just one thing I don't get with this approach. How do you make use of the space savings? You've explicitly created an outside disk image which is larger than the ddrescue image, and the ddrescue image is inside that larger file. So while the inside image is taking less space inside the mounted loopback volume, the outside disk image will always take the original amount of space. Do you trim the outside volume after you're done or do you somehow extract the lzo-encoded disk image after?
It's called sparse files, it's files with holes in them where no data is written to disk. You can have terabytes of files on small disks as long as they contain a high % of bocks of only zeros.
There’a actually an even easier way for many use cases. Just use libguestfs. One big benefit it has over the losetup process is that it works in unprivileged containers because nothing needs to be mounted.
One time I tried to create a tool to do in-place conversion between Linux software RAID volumes (e.g. RAID-0 to RAID-1 (assuming data fits), or RAID-1 to RAID-5, etc.) I used disk image files and the loopback device to test it to avoid having to reformat physical partitions.
Despite reading all of the documentation I could find, and even going so far as to read kernel source code, I could never get the system to recognize my striped block data. That is, I tried to generate three files composing a RAID-5 "by hand", but mdadm would refuse to mount them. I never figured out if there was some additional id-block I was missing, or if my striping algorithm was not correct.
Sure, ZFS has lots of awesome features, but the point of loopback device lets you to attach and mount basically any disk image that has kernel or fuse drivers.
^ The above creates a 100MB disk image, binds it to a loopback device, runs fdisk, and then detaches it. I'm not sure how formatting the partition would work but presumably those tools have an offset option too?
