Migration of Rocky 8.7 from a large .vmdk to a smaller one

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).

Any idea how I can migrate my system from large disk to a smaller one ? Did I do right ? What did I do wrong ?

If you are using lvm, reduce the lvm partition.
Then I would use clonezilla to clone the harddrive, and restore the clonezilla image back to the new 20GB harddrive. Adjust lvm to use the full 20GB

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.

Idk but I cannot walk this way now. I use XFS.

The thing that I don’t understand is why the simple copy doesn’t work ?
The disk is smaller but it contains the same partitions (the difference is the beginning and the ending of the partitions).

Here is a screenshot about the original disk:
image

# fdisk /dev/sda
image

Here is a screenshot about the disk that I made:
image

# fdisk /dev/sda
image

Any idea why this constellation doesn’t work ?

I’ve found this article. Do you have experience with this method ?

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 would suggest making other backups just in case, eg: copy the files/data that you need to an external disk just in case that article doesn’t do what it says it does.

1 Like

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.

I installed a minimal Rocky. Disk looked like this after installion:
image

entered the following commands:
image

and the result finally:
image

It booted beautifully.

(Lets see what happens my production system.)

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. :confused:
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.

Something like

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.

1 Like

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 ?

Your idea helped me a lot. Thank you for that.
I am able to boot up now.
Unfortunately it stops because it says:

image

Is it possible to tell to the system that don’t look for them ?

Tbh I changed the /etc/fstab like this:

System boot stops and dracut# promt appears but if I press Ctrl+D it continous booting and look all normal.

It runs than but after a while it freezes and only reset helps.

What can be the issue ?

Workaround:

I don’t know how to tell to the system don’t look for the logical volumes so I created dummy volumes with the same name. They don’t do anything just let me avoid the boot error.

(I still need the proper solution to get rid off them. Thank you.)

I think you just need to rebuild your intiramfs after you comment those lines out of the fstab. It’s been a long time since I did this type of thing (i.e. back in the CentOS days). From another post:

# Make a backup copy
cp initramfs-$(uname -r).img initramfs-$(uname -r).img.backup
# Regenerate
dracut -f initramfs-$(uname -r).img  $(uname -r)
1 Like

Sorry for my ignorance but idk how to use the dracut.
When dracut:/# appears I cannot do initramfs rebuild.

Should I boot from a live-system or how should I do ?

(Sorry for my lame question but this is not clear.)

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.

1 Like