I needed to expand my Umbrel from 1Tb to 2Tb. Unfortunately it wasn’t quite the smooth process I’d hoped, so I thought I’d document my journey in case it helps anyone who hits the same issues as I expect quite a few people will be getting to the stage where a 1Tb drive is getting a little low on space and thinking about an upgrade …
I was down to my last ~100Gb so I decided it was time to upgrade to a larger drive (1st world problems, I think my first ever HDD was only 10Mb!). Also my son had just bought himself a gaming laptop so could make use of the existing 1Tb SSD for extra storage so it wouldn’t go to waste.
The approach I decided on was to install the new 2Tb drive in the server (an N100 mini-PC), put the existing 1Tb drive in a USB enclosure, use a tool like Rescuezilla or Foxclone to clone it, and then GParted to resize the partition to use the extra space. Then I’d just unplug the USB drive, turn it back on, and I’d be good to go.
Easy, right? RIGHT?! Well …
That’s how it should work. For me, everything went fine until I got to using GParted to expand the partition which failed with:
“resize2fs: New size results in too many block group descriptors”
From what I’ve read, I think this is due to the block size on the filesystem (I gather creating a small partition and then expanding it is a no-no precisely because of this kind of issue). However it happened, the filesystem was using a block size of 1024 instead of the typical 4096 default. This was originally setup with Umbrel 0.5.4 installed on top of Debian and upgraded to the latest 1.x using the migration tool and I can’t recall ever being asked the block size to use, so maybe something picked it as the best for the size of the drive (there’s a filesystem config for ‘small drives’ that may have caused it).
Note: if you do plan on upgrading your system, you can check if this is going to be an issue by opening the terminal and running stat -f /data which will tell you the block-size used.
So what to do?
Fortunately, I had 2 identical mini-PCs so I could put the original SSD back in and leave the Umbrel server running and try a few things out with the now-cloned drive to try to figure out how to make it right.
I looked at using dd to do the cloning, but a test run showed it was painfully slow and I wasn’t confident it would really change the situation. Same with clonezilla which looked complicated to use. I tried creating a backup using Rescuezilla, recreating the partition with a larger block size, then restoring … but it just put everything back as it was (I guess because it does a block-level backup and recreates everything as-is). It was useful to be able to get back to the just-cloned-state though, so I could try different things while the Umbrel server was still running - it takes the pressure off, and avoids rushing and making a mistake.
The approach I finally used was:
- Install the new 2Tb SSD in the Mini-PC
- Install the old 1Tb SSD in the USB enclosure
- Use Foxclone to clone from the 1Tb to the 2Tb (took about 25 minutes, and ensures all the partition IDs are identical)
- Use GParted to resize the data partition to use up the remaining space (not worrying about the filesystem error)
- Use Debian to recreate the data partition filesystem with the 4k block size:
sudo mkfs.ext4 -b 4096 /dev/nvme0n1p4(NOTE: don’t just copy this, see tips below!) - Still in Debian, mount the source and destination filesystems and copy the files:
sudo mkdir /mnt/source
sudo mkdir /mnt/dest
sudo mount /dev/sda4 /mnt/source
sudo mount /dev/nvme0n1p4 /mnt/dest
sudo cp -ra /mnt/source/. mnt/dest/
This additional filesystem copy also took about 25 minutes (you can use sudo progress -m from another terminal to see where it’s up to) and when it was finished I shut down the PC, removed the USB drives, let it start up running Umbrel again, and …
Success - everything worked and I had the new storage capacity!
Some tips:
- Use Ventoy and have all the live images of the utilities you need prepared in advance
- Learn how to boot from the Ventoy USB drive (mine was F7) so you don’t accidentally re-start the server before you’re complete
- Identify and write down the device paths - my new partition was
/dev/nvme0n1p4and the old one/dev/sda4but these may be different on your system so don’t just blindly copy any of the commands - write down all the steps with all the correct paths and double check them before you begin (don’t try to translate the paths as you go). - Never, ever, write to or change anything on the original SSD! Don’t be afraid to give up if it doesn’t seem to be going right and just put things back to how they were while you research or get help.
Good luck!