3

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

5
  • This Question is off topic for this site. You need to understand the structure of images designed for a SD Card, but you are using the spare 3MB in the image. You will probably succeed if you note the start sector of the root partition specify this instead of the default.
    – Milliways
    Apr 27, 2020 at 1:36
  • Sorry, I don't follow your statement. What does "you are using the spare 3MB in the image" mean? Do you mean that my existing partitions left only 3MiB spare, and the newly-created partition could only use those? That doesn't add up - 3.1G (post resize image size) - (256M (sda1) + 1.9G (original sda2)) gives ~944M, not 3M. Also, apologies for asking an off-topic question. Can you elaborate on why this was off-topic, but this one wasn't?
    – scubbo
    Apr 27, 2020 at 2:34
  • In fact, I came to this stack precisely because a commenter on this question mentioned it.
    – scubbo
    Apr 27, 2020 at 2:48
  • This is NOT a discussion site, BUT your Question was about qemu which is off-topic. Doing things in an emulator is quite different. If you want to build/modify custom images you NEED a Linux machine. You will find quite a few Questions which discuss this, but most assume a good understanding of Linux and partitioning tools. Also you CAN NOT modify an active partition.
    – Milliways
    Apr 27, 2020 at 3:36
  • Are you able to use a computer with a Debian like operating system (Debian, Ubuntu, Raspbian, etc.) with enough disk space to create an image with the size of your choice? Please address me with @Ingo, otherwise I won't see your reply.
    – Ingo
    Apr 27, 2020 at 12:06

1 Answer 1

2

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;1 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)2, which you need to do once the partition(s) are expanded, using resize2fs.3 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.

2
  • Interesting - thanks! I'll try that and report back.
    – scubbo
    Apr 27, 2020 at 16:45
  • Success! I ran sudo fdisk /dev/sda as before, deleted a partition and created a new one explicitly setting the start sector to be the same as the deleted partition's), ran sudo resize2fs /dev/sda2, and df is now reporting that /dev/root is correspondingly larger. Thanks a ton - I never would have thought to check whether the partitions started at 0!
    – scubbo
    Apr 28, 2020 at 3:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.