Allow to specify image size when using mix firmware.image

Hey there!

This is more of a feature requests to the people knowing the internals of fwup. I’m currently testing some nerves systems in QEMU, therefore I’m using mix firmware.image to write a raw disk image. The problem is that, compared to a real device, the application partition is never expanded to a reasonable size. To workaround this, I currently need to

resize the image (qemu-img resize disk.img +20G)
boot up the image once to create the filesystem
stop the machine again and boot into the gparted live system
resize the partition in gparted
stop the machine and eject the gparted live iso
finally boot up nerves with a reasonable app partition size

I tried to look into the fwup internals, but that’s out of my comfort zone…
I’m imagining something like mix firmware.image disk.img --size 20G to create an image with 20GB in size where the application partition expands like when burning a 20GB SD card. This is probably something that would need to be implemented in fwup itself, e.g. fwup -a -i firmware.fw -t complete -d disk.img --size 20G.

Thanks!

7 comments

/nerves #fwup #mix-firmware

1 272 7

2024-10-02 15:07:12 UTC

Marked As Solved

fhunleth

Co-author of Nerves

I went through your test steps to verify that the final partition was properly expanded on your docker_example repository. Both using qmeu-img and the --max-size option work for me with the fwup PR modifications. I’m going to go ahead and make a fwup 1.11.0 release so that it’s generally available.

Post #7

Also Liked

fhunleth

Co-author of Nerves

@steffend I added support for part of the issue that you ran into since it was trivially reproducible. I expect that this fixes the case when you create the disk.img file and do not use --max-size.

PR is at When writing regular files, check file size to support expansion by fhunleth · Pull Request #231 · fwup-home/fwup · GitHub. Manual build instructions for fwup are at fwup/docs/build_osx.md at main · fwup-home/fwup · GitHub, but no worries if you don’t have time to try it out.

The fact that --max-size doesn’t work is strange since there actually is a unit test that I thought exercised that case. I will investigate that next time I get a spare moment.

Thank you for bringing this to my attention.

Post #6

fhunleth

Co-author of Nerves

What you’re doing sounds like the normal path outside of qemu, but just not automated.

Before I expand on this, if you’re only going to be working in qemu with a 20GB application partition, I’d change the fwup.conf to specify a 20GB partition. To do this, change the line that looks like this:

define(APP_PART_COUNT, 524288)

define(APP_PART_COUNT, 42949672960) # 20GB in units of 512-byte blocks

Normally the fwup.conf files specify a lowest expected size of the destination media. This is for practical reasons since there’s variation in 4GB eMMC parts or maybe you want to accommodate whatever MicroSD or eMMC that is the easiest to buy or maybe you want flash programming to go faster on the manufacturing line.

Regardless of the reason, the application data partition needs to be formatted on the first boot. Nerves does that for you in Nerves.Runtime. However, you could change that code to run gparted to max out the application data partition first and then do the first-time format. This would save the reboot and the manual hassle that you’re going through.

Sadly, we’ve never done this with Nerves. In hindsight, I’m a little surprised that the need hasn’t arisen, but I’m not sure many Nerves users need to max out the application data partition. Or more likely, the change was too device-specific and never contributed upstream. I hope that in your case, adjusting the fwup.conf might be “good enough”.

Post #1