20

I'd like to build an in-house Raspberry Pi image based on Raspbian Lite which is already configured with the correct locale, timezone, etc. Unfortunately for me, current releases of Raspbian images automatically resize the file system, then reboot.

I want to avoid the hassles of downsizing the filesystem by preventing the resize from ever occurring. How would I edit the image after burning such as to temporarily disable the automatic file system resize?

Edited to clarify effects should be reversible; that is, I'll want my customized image to expand at first boot.

4
  • This may not be the ideal solution but have you considered using a small card 4gb where this would not present such a problem. Oct 21 '16 at 19:51
  • 3
    Interesting idea.. burning to a small card, effectively limiting the resize. I'd prefer a direct solution but this is a decent alternative. Thanks Oct 21 '16 at 19:54
  • 2
    That is pretty annoying. I'm very sure this is done via some simple self-effacing boot script a la the way raspi-config is run at first boot, and would be easy to disable. I can have a look but I'll have to download a new image, the last one I have is from May. Check back in few hours.
    – goldilocks
    Oct 21 '16 at 20:09
  • @patricktokeeffe Let's say you have a 16 GB microSD card. What happens if you 1) burn the 4 GB image on the micro SD card 2) create a fake 12 GB second partition to prevent the empty space to be used 3) Boot normally?
    – Basj
    Oct 7 at 20:29
22

There is a two part mechanism which takes responsibility for this on Raspbian; likely the best idea is to take care of both parts if they are enabled.

The first is that the original /boot/cmdline.txt includes this:

init=/usr/lib/raspi-config/init_resize.sh

Referring to a script with that path on the root partition, which will be used as the init process at boot. Without that bit, it would default to a value built into the kernel, /sbin/init, which on Raspbian is a symbolic link to /lib/systemd/systemd.

By removing that portion of cmdline.txt, the system should then boot normally.

What that script actually does is resize the partition on the SD card. This is a distinct process from resizing the filesystem in the partition,1 which is what happens next.

The way that happens is the system is immediately rebooted normally (that is, via systemd) and an init.d script is set to trigger early on, which should be removed from the second partition:

/etc/init.d/resizefs_once

And the symbolic link to it, which should also be removed:

/etc/rc3.d/S01resizefs_once

You can keep a copy for later use if you want, but raspi-config can create it again for you (it's embedded in the raspi-config shell script). If it actually runs, it deletes itself, so it will not happen again.

What it also does is resize the filesystem in the newly resized partition.

No harm should be done if just one or the other part happens; in the first case you end up with a filesystem that doesn't fill the enlarged partition, in the second nothing will happen, because the filesystem already fills the partition.

If you later use raspi-config to enlarge the filesystem, it does the partition resize right away, then sets up the init script (as already mentioned).

Editing cmdline.txt on the first partition is simple on any computer since it is a VFAT partition. Removing the init.d file requires a system that can access and edit ext4 filesystems.

Both tasks can instead be done to the image file itself prior to burning the card; to mount and modify a Raspbian image on a GNU/Linux system, see here. There is a parallel Q&A for Windows.

This is also reversible, but you'll need to put back both parts of the mechanism as just described, since the first one does not include automatically staging the second one.


  1. Although an error message from that script arguably confuses those terms by claiming it failed to resize the root filesystem, when what it really failed to do is resize the partition on with the root filesystem resides. Doing one does not automatically accomplish the other.
5
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Ghanima
    Oct 24 '16 at 22:52
  • 1
    @goldilock's disabling of init=/usr/lib/raspi-config/init_resize.sh from /boot/cmdline.txt works on ubuntu mate too and seems enough all by itself. I have a 4gb ubuntu mate image flashed onto a 32gb sdcard and its holding the partition sizes at the original image size. Also /etc/init.d/resizefs_once and /etc/rc3.d/S01resizefs_once dont exist after first boot on ubuntu mate.
    – sith
    Jul 18 '17 at 4:09
  • Just to confirm, will restoring both the cmdline.txt and init.d and rc3.d file and link allow the next boot to resize all by itself or will I've to run raspi-config and run it manually?
    – Oxwivi
    Jan 1 '19 at 13:49
  • @Oxwivi It should, yes. I've clarified this whole post and made an explicit comment about that at the end.
    – goldilocks
    Jan 1 '19 at 18:40
  • 1
    Yes, thank you. Also of note, IDK since which version but at least the latest version does not carry the resize script references you mentioned outside cmdline.txt. I booted up the Raspbian image using systemd-nspawn and still got error logs attempting to resize after removing cmdline.txt thing, however.
    – Oxwivi
    Jan 2 '19 at 11:17
2
+50

You can flash the same image on two SD cards: you boot from the first one (which will expand), and mount the second one using the USB card reader. Then you chroot into the second image, make the changes you need, and unmount it: voilà, you have a modified unexpanded image on the second SD card.

  1. Flash the image on two SD cards, boot from the first one, put the second one in a card reader. Suppose it becomes /dev/sda.

  2. Mount the second image and chroot into it:

sudo mkdir /mnt/img
sudo mount /dev/sda2 /mnt/img
sudo mount /dev/sda1 /mnt/img/boot # if you need to edit the boot partition as well
sudo chroot /mnt/img
  1. Edit the image you chrooted into, e.g.
apt-get install mc
raspi-config
  1. Unmount the modified image and save it where you want it:
exit
sudo umount /mnt/img/boot
sudo umount /mnt/img
sudo rm -d /mnt/img
sudo dd if=/dev/sda of=/path/to/backup bs=1M count=<size_of_image_in_MB>

If you prefer to actually boot to the unexpanded image, e.g. because the changes you want to make won't work in the chroot jail, you can do that in a similar way:

  1. Flash the image on two SD cards, boot from the first one, put the second one in a card reader. Suppose it becomes /dev/sda.

  2. Mount the second image and remove the resize_fs hook:

sudo mkdir /mnt/img
sudo mount /dev/sda2 /mnt/img
sudo mount /dev/sda1 /mnt/img/boot
sudo cp /mnt/img/boot/cmdline.txt ~/
sudo sed -i s!init=/usr/lib/raspi-config/init_resize.sh!! /mnt/img/boot/cmdline.txt
sudo mv /mnt/img/etc/rc3.d/S01resizefs_once ~/
  1. Unmount the image and boot into it, doing the changes
sudo umount /mnt/img/boot
sudo umount /mnt/img
# eject the second SD card,
# boot into it, do the changes
# shut down, boot back into the first SD card
# put the second SD card back into the card reader
  1. Put back the resize_fs hook and save the modified image:
sudo mount /dev/sda2 /mnt/img
sudo mount /dev/sda1 /mnt/img/boot
sudo mv ~/S01resizefs_once /mnt/img/etc/rc3.d/
sudo rm /mnt/boot/cmdline.txt
sudo mv ~/cmdline.txt /mnt/img/boot/
sudo umount /mnt/img/boot
sudo umount /mnt/img
sudo rm -d /mnt/img
sudo dd if=/dev/sda of=/path/to/backup bs=1M count=<size_of_image_in_MB>

The size of the original images is listed here, or, better yet, take note of the image you have downloaded. You can add a couple of extra MB for safety, it will make your image larger but will not harm in any other way.

Note: technically you don't actually need an SD card, or the Pi, to do changes. You can mount the image you downloaded on any Linux machine (losetup -P /dev/loop0 image.img; mount /dev/loop0p2 /mnt/img), and edit the files you need. It's also possible to install packages into it with apt-get -o RootDir=/mnt/img, however, it gets easier if you work on a compatible system (that is, an actual Pi).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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