I’m trying to migrate my laptop from 4TB ssd to 350GB image but it seems that linux has very hard time reading such dumped drive since it shows up like this and OpenSUSE residing on one of partitions is unbootable (doesn’t go past initramfs):
Disk /dmnt/fcraid/FCRAIDStorage/VMs/Win10_KVM_P14s/nvme0n1-partial.img: 350 GiB, 375809638400 bytes, 734003200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dmnt/fcraid/FCRAIDStorage/VMs/Win10_KVM_P14s/nvme0n1-partial.img1 1 4294967295 4294967295 2T ee GPT
When I perform truncate -s 4TB on that image then everything is fine - fdisk will just say that oh crap, secondary GPT is damaged, lemme fix that for ya and Suse boots just fine. But as soon as I truncate it back to 350GB then fdisk falls flat and while GRUB works fine, Windows 10 boots fine, OpenSUSE flatlines.
This is my disk situation and nvme0n1p7 is useless and I want to skip it (it’s not even mounted on boot anyways). I already removed that last NTFS windows recovery partition and nvme0n1p7 in image (when it was truncated back to 4TB) but it didn’t help either. Still truncating back to 350GB trashes image. I must say that Windows booting just fine while linux struggling is probably the last thing I would expect but well… that’s how it turned out :T
Either way - is there something I can do about that?
What are you trying to accomplish here? A smaller root partition, a smaller Linux partition?
I would simply set up the smaller partition and copy the files instead of using dd. Also, remember that the secondary partition needs to be void of any data files, so you need to do a defrag if you are to partition this.
If in doubt, go buy a 250GB or 500GB NVME SSD with DRAM cache for $40 and run Linux from that.
yeah, seems like it. Parted was crashing on error illegal seek so it seems it tried to read out of bounds. Still I’m a bit surprised it failed this badly. It turned out that Windows Disk Manager had no problem reading that disk and I simply created new partition then deleted it to make windows re-write GPT and it actually worked. That said like I said it was entirely unexpected that Windows managed to fix broken drive, typically I used Linux for data recovery stuff.
Image was sparse anyways since I kept it on btrfs with compression so it compressed all zeroes anyways and realistically file was small, but it’s always dodgy to have such image on disk since you never know when compression won’t kick in and suddenly you’ll run out of space while making backup of such image to your backup NAS.
I wanted to migrate OS’es to VM without copying home data partition (since I have this data in billion copies anyways so it’d be complete waste of space). But I wanted to keep disk itself “bootable” in a sense that it would preserve partitions layout and UUID so that both OS’es would boot right off without any bootloader reinstallations and stuff. Managed to do that in the end so I guess it’s okay. I really hate copying files because I use btrfs with CoW copies and compression and it often gets mangled when copying files in regular way so you may suddenly end up in situation when you run out of space when copying files from 60gb partition to another 60gb partition because CoW copies don’t get transferred, compression doesn’t kick in and suddenly 60gb of files expanded to 400gb. The only situation when I’m actually copying files is for data recovery when btrfs filesystem itself gets trashed beyond point of “worth trying to repair”
