Today I tried this on my machine with OpenSUSE 12.3 (kernel 3.7):

# resize2fs /dev/mapper/system-srv 2G
resize2fs 1.42.6 (21-Sep-2012)
Filesystem at /dev/mapper/system-srv is mounted on /srv; on-line resizing required
resize2fs: On-line shrinking not supported

/dev/mapper/system-srv is an EXT4 volume.

Is it really unsupported or I am missing something?

3 Answers 3


As the message said, you can only grow an ext4 filesystem on-line. If you want to shrink it, you will need to unmount it first.

According to the ext4 filesystem maintainer, Ted Ts'o:

Sorry, on-line shrinking is not supported.

  • 14
    That's a pity...
    – Alicia
    Commented Aug 1, 2013 at 19:06
  • 6
    What's with the downvote? Commented Sep 23, 2014 at 17:43
  • 28
    @MichaelHampton - some moron shooting the messenger? :D
    – tink
    Commented Sep 29, 2015 at 22:49
  • 3
    That was 10 years ago. Has this been implemented yet? Commented Jun 17, 2019 at 18:07
  • 3
    @duane No. It has not. It is not likely ever to be, either. Commented Jun 18, 2019 at 0:49

If the case is remote server without console, you can shrink filesystem using initramfs while rebooting. You need to add resize2fs to initramfs and run it before mounting root.

Debian/Ubuntu example:

/etc/initramfs-tools/hooks/resizefs (executable):


set -e


prereqs() { echo "$PREREQS"; }

case $1 in
        exit 0

. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/e2fsck
copy_exec /sbin/resize2fs
exit 0

/etc/initramfs-tools/scripts/local-premount/resizefs (executable)


set -e


prereqs() { echo "$PREREQS"; }

case "$1" in
        exit 0

# simple device example
/sbin/e2fsck -yf /dev/sda1
/sbin/resize2fs /dev/sda1 5G # see size info below
/sbin/e2fsck -yf /dev/sda1

# complex device example
# activate md-raid containing FS/PV
#/sbin/mdadm -A /dev/md0
# activate VG containing FS
#/sbin/lvm vgchange -ay vg0
# resize
#/sbin/e2fsck -yf /dev/vg0/root # or /dev/md0
#/sbin/resize2fs /dev/vg0/root 5G
#/sbin/e2fsck -yf /dev/vg0/root

Now run update-initramfs -u -k kernel-name to update initramfs for the kernel kernel-name which is set as default in your bootloader (grub). In case of boot failure - you can boot with another unmodified healthy kernel/initramfs. Or you can use all to update all kernels, but then you have no way back.

Check that you do not have any tools in your system that grow filesystem automatically (e.g. cloud-init - comment resizefs in /etc/cloud/cloud.cfg).

Reboot. Check filesystem size. Remove initramfs scripts and run update-intiramfs -u -k kernel-name again.

Now you can shrink underlying device with parted resizepart / mdadm --grow --size= / lvresize -L. The size of the device should be bigger then the size of filesystem from the scripts. The simplest way to make no mistakes: if planned device size - 6G. set fs size in the script to 5G. after fs is resized - resize device to 6G, then grow fs to maximum online with resize2fs /dev/sda1. Now your fs fits perfectly in your device.

For dracut (Fedora,CentOS) use the same logic (/usr/lib/dracut/modules.d).

This is very usefull for crypting or moving rootfs, with no free space available for the new partition.

  • 5
    This works like a charm. Note that you need to run update-initramfs with the -u option. Commented Jan 25, 2018 at 18:19
  • 1
    Cool. In my case I also needed to update-grub. Commented Aug 3, 2018 at 12:32
  • 1
    This totally works, but I didn't think so at first because my hosting provider had stuck an /etc/rc.local entry in that resizes / to maximum size on every boot! Presumably they have a stock image that gets autoexpanded per host. Banished and all is well. Commented Jul 24, 2020 at 18:18
  • Shouldn't the /sbin/resize2fs be run with /dev/lg/lv_root parameter in case of LVM? My logical volume /dev/lg/lv_root consist of two physical partitions /dev/sda2 and /dev/sda3 therefore I don't think I should be shrinking sdaX directly. Commented Dec 27, 2020 at 14:25
  • By 'run update-initramfs', do you mean to run it with the -u parameter? Commented Dec 27, 2020 at 14:59

Yes, you can shrink/move/grow a root partition without any reboots (nor livecd, nor usbkey): consult this answer. It's very well written and easy to follow, although quite long and a little risky.

resize2fs can't shrink online ext4 partitions. This limitation, when applied on the root partition may lead you to think you can't avoid rebooting the host to allow shrinking the root partition, which might be something you want to avoid. The linked process will allow you to umount the root partition without any reboots. So in this light it is not strictly speaking online resizing in regards to the mounted state of the partition, however it remains an online resizing in regards to the network online status or reachability of the host.

Of course, if you only want to grow your ext4 partition, you should stick to the conventional working resize2fs solutions.

The general solution I've linked will work on any type of dedicated or VPS solution for instance.

TLDR; this solution implies to pivot_root to tmpfs so you can umount safely your root partition live and fiddle with it. Once done, you'll pivot_root back on your new root partition.

This allows pretty much any manipulation on the root file system (move it, change filesystem, changing it's physical device...).

I have personally used this, and it works very well on debian system also, but the guide was initially written in 2007 for redhat, the answer I've linked was updated for CentOS7. It's highly probable that it'll work on your OpenSUSE, although probably with some adaptation.

  • 16
    This is not 'online' in regards to comparison with 'online grow'. All services must be down and your root filesystem becomes inaccessible. Might be worth contrasting this with the livecd or initramfs/rdshell approach in this comment. I'd hate for people to be confused by this. Commented Jun 14, 2016 at 23:16
  • 3
    @BrianChrisman This is indeed a gotcha that merited clarification and that I hope I've covered with an edit in my post. Many thanks for the feedback.
    – vaab
    Commented Jun 15, 2016 at 7:35
  • What I like about the referenced solution is that it's 'almost online'. I did this particular thing by encoding a small script and tools into the dracut command and launched the resultant initramfs from kexec. If this could somehow keep an ssh session open through the process, that would be best. I suppose if you build the faked root with sshd and needed files, start another sshd (because you're ssh'd in) on another port, then you can ssh to the other port and verify connectivity before continuing to lobotomize the system. Commented Sep 3, 2016 at 23:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .