Hi Phillip, On Sat, Jan 20, 2024 at 01:00:54PM -0500, Phillip Susi wrote: > Andy Smith <andy@xxxxxxxxxxxxxx> writes: > > dsthost$ sudo mount /dev/mapper/slowvg-4ksectortest1 /mnt > > mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/slowvg-4ksectortest1, missing codepage or helper program, or other error. > > > > So at the end here, despite msdos partition table looking correct, > > sha256sum matching and kpartx appearing to work, dsthost can't mount > > this filesystem. Did I miss a step or misunderstand? > > Try mount -t ext4. If that doesn't work, see what e2fsck/tune2fs say. I've not needed that before and my instinct is that if it is needed, something has gone wrong. But in any case it did not help: $ sudo mount -t ext4 /dev/mapper/slowvg-4ksectortest1 /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/slowvg-4ksectortest1, missing codepage or helper program, or other error. I had posted tune2fs -l at the end of the email you're replying to; it was from dsthost, after the move. It looks pretty normal. And as I say, the sha256sum of the partition matches on both sides. Here's the tuen2fs -l again: $ sudo tune2fs -l /dev/mapper/slowvg-4ksectortest1 tune2fs 1.44.5 (15-Dec-2018) Filesystem volume name: 4ksectortest Last mounted on: <not available> Filesystem UUID: c39bf28a-c432-4a2a-9545-5da13b8574f2 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 32512 Block count: 130048 Reserved block count: 6502 Free blocks: 120293 Free inodes: 32501 First block: 1 Block size: 1024 Fragment size: 1024 Group descriptor size: 64 Reserved GDT blocks: 256 Blocks per group: 8192 Fragments per group: 8192 Inodes per group: 2032 Inode blocks per group: 254 Flex block group size: 16 Filesystem created: Sat Jan 20 04:03:42 2024 Last mount time: n/a Last write time: Sat Jan 20 04:03:42 2024 Mount count: 0 Maximum mount count: -1 Last checked: Sat Jan 20 04:03:42 2024 Check interval: 0 (<none>) Lifetime writes: 4441 kB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 2a074d90-0ade-4dfb-b8f2-3588ffa56cf6 Journal backup: inode blocks Checksum type: crc32c Checksum: 0xc7322510 In a way this is all becoming academic, as it seems very filesystem-specific. Given I generally can't poke about inside these disk images, it looks like I will never come up with a robust procedure for block-wise copying of these LVs. Using hdparm to set a 512b sector may be my only way forward. I am interested in personally knowing more though, so am happy to try out any ideas anyone has for a while. Thanks, Andy
