Andy Smith <andy@xxxxxxxxxxxxxx> writes: > The LV there when examined in a partitioning tool such as "fdisk" > now thinks it has a 3.2TiB partition and it is not usable. > Correcting the partition sector numbers allows for use of, for > example, "kpartx", to expose the partition as a loop device but the > ext4 driver and fsck.ext4 remain unable to detect a superblock. You mean you put a partition table inside of the logical volume? Why? IIRC, the dos partition table uses units of logical sectors, so if the logical sector size changes, the start sector and length will be off. You would need to create a new partition table and use the correctly adjusted numbers when creating the partition, if that is even possible. In your case, you will need to divide them all by 8, but if any of them is not an even multiple of 8, you won't be able to do that. > I have confirmed with sha256sum that the content of the > image/partition remains the same on source and destination. If you have already modified the partition table, then how could it still have the same sha256sum? > So, clearly the issue is the 512e sector size on source vs 4Kn on > destination. Is there any way to work around this in LVM? My issue > is that I would like to be able to move images of disks/filesystems > around at the block level without mounting/creating filesystem and > transferring with an fs-level application. LVM doesn't really know or care about it. > I don't think the presence of a partition (as opposed to an ext4 > filesystem directly upon the LV) is relevant; I think the same > issues would occur with a direct filesystem. I mention it only for No, it wouldn't be a problem without the partition table. ext4 uses its own block size, which is pretty much always 4k. It doesn't know or care about the underlying disk logical sector size. If this is the only partition in the LV, then I think the best thing for you to do is to dd only the partition and don't bother with a partition table on the new machine. Otherwise, you might need to manually create the new partition table, then dd each partition individually. For that matter, using dd wastes a lot of time and bandwidth copying all of the unused space in the filesystem. I'd suggest using e2image instead. It's smart enough to skip the unused space.
