diff mbox

[4/4] board/raspberrypi: auto-expand rootfs on first boot

Message ID 1440273688-92868-4-git-send-email-benoit@wsystem.com
State Changes Requested
Headers show

Commit Message

Benoît Thébaudeau Aug. 22, 2015, 8:01 p.m. UTC
Add init scripts to auto-expand the persistent rootfs on the first boot
to fill the medium.

These scripts follow the same procedure as raspi-config. The root
partition is first expanded, then a reboot is required, then the rootfs
is expanded. Each script removes itself once run.

The volatile (initramfs) rootfs is not affected by this change.

The instructions in readme.txt are updated accordingly.

Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
---
 board/raspberrypi/post-build.sh                    |  7 +++++
 board/raspberrypi/readme.txt                       | 11 ++++---
 .../rootfs-overlay/etc/init.d/S22expand-rootpart   | 36 ++++++++++++++++++++++
 .../rootfs-overlay/etc/init.d/S23expand-rootfs     | 16 ++++++++++
 configs/raspberrypi2_defconfig                     |  8 +++++
 configs/raspberrypi_defconfig                      | 12 ++++++--
 6 files changed, 84 insertions(+), 6 deletions(-)
 create mode 100755 board/raspberrypi/post-build.sh
 create mode 100755 board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
 create mode 100755 board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs

Comments

Benoît Thébaudeau Aug. 27, 2015, 9:02 a.m. UTC | #1
Hi Vivien, Yann, all,

On 22/08/2015 22:01, Benoît Thébaudeau wrote:
> Add init scripts to auto-expand the persistent rootfs on the first boot
> to fill the medium.
> 
> These scripts follow the same procedure as raspi-config. The root
> partition is first expanded, then a reboot is required, then the rootfs
> is expanded. Each script removes itself once run.
> 
> The volatile (initramfs) rootfs is not affected by this change.
> 
> The instructions in readme.txt are updated accordingly.
> 
> Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>

[...]

> diff --git a/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs b/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs
> new file mode 100755
> index 0000000..7b3f286
> --- /dev/null
> +++ b/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs
> @@ -0,0 +1,16 @@
> +#!/bin/sh
> +
> +case "$1" in
> +	start)
> +		echo -n "Expanding the root FS: "
> +		resize2fs /dev/mmcblk0p2 &>/dev/null

I had first tested this on a Raspberry Pi B using a 2-GiB SD card. It worked
fine and it was very quick.

I've just tested this on a Raspberry Pi B+ using a 8-GiB SD card. First, I got:

    [    6.831228] EXT4-fs (mmcblk0p2): resizing filesystem from 130322 to 7611388 blocks
    [    6.838822] EXT4-fs (mmcblk0p2): Converting file system to meta_bg
    [   16.888893] EXT4-fs (mmcblk0p2): resized to 3407537 blocks
    [   20.794071] ------------[ cut here ]------------
    [   20.798723] kernel BUG at fs/jbd2/journal.c:766!
    [   20.803338] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM

    Entering kdb (current=0xcf339b80, pid 44) Oops: (null)
    due to oops @ 0xc02216a8
    CPU: 0 PID: 44 Comm: jbd2/mmcblk0p2- Not tainted 4.1.5 #1
    Hardware name: BCM2708
    task: cf339b80 ti: cf356000 task.ti: cf356000
    PC is at jbd2_journal_next_log_block+0xb0/0xb4
    LR is at jbd2_journal_commit_transaction+0x978/0x1f08
    pc : [<c02216a8>]    lr : [<c0219cd0>]    psr: 60000013
    sp : cf357e00  ip : 00000001  fp : cf357e1c
    r10: ce93851c  r9 : cef22140  r8 : c0218e0c
    r7 : 00000021  r6 : ceedfbc0  r5 : cf357e88  r4 : cedb41e0
    r3 : 00000001  r2 : cf357e00  r1 : cf357e88  r0 : cf336000
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    Control: 00c5387d  Table: 0e6fc008  DAC: 00000015
    CPU: 0 PID: 44 Comm: jbd2/mmcblk0p2- Not tainted 4.1.5 #1
    Hardware name: BCM2708
    [<c0016d08>] (unwind_backtrace) from [<c0013ad0>] (show_stack+0x20/0x24)
    [<c0013ad0>] (show_stack) from [<c0566070>] (dump_stack+0x20/0x28)
    [<c0566070>] (dump_stack) from [<c0010964>] (show_regs+0x1c/0x20)
    [<c0010964>] (show_regs) from [<c00a4b38>] (kdb_main_loop+0x3c8/0x730)
    [<c00a4b38>] (kdb_main_loop) from [<c00a75dc>] (kdb_stub+0x19c/0x3cc)
    [<c00a75dc>] (kdb_stub) from [<c009da00>] (kgdb_handle_exception+0x284/0x8a8)
    more> 

