I have a Libre Computer Le Potato single board computer that I bought during the pandemic when Raspberry Pi boards were pretty much impossible to get. It has turned out to be a great little machine that’s been so reliable that a year or so ago I decided to move some of my most important home lab services, including my smart home software stack (Home Assistant, Node-RED, etc.), to it.

Libre Computer offers a version of the Raspberry Pi OS Bullseye (which they still refer to as Raspbian) that has been customized for the Le Potato’s hardware on the boards’s downloads page. For consistency with my actual Pi devices, I’m using this image on my board, though I’ve manually upgraded it to Bookworm. For the most part, everything works exactly as it would on a Pi. There are a few small differences, such as the mount points of the filesystems, but nothing that you’d notice during normal, everyday operations.

Lately, the machine been acting a little wonky–web requests would, for example, take forever to load if something else was running at the same time. Upon investigation, I found that my 32Gb MicroSD card was nearly full. No problem—just get a bigger card, clone the current one onto it, and then use raspi-config to resize the partition. Easy peasy.

I got a new 128Gb MicroSD card and proceeded to do just that. I shut down the Le Potato, ejected the card, and then used Balena Etcher on my MacBook to copy the contents of the old card to the new one (there’s any number of ways I could have done this, including the Linux dd command, but Etcher has become my preferred way to prepare SD cards for my various little computers). When It was done, I put the new card in the Le Potato and started it back up. As expected, the machine booted and everything came up, but the drive was still full because copying the partition doesn’t resize it.

Next, I ran sudo raspi-config, went to “Advanced Options,” and chose “Expand Filesystem.” After going through the prompts and rebooting, I ran the df -h command to check the free space available on the machine’s disk and, to my surprise, it was still showing as full.

Filesystem     Size  Used Avail Use% Mounted on
/dev/mmcblk1p2  30G   28G    2G  97% /

Note, to be concise, I’m only showing the affected drive’s stats. When you run the command you’ll likely see a several lines for things like in-memory file systems that the operating system creates when it runs.

Thinking that the resize didn’t take for some reason, I ran sudo fdisk -l to list the partition table, and I got this:

Device         Boot  Start       End   Sectors   Size Id Type
/dev/mmcblk1p1        8192    532479    524288   256M  c W95 FAT32 (LBA)
/dev/mmcblk1p2      532480 249737215 249204736 118.8G 83 Linux

Clearly the partition has been resized, but the drive wasn’t seeing it. Why not? I was perplexed.

After a bit of pondering, I decided to check what type of file system the drive was using. To do this, I ran df -hT. This time, I got the following output:

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/mmcblk1p2 btrfs      30G   28G    2G  97% /

Butter FS! All of my actual Pi’s are using the Ext4 file system, which will automatically use the full partition when it is expanded, but my Le Potato is using btrfs, the BTree File System. btrfs is a newer file system that has some nice features, including the ability to span multiple physical drives, data integrity features similar to RAID, and the ability to make snapshots of the drive’s state. I chose to use btrfs when I built my NAS because it gave me RAID-like redundancy across the initial two drives that I added, but would also let me use different size drives in the future, when I need to add more capacity, without losing any space the way I would with RAID.

Because of the way btrfs works, another step is needed:

btrfs filesystem resize max /

This tells btrfs to resize the file system mounted at / (the root files system) using all of the space available to it which, in this case, is the remaining portion of the partition created by raspi-config.

The fact that this can be done (and has to be done) on the running filesystem always seems weird to me as I’m used to having to unmount drives before doing any kind of maintenance on them, but because btrfs can span multiple disks, the file system has to be mounted.

While it technically isn’t necessary, I did one more reboot after resizing, just to make sure everything got updated:

sudo shutdown -r now

Once back up, I ran df -hT again and now I’m seeing this:

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/mmcblk1p2 btrfs     119G   28G   91G  24% /

Much better. And more importantly, the machine appears to be stable once again.

I don’t know how popular btrfs is with other Raspberry Pi “clones,” but if you attempt to install a larger SD card and don’t get the results you’re expecting, be sure to check what file system is being used. There may be extra steps necessary.