23

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.

patricktokeeffe
  • 557
  • 2
  • 5
  • 11

3 Answers3

26

[Beware this may not reflect the current mechanism as it is some years old.]

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 which the root filesystem resides. Doing one does not automatically accomplish the other.
goldilocks
  • 60,325
  • 17
  • 117
  • 234
4

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).

Dmitry Grigoryev
  • 28,277
  • 6
  • 54
  • 147
2

I found a very easy solution for this issue. Seems the automated resizing process only fires when the Raspian image is the LAST one. So what I did while trying to setup a 2TB OpenMediaVault server (requiring some empty space for storage) is to simply move the Raspian rootfs (do not move the boot partition) partition right after I created it with Imager using my PC's Partitioning tool (in my case KDE Disk Partitioner). I moved it to the end of the 2TB disk leaving 30GB free at the end. I also created an EX4 partition for the large remainder of the space I wanted to reserved for OpenMediaVault. I then booted this drive for the first time and the automatic partition expander ran as normal extending the Raspian partition into the free space at the end. Worked perfectly and was easy to do.