I have a Rocky Linux 8.7 that operates well. The thing is that the whole OS is 9GB all together but it sits on a 120GB (vmdk) disk. I wanted to migrate onto a smaller .vmdk.
How did I do ?
I took a vmdk and set to 20GB. I checked the source disk partitions and created the same structure on the new disk. I copied the data by using cp -vp from the source disk to the destination disk. I had a 1G partition for boot and another partition for root/home/swap.
First time it didn’t boot but I boot from Rocky dvd in Troubleshoot/Rescue mode and fixed the grub.
Second time boot menu came up and system boots
But it stucks … (see attached screenshot).
Vmware do have instructions to shrink a vmdk which converts it from thick provisioning to thin provisioning. That said though the disk willl still be the size it is now and will expand as and when you use the space. If you dont use it though then the image size will remain small.
It’s not reducing or shrinking, only in the sense that the LVM command reduces, but later it is formatted again. Which means it’s not the same as resizing ext4 which would keep the data intact. See steps 3 and 4 which clearly show the LVM reduce, and then formatting in step 4.
I’m testing this solution now. It says I need to backup the filesystem information with xfsdump and after partition format the xfsrestore will restore the data.
Idk. I’ve no experience. I’m sceptic but I give chance. I will report my conclusion soon.
I’m ready with the test and what the article states it works. I was able to backup and restore the data meanwhile the logical volume has been resized. But this was not “real” data so I’m going to install an OS and check whether it works.
Before I do the shrink on my productive system I did a clone with clonezilla. It took quite a long time but it is ready and tested. The productive system clone has been done successfully. It boots normally from the cloned disk.
Finally I can start the work with shrinking on my real disk.
Shrink went well. I wanted to clone the partitions with Clonezilla but it seems it is not able to restore to smaller disk anyway. Maybe I did it wrong but I tried the clone partitions to image and clone partitions directly to another disk but was no success.
I keep trying after weekend.
Personally I prefer to use cpio -p (pass-through mode) instead of cp when copying entire partitions. It tends to do a better job with things like devices, sockets, etc. If those are missing, it tends to cause problems.
find | cpio -pdm
Then cross check that all files are there and the partitions size is what you think it should be. Spot check ownerships and permissions.
Thank you for your comment. (I’ve just come back to tell how frustrating that I cannot copy the partitions with clonezilla nor cp command.)
I am going to test your suggestion.
But before I leave I need to ask that I think well or not. My idea is that I create only three partitions.
sda1 = /boot
sda2 = /
sda3 = swap
I copy (or better cpio -p ) the data from the source partitions to the destination partitions.
If It is done I fix the grub like # grub2-install /dev/sda
And I expect it boots normally.
Is it a good plan ? Should it work by design ? I spent a week with copy and fix but still no success.
(Clonezilla wasn’t able to clone the partitions or I didn’t understand the logic but was no success.)
So my question is: If I copy the binaries of Linux OS from a disk to another disk and I do some ‘magic’ will the OS boot up or this is absolutely a bad idea ?
You said you were able to boot the system using Ctrl+D. Once you have the system up and running, then use the dracut command to re-create the initramfs for your kernel while the correct /etc/fstab is in place. The commands above are used as root (in the /boot directory where the initramfs files are) while the system is up and running normally.