BTRFS on the default images complicates customizations with Packer

Requests
1

I was following the instructions to download an Ubuntu 22.04 image and feed that image into Packer (via packer-plugin-arm-image) to upgrade it from 22.04.2 to 22.04.3, install a few extra packages, and configure it for our production environment.

Normally, Packer downloads the image, resizes/expands the filesystem in the image, and then attaches the filesystem to a chroot to perform setup tasks.

The default btrfs filesystem has been a huge headache.

There doesn’t seem to be any way to expand a btrfs filesystem before it’s mounted.

Mounting it on the system before doesn’t seem to be working

sudo losetup --show -f -P output-arm-image/image
sudo mount /dev/loop3p2 /btr
sudo btrfs filesystem show
Label: 'writable'  uuid: b95350b5-5c3a-497c-bb88-85993f53693e
	Total devices 1 FS bytes used 1.70GiB
	devid    1 size 2.37GiB used 2.12GiB path /dev/loop3p2

sudo btrfs filesystem resize +2G /btr
Resize device id 1 (/dev/loop3p2) from 2.37GiB to 4.37GiB
ERROR: unable to resize '/btr': no enough free space

and attempting to manipulate the filesystem in the chroot seems to be failing.

btrfs filesystem show
zoned: ioctl BLKGETZONESZ failed: Function not implemented

btrfs filesystem resize max /
ERROR: unable to check status of exclusive operation: Function not implemented

.
I’m going to grab a stock ubuntu image and start with something like libretech-raspbian-portability to figure out how to get it to boot on a aml-s905x-cc just to get ext4 compatibility back.

Would you consider changing the default filesystem for your images back to ext4?

Would you consider preparing some kind of documentation of how we’re supposed to work with btrfs to make changes to the image before booting it for the first time?

Thanks for your considerations.

2

EXT4 on SBCs is just a bad idea in general. It is significantly slower and less robust on a number of fronts.

The standard tools work fine. The issue you are having is probably with the Linux version on your machine being too old. We recommend using at least 6.1. You also need to make sure you increased the partition size in MBR before resizing. btrfs tools only does the partition, not the partition table.

We will create a demo repo for strapping an image in the future.

1 Like
3

Thank you for the speedy reply @librecomputer! :yellow_heart:

For posterity, the way I managed to increase the size of the image to work with it effectively in packer is as follows:

wget https://distro.libre.computer/ci/ubuntu/22.04/ubuntu-22.04.2-preinstalled-server-arm64%2Baml-s905x-cc.img.xz
xz -d ubuntu-22.04.2-preinstalled-server-arm64+aml-s905x-cc.img.xz
mv ubuntu-22.04.2-preinstalled-server-arm64+aml-s905x-cc.img ./ubuntu.img

truncate --size=+3G ./ubuntu.img

sudo losetup --show -f -P ./ubuntu.img
	'/dev/loop3'

sudo parted /dev/loop3
	print
		'Disk /dev/loop3: 6030MB'
		'part 2 end 2809MB size 2540MB'
	resizepart 2
		'End?  [2809MB]?'
		6030MB
	print
		'part 2 end 6030MB size 5761MB'
	quit

sudo mkdir /btrfs
sudo mount /dev/loop3p2 /btrfs
sudo btrfs filesystem resize max /btrfs
sudo btrfs filesystem show
sudo btrfs check --force /dev/loop3p2

sudo umount /btrfs
sudo losetup -d /dev/loop3
4

Instead of using dd oflag=append, use truncate -s

1 Like
5

Thanks again @librecomputer for the speedy reply!

I updated my earlier example, and now use truncate --size=+3G ./ubuntu.img instead of sudo dd if=/dev/zero bs=1MiB of=./ubuntu.img conv=notrunc oflag=append count=4200 to grow the size of the image. Appreciate all the guidance! :pray:t2:

1 Like