I retried several times with the same result. Then, I fsck'ed and reformatted
the SD card, and I retried with the same sdcard.img as the first time. It worked
fine, but it was extremely slow:

    [    6.803146] EXT4-fs (mmcblk0p2): resizing filesystem from 130322 to 7611388 blocks
    [    6.826546] EXT4-fs (mmcblk0p2): Converting file system to meta_bg
    [   16.884732] EXT4-fs (mmcblk0p2): resized to 3423841 blocks
    [   26.912318] EXT4-fs (mmcblk0p2): resized to 4442841 blocks
[...]
    [  768.704191] EXT4-fs (mmcblk0p2): resized to 7581361 blocks
    [  775.571684] EXT4-fs (mmcblk0p2): resized filesystem to 7611388

So the initial contents of the unused space on the SD card seem to have an
influence, and there seems to be a bug somewhere (Linux, resize2fs, genext2fs,
tune2fs, or lack of call to e2fsck before calling resize2fs but this would not
be reliable with an online partition).

Then I retried with a 16-GiB SD card on a Raspberry Pi B, and it was very slow
too. Same if the resize is performed on a PC. However, it's very quick with
raspi-config and the latest Raspbian image. The main difference seemed to be the
block size (4 KiB on Raspbian vs. 1 KiB with mke2img), so I hacked mke2img to
test with genext2fs -B 4096 and tune2fs -J size=4, but it did not make things
faster, only the image bigger (about 512 MiB, probably the minimal size for
4-KiB blocks). So I don't know which ones, but it's probably some ext4
parameters that are having an influence on the resize2fs speed here. Any idea?

