How to resize a partition on a Raspberry Pi image, emulated on a Mac?

Question

I followed this guide to emulate a Raspbian image on my Mac - the only change I made was to use a Buster Lite image. The Image boots perfectly well, and I can interact with it either via the popped-up terminal or by ssh-ing to the hosted device. However, once I started installing software, I swiftly ran out of space.

By using qemu-img resize (as prompted by here and here), I am able to resize the image such that sudo fdisk -l's output changes from reporting, say, Disk /dev/sda: 2.1 GiB to Disk /dev/sda: 3.1 GiB. However, the actual available disk space remains the same - that is, df still reports the same %ge of disk usage, and I still get "out of space" errors when trying to install software.

I think that this is because I also need to extend the partitions on the disk. Referring back to this guide, here is what I did:

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sda: 3.1 GiB, 3321888768 bytes, 6488064 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c586e13

Device     Boot  Start     End Sectors  Size Id Type
/dev/sda1         8192  532479  524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 4390911 3858432  1.9G 83 Linux

Command (m for help): d
Partition number (1,2, default 2):

Partition 2 has been deleted.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p):

Using default response p.
Partition number (2-4, default 2):
First sector (2048-6488063, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-8191, default 8191):

Created a new partition 2 of type 'Linux' and of size 3 MiB.

Note that, following the defaults, the newly-created partition is only 3 MiB, which is smaller than the 1.9G previous partition. If I quit fdisk, and retry, trying to explicitly set a larger size (such as +2G) for the "Last sector" value, I get Value out of range.. This happens event for +1G (which is smaller than the previously-existing partition) - indeed, it even happens if I try to create a partition of size +3M, which is what the default successfully does! (+2M, however, succeeds)

EDIT: prompted by @Milliways' comment, I tried creating a new (3rd) partition without first deleting the existing partition - this, likewise, defaulted to 3MiB size, and did not allow the ~900Mb size that I would have expected (3.1G - (256M + 1.9G) ~= 900M). This just raises a further question - why does the d command in fdisk (as demonstrated, among other places, here and here) not free up disk space for the soon-to-be-created partition? (I infer from fdisk's output that changes are just being staged, and are not actually enacted until w is entered)

EDIT2: I tried writing the image to an actual (64G) SD card and booting in a physical Raspberry Pi. Upon first boot, it displayed a message "resizing root partition", and rebooted. After it started up again, I logged in, and sudo fdisk -l reported that /dev/mmcblk0 had size 58.2G - which I assume is about what's expected for an SD card that is reported as 64G. However, I don't consider this issue closed:

• I only have a 64G SD card to-hand, but I'd like to create an image that could be distributed on smaller cards
• I'd like to actually understand why the previous attempts to resize the image and partitions directly and deliberately were failing. Just because I'm unblocked from installing more software and continuing development now, doesn't mean I can't learn!

I was unable to "downsize" the image by running sudo fdisk /dev/mccblk0 from the Raspberry Pi itself - I got fdisk: cannot open /dev/mccblk0: No such file or directory

Answer 1

Note that, following the defaults, the newly-created partition is only 3 MiB, which is smaller than the 1.9G previous partition.

Let's think about why that is.

You deleted the second partition. This leaves the first partition, which starts at sector 8192. Then you ask to make a second partition, and accept the default starting sector, which is always going to be at the beginning of the device if there is space. And there is space at the beginning;¹ the default starting sector (2048) is offset 1 MiB (2048 * 512 sector size) but the first partition starts 8192 - 2048 = 6144 * 512 = 3145728, exactly 3 MiB, after that.

What you want to do is start the new partition at the same place as the old one started, after the first partition, at sector 532480. The "end at" default will then be the end of the device image, and you can use the whole thing.

That's not it though.

I think that this is because I also need to extend the partitions on the disk.

I'm not a qemu user but it's implied that qemu-img resize just resizes the device image and not the content, hence you have to manually resize the partitions inside. But that does not resize the filesystem(s) in the partition(s)², which you need to do once the partition(s) are expanded, using resize2fs.³ You can do this from the active system or while it is unmounted, see man resize2fs and the piles of examples you should be able to find online.

---

1. This 4 MiB offset is a perhaps superstitious practice used with Pi images on the presumption that it will force proper block alignment for the filesystems put on the SD card. It does not contain anything.

2. Resizing a partition != resizing the filesystem it contains.

3. This is a partition type specific process, and resize2fs can be applied to ext2/3/4 types. The system root fs, on the second partition in Raspbian images, is ext4.