Guidelines

This site is for tech Q&A. Please keep your posts focused on the subject at hand.

Ask one question at a time. Don't conflate multiple problems into a single question.

Make sure to include all relevant information in your posts. Try to avoid linking to external sites.

Links to documentation are fine, but in addition you should also quote the relevant parts in your posts.

0 votes
570 views
570 views

In the Hetzner Cloud service we want to create VMs with the root disk partitioned into a root volume and a separate data volume. We use different filesystems for root and data volume, but want to keep the data volume on local storage for performance reasons (hence no data volume on shared storage).

We can create custom images by preparing and then snapshotting a VM, and we can prevent cloud-init from automatically growing the root volume to the size of the root disk by creating a file /etc/growroot-disabled before snapshotting the VM. However, the smallest available VM type has 20 GB disk size, so the root volume in the snapshot is at least 20 GB in size. How can we reduce that to 10 GB?

in Sysadmin
by (100)
1 4 11
edit history

Your answer

Preview

Privacy: Your email address will only be used for sending these notifications.
Anti-spam verification:
By submitting this post you agree to our Terms & Conditions.
To avoid this verification in future, please log in or register.

1 Answer

0 votes
 

Changing the size of a root volume from a live system is a pain in the rear. There are tricky approaches using pivot_root to switch the root filesystem without rebooting, but it's usually much easier to boot another system (e.g. a live CD) and modify volumes from there.

In case of Hetzner's cloud service you can simply boot the server with a rescue system and SSH into that system. The rescue system has the same IP that the server normally has, and you can login either via password or SSH key (if you provided one).

After logging in you should first run a filesystem check on the volume and fix any issue the check reports. Then you can use resize2fs and parted (or whetever partition management program you prefer) for resizing the volume. First shrink the filesystem, then the partition. You can do clever size calculations so you need to run each command only once with exact sizes. However, I usually find it much more convenient to shrink the filesystem to a slightly smaller size, then shrink the partition to the desired size, then re-grow the filesystem to the partition size.

e2fsck -fp /dev/sda1
resize2fs -M /dev/sda1 9G
echo 'yes' | parted ---pretend-input-tty /dev/sda unit GiB resizepart 1 10GiB
resize2fs /dev/sda1

The parameter -f tells e2fsck to run the check even if it perceives the filesystem as clean. The parameter -p tells it to automatically repair the filesystem (if there are problems).

Running resize2fs with the parameter -M moves data to the beginning of the filesystem to reduce the required size.

Reboot the system and check if everything works as intended, then shut it down (may require additional preparation steps like resetting cloud-init, cleaning up logs, etc.) and create the snapshot.

by (100)
1 4 11
edit history
...