So what do you think would be the best thing to do here?
 1) Find the set of ext4 parameters making resize2fs faster and change mke2img
    and fs/ext2/* to make it possible to use these parameters.
 2) Just drop this patch from the series because the resize will probably always
    be slow for some larger SD cards.

If 2), would you keep the auto ext4 size as in the current 3/4, or would you
set a fixed size with some significant free space margin (e.g. 512 MiB)?

Best regards,
Benoît
Benoît Thébaudeau Aug. 31, 2015, 9:11 a.m. UTC | #2
Hello Jérôme,

On 31/08/2015 10:51, Jérôme Pouiller wrote:
> On Saturday 22 August 2015 22:01:28 Benoît Thébaudeau wrote:
>> Add init scripts to auto-expand the persistent rootfs on the first boot
>> to fill the medium.
>>
>> These scripts follow the same procedure as raspi-config. The root
>> partition is first expanded, then a reboot is required, then the rootfs
>> is expanded. Each script removes itself once run.
> [..]
>> diff --git a/board/raspberrypi/readme.txt b/board/raspberrypi/readme.txt
>> index d63e71e..7ee783b 100644
>> --- a/board/raspberrypi/readme.txt
>> +++ b/board/raspberrypi/readme.txt
>> @@ -34,10 +34,13 @@ And for model 2 B:
>>    $ make raspberrypi2_defconfig
>>
>>  If you want to use a persistent rootfs, the generated ext4 rootfs image
>> fits its -contents with only a small (but sensible) margin of free space by
>> default, so -you might want to adjust "Filesystem images"/"ext2/3/4 root
>> filesystem"/ -"size in blocks (leave at 0 for auto calculation)" depending
>> on your needs, then -skip to "Build the rootfs", below.
>> +contents with only a small (but sensible) margin of free space by default,
>> but +it is auto-expanded on the first boot to fill the medium. You can
>> however adjust +"Filesystem images"/"ext2/3/4 root filesystem"/
>> +"size in blocks (leave at 0 for auto calculation)" to fit your needs. The
>> +auto-expansion is controlled by
>> +board/raspberrypi/rootfs-overlay/etc/init.d/S*expand-root*. Skip to
>> +"Build the rootfs", below.
> Isn't safer to auto-expand partition while flashing SD Card instead of doing 
> it online?
> 
> Maybe you can explain how to resize partition in README or provide a script 
> like the one I sent you a few days ago (named sdflash.sh), no?

It would be safer if users pull the power plug during the few seconds that the
expansion lasts, without looking at their console output, which is not a big
risk. Doing it while flashing the SD card would have a major limitation: it
prevents the publication of an autonomous image file that you can program by any
means to get the same result.

Resizing a partition on a PC is trivial if the image is programmed first. There
are plenty of tools like gparted and tutorials for that on the web, so I don't
think adding such information to the readme.txt would be worth it.

Regarding a script writing the SD card and auto-expanding the rootfs, it might
be useful. Since it would require superuser rights, it should not be added to
the post-image scripts, but launched manually. That would give users a choice.
This script would just write the generated image file, auto-expand the rootfs
and remove the auto-expansion scripts from the rootfs. I'll look into it.

Best regards,
Benoît
Floris Bos Aug. 31, 2015, 12:17 p.m. UTC | #3
On 08/22/2015 10:01 PM, Benoît Thébaudeau wrote:
> Add init scripts to auto-expand the persistent rootfs on the first boot
> to fill the medium.

Wonder if it wouldn't be better to have a package section in buildroot 
for commonly used init scripts like this?

I don't think resizing the rootfs is specific to only this board.
And by making it a package you could do "depends on 
!BR2_TARGET_ROOTFS_INITRAMFS" instead of grep magic in the post build 
script.


Yours sincerely,

Floris Bos
Floris Bos Aug. 31, 2015, 1:25 p.m. UTC | #4
On 08/22/2015 10:01 PM, Benoît Thébaudeau wrote:
> Add init scripts to auto-expand the persistent rootfs on the first boot
> to fill the medium.

Had a look at your script, but think it has more dependencies than 
strictly necessary.

>   
> diff --git a/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
> new file mode 100755
> index 0000000..7f19e7a
> --- /dev/null
> +++ b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +
> +case "$1" in
> +	start)
> +		echo -n "Expanding the root partition: "
> +		BLOCK_DEV="/dev/mmcblk0"
> +		PART_NUM="2"
> +		PART_START="$(parted -ms "${BLOCK_DEV}" unit s p 2>/dev/null | \
> +			grep "^${PART_NUM}:" | cut -d : -f 2 | sed 's/s$//')"
> +		if [ -z "${PART_START}" ]; then
> +			echo "failed"

Note that the existing start sector can also be found in 
/sys/class/block/mmcblk0p2/start
So can remove the parted dependency.

> +		else
> +			fdisk "${BLOCK_DEV}" <<-EOF &>/dev/null
> +				d
> +				$PART_NUM
> +				n
> +				p
> +				$PART_NUM
> +				$PART_START
> +
> +				w
> +			EOF
> +			echo "done"
> +		fi
> +		rm -f /etc/init.d/S22expand-rootpart
> +		if [ "${PART_START}" ]; then
> +			reboot -f
> +			while true; do :; done
> +		fi
> +		exit 2
> +		;;
> +	*)
> +		echo "Usage: $0 start" >&2
> +		exit 1
> +		;;
> +esac
> diff --git a/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs b/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs
> new file mode 100755
> index 0000000..7b3f286
> --- /dev/null
> +++ b/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs
> @@ -0,0 +1,16 @@
> +#!/bin/sh
> +
> +case "$1" in
> +	start)
> +		echo -n "Expanding the root FS: "
> +		resize2fs /dev/mmcblk0p2 &>/dev/null
> +		ret=$?
> +		[ ${ret} -eq 0 ] && echo "done" || echo "failed"
> +		rm -f /etc/init.d/S23expand-rootfs
> +		exit ${ret}
> +		;;
> +	*)
> +		echo "Usage: $0 start" >&2
> +		exit 1
> +		;;
> +esac
> diff --git a/configs/raspberrypi2_defconfig b/configs/raspberrypi2_defconfig
> index 73dc290..2e064e0 100644
> --- a/configs/raspberrypi2_defconfig
> +++ b/configs/raspberrypi2_defconfig
> @@ -3,6 +3,7 @@ BR2_cortex_a7=y
>   BR2_ARM_EABIHF=y
>   BR2_ARM_FPU_NEON_VFPV4=y
>   
> +BR2_TOOLCHAIN_BUILDROOT_GLIBC=y

Why is glibc required?
Isn't it possible to just set the right options (like wchar, largefile) 
for uclibc?

>   BR2_TOOLCHAIN_BUILDROOT_CXX=y
>   
>   BR2_TARGET_GENERIC_GETTY_PORT="tty1"
> @@ -27,6 +28,13 @@ BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2709-rpi-2-b"
>   BR2_PACKAGE_RPI_FIRMWARE=y
>   # BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS is not set
>   
> +BR2_PACKAGE_E2FSPROGS=y
> +BR2_PACKAGE_E2FSPROGS_RESIZE2FS=y
> +BR2_PACKAGE_PARTED=y
> +BR2_PACKAGE_UTIL_LINUX_BINARIES=y
> +
> +BR2_ROOTFS_OVERLAY="board/raspberrypi2/rootfs-overlay"
> +BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi2/post-build.sh"

Why is UTIL_LINUX_BINARIES necessary?
If for fdisk, doesn't busybox provides this as well?



Yours sincerely,

Floris Bos
Benoît Thébaudeau Aug. 31, 2015, 6:53 p.m. UTC | #5
Dear Floris Bos,

On Mon, Aug 31, 2015 at 2:17 PM, Floris Bos <bos@je-eigen-domein.nl> wrote:
> On 08/22/2015 10:01 PM, Benoît Thébaudeau wrote:
>> Add init scripts to auto-expand the persistent rootfs on the first boot
>> to fill the medium.
>
>
> Wonder if it wouldn't be better to have a package section in buildroot for
> commonly used init scripts like this?
>
> I don't think resizing the rootfs is specific to only this board.
> And by making it a package you could do "depends on
> !BR2_TARGET_ROOTFS_INITRAMFS" instead of grep magic in the post build
> script.

That makes sense. It would do "depends on BR2_TARGET_ROOTFS_EXT2" and
select the required target utils. It would also have to ask the user
for the block device to use (or it could autodetect at runtime the
block device on which '/' is mounted). Should this be a new package,
or just new options in the ext2 rootfs menu? I think that the latter
makes more sense for now.

But regarding the "!BR2_TARGET_ROOTFS_INITRAMFS", it would not be
needed at all. This is only on RPi to make user choices easier by not
having to unselect ext4fs and the rootfs overlay besides selecting
initramfs. On RPi, we could just force users to select only one of
them, and say so in readme.txt, and there would be no rootfs overlay
to manage with this feature as new config options.

Best regards,
Benoît
Benoît Thébaudeau Aug. 31, 2015, 7:05 p.m. UTC | #6
Dear Floris Bos,

On Mon, Aug 31, 2015 at 3:25 PM, Floris Bos <bos@je-eigen-domein.nl> wrote:
> On 08/22/2015 10:01 PM, Benoît Thébaudeau wrote:
>> Add init scripts to auto-expand the persistent rootfs on the first boot
>> to fill the medium.
>
>
> Had a look at your script, but think it has more dependencies than strictly
> necessary.

Certainly. I've not tried to optimize dependencies in this patch.

>>   diff --git
>> a/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
>> b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
>> new file mode 100755
>> index 0000000..7f19e7a
>> --- /dev/null
>> +++ b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
>> @@ -0,0 +1,36 @@
>> +#!/bin/sh
>> +
>> +case "$1" in
>> +       start)
>> +               echo -n "Expanding the root partition: "
>> +               BLOCK_DEV="/dev/mmcblk0"
>> +               PART_NUM="2"
>> +               PART_START="$(parted -ms "${BLOCK_DEV}" unit s p
>> 2>/dev/null | \
>> +                       grep "^${PART_NUM}:" | cut -d : -f 2 | sed
>> 's/s$//')"
>> +               if [ -z "${PART_START}" ]; then
>> +                       echo "failed"
>
>
> Note that the existing start sector can also be found in
> /sys/class/block/mmcblk0p2/start
> So can remove the parted dependency.

Yes, but we would have to check how portable this is among all Linux
versions if we want to move that to fs/ext2/ or packages/.

[...]

>> diff --git a/configs/raspberrypi2_defconfig
>> b/configs/raspberrypi2_defconfig
>> index 73dc290..2e064e0 100644
>> --- a/configs/raspberrypi2_defconfig
>> +++ b/configs/raspberrypi2_defconfig
>> @@ -3,6 +3,7 @@ BR2_cortex_a7=y
>>   BR2_ARM_EABIHF=y
>>   BR2_ARM_FPU_NEON_VFPV4=y
>>   +BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
>
>
> Why is glibc required?
> Isn't it possible to just set the right options (like wchar, largefile) for
> uclibc?

Maybe. It was for e2fsprogs or parted. I will check that.

>>   BR2_TOOLCHAIN_BUILDROOT_CXX=y
>>     BR2_TARGET_GENERIC_GETTY_PORT="tty1"
>> @@ -27,6 +28,13 @@ BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2709-rpi-2-b"
>>   BR2_PACKAGE_RPI_FIRMWARE=y
>>   # BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS is not set
>>   +BR2_PACKAGE_E2FSPROGS=y
>> +BR2_PACKAGE_E2FSPROGS_RESIZE2FS=y
>> +BR2_PACKAGE_PARTED=y
>> +BR2_PACKAGE_UTIL_LINUX_BINARIES=y
>> +
>> +BR2_ROOTFS_OVERLAY="board/raspberrypi2/rootfs-overlay"
>> +BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi2/post-build.sh"
>
>
> Why is UTIL_LINUX_BINARIES necessary?
> If for fdisk,

Yes.

> doesn't busybox provides this as well?

Yes, it does, and it's selected in the default Busybox configuration
provided by Buildroot and used on RPi. But I've not checked whether it
is compatible with the one from util-linux regarding the command line
interactions. I will check this.

Best regards,
Benoît
diff mbox

Patch

diff --git a/board/raspberrypi/post-build.sh b/board/raspberrypi/post-build.sh
new file mode 100755
index 0000000..4b92b33
--- /dev/null
+++ b/board/raspberrypi/post-build.sh
@@ -0,0 +1,7 @@ 
+#!/bin/bash -e
+
+# The init scripts used to auto-expand the persistent rootfs on the first boot
+# to fill the medium must not be used with the volatile (initramfs) rootfs.
+if grep "^BR2_TARGET_ROOTFS_INITRAMFS=y$" "${BR2_CONFIG}" &>/dev/null; then
+	rm -f "${TARGET_DIR}"/etc/init.d/{S22expand-rootpart,S23expand-rootfs}
+fi
diff --git a/board/raspberrypi/readme.txt b/board/raspberrypi/readme.txt
index d63e71e..7ee783b 100644
--- a/board/raspberrypi/readme.txt
+++ b/board/raspberrypi/readme.txt
@@ -34,10 +34,13 @@  And for model 2 B:
   $ make raspberrypi2_defconfig
 
 If you want to use a persistent rootfs, the generated ext4 rootfs image fits its
-contents with only a small (but sensible) margin of free space by default, so
-you might want to adjust "Filesystem images"/"ext2/3/4 root filesystem"/
-"size in blocks (leave at 0 for auto calculation)" depending on your needs, then
-skip to "Build the rootfs", below.
+contents with only a small (but sensible) margin of free space by default, but
+it is auto-expanded on the first boot to fill the medium. You can however adjust
+"Filesystem images"/"ext2/3/4 root filesystem"/
+"size in blocks (leave at 0 for auto calculation)" to fit your needs. The
+auto-expansion is controlled by
+board/raspberrypi/rootfs-overlay/etc/init.d/S*expand-root*. Skip to
+"Build the rootfs", below.
 
 For a volatile rootfs, you have to slightly adjust the configuration:
 
diff --git a/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
new file mode 100755
index 0000000..7f19e7a
--- /dev/null
+++ b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart
@@ -0,0 +1,36 @@ 
+#!/bin/sh
+
+case "$1" in
+	start)
+		echo -n "Expanding the root partition: "
+		BLOCK_DEV="/dev/mmcblk0"
+		PART_NUM="2"
+		PART_START="$(parted -ms "${BLOCK_DEV}" unit s p 2>/dev/null | \
+			grep "^${PART_NUM}:" | cut -d : -f 2 | sed 's/s$//')"
+		if [ -z "${PART_START}" ]; then
+			echo "failed"
+		else
+			fdisk "${BLOCK_DEV}" <<-EOF &>/dev/null
+				d
+				$PART_NUM
+				n
+				p
+				$PART_NUM
+				$PART_START
+
+				w
+			EOF
+			echo "done"
+		fi
+		rm -f /etc/init.d/S22expand-rootpart
+		if [ "${PART_START}" ]; then
+			reboot -f
+			while true; do :; done
+		fi
+		exit 2
+		;;
+	*)
+		echo "Usage: $0 start" >&2
+		exit 1
+		;;
+esac
diff --git a/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs b/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs
new file mode 100755
index 0000000..7b3f286
--- /dev/null
+++ b/board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs
@@ -0,0 +1,16 @@ 
+#!/bin/sh
+
+case "$1" in
+	start)
+		echo -n "Expanding the root FS: "
+		resize2fs /dev/mmcblk0p2 &>/dev/null
+		ret=$?
+		[ ${ret} -eq 0 ] && echo "done" || echo "failed"
+		rm -f /etc/init.d/S23expand-rootfs
+		exit ${ret}
+		;;
+	*)
+		echo "Usage: $0 start" >&2
+		exit 1
+		;;
+esac
diff --git a/configs/raspberrypi2_defconfig b/configs/raspberrypi2_defconfig
index 73dc290..2e064e0 100644
--- a/configs/raspberrypi2_defconfig
+++ b/configs/raspberrypi2_defconfig
@@ -3,6 +3,7 @@  BR2_cortex_a7=y
 BR2_ARM_EABIHF=y
 BR2_ARM_FPU_NEON_VFPV4=y
 
+BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
 BR2_TOOLCHAIN_BUILDROOT_CXX=y
 
 BR2_TARGET_GENERIC_GETTY_PORT="tty1"
@@ -27,6 +28,13 @@  BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2709-rpi-2-b"
 BR2_PACKAGE_RPI_FIRMWARE=y
 # BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS is not set
 
+BR2_PACKAGE_E2FSPROGS=y
+BR2_PACKAGE_E2FSPROGS_RESIZE2FS=y
+BR2_PACKAGE_PARTED=y
+BR2_PACKAGE_UTIL_LINUX_BINARIES=y
+
+BR2_ROOTFS_OVERLAY="board/raspberrypi2/rootfs-overlay"
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi2/post-build.sh"
 BR2_TARGET_ROOTFS_EXT2=y
 BR2_TARGET_ROOTFS_EXT2_4=y
 BR2_TARGET_ROOTFS_EXT2_LABEL="rootfs"
diff --git a/configs/raspberrypi_defconfig b/configs/raspberrypi_defconfig
index 58f4cab..7e744f3 100644
--- a/configs/raspberrypi_defconfig
+++ b/configs/raspberrypi_defconfig
@@ -2,6 +2,9 @@  BR2_arm=y
 BR2_arm1176jzf_s=y
 BR2_ARM_EABIHF=y
 
+BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
+BR2_TOOLCHAIN_BUILDROOT_CXX=y
+
 BR2_TARGET_GENERIC_GETTY_PORT="tty1"
 
 # Lock to 4.1 headers as the RPi kernel stable tree is
@@ -10,8 +13,6 @@  BR2_KERNEL_HEADERS_VERSION=y
 BR2_DEFAULT_KERNEL_VERSION="4.1.5"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1=y
 
-BR2_TOOLCHAIN_BUILDROOT_CXX=y
-
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
 BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
@@ -26,6 +27,13 @@  BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2708-rpi-b bcm2708-rpi-b-plus"
 BR2_PACKAGE_RPI_FIRMWARE=y
 # BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS is not set
 
+BR2_PACKAGE_E2FSPROGS=y
+BR2_PACKAGE_E2FSPROGS_RESIZE2FS=y
+BR2_PACKAGE_PARTED=y
+BR2_PACKAGE_UTIL_LINUX_BINARIES=y
+
+BR2_ROOTFS_OVERLAY="board/raspberrypi/rootfs-overlay"
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi/post-build.sh"
 BR2_TARGET_ROOTFS_EXT2=y
 BR2_TARGET_ROOTFS_EXT2_4=y
 BR2_TARGET_ROOTFS_EXT2_LABEL="rootfs"