On 2023-01-25, Cyril Brulebois wrote: > Cyril Brulebois <k...@debian.org> (2023-01-24): ... > # SD card images (might also be applicable to the upcoming ChromeOS images) > > Looking at how those images are built, it seems we have a predefined, > per-arch image size (150M or 200M), and gen-hd-image that's called in two > modes: firmware or partition. The former takes care of the board-specific > part (e.g. firmware.a64-olinuxino.img.gz) while the latter takes care of > the board-independent part (partition.img.gz). Both can be concatenated > with the following command as documented in the README: > > https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/images/netboot/SD-card-images/README.concatenateable_images > > zcat firmware.<board_name>.img.gz partition.img.gz > complete_image.img > > And that works, generating an image with a single fat16, fat32, or ext2 > partition with contents merged together, because of the pre-defined image > size. > > We could think about bumping the image size, but given the size of the > firmware directory (as in containing the firmware-* packages and metadata, > not the board-specific firmware files), this would seem like a waste of > space for all those not needing firmware files (probably requiring twice > the current size to make sure everything fits)…
Well, empty space does compress quite well, at least! Though a larger image would take a bit longer and burn a few extra write cycles for those who did not need to actually use the space. I do not know that we are all that size-constrained; it is hard to come by USB sticks or SD cards that are less that 4GB these days. So even bumping the image size to 500MB or even 1GB does not seem unreasonable to me... I would rather err on the side of slightly larger than currently needed; maybe there are use-cases I am not considering? Another option is to concatenate the firmware part directly to the initrd image manually, though it is a bit of a cumbersome process... soemthing like: gunzip partition.img mount -o loop partition.img /mnt cat kernelfirmware.cpio.gz >> /mnt/initrd.gz umount /mnt zcat firmware.BOARD.gz partition.img > complete.img Though I realize that is quite a few extra steps for an already slightly complicated manual two-part SD card image process... but it could probably be scripted; it is not absurdly complicated. (presuming you have the kernel-firmware.cpio.gz creation sorted out) This technically only requires changing the size of the partition.img to make more room for the kernel firmware image, but otherwise would be identical to the current process for those who did not need to add the firmware. Another option would be to use a growable filesystem, and then grow it to whatever size needed? Are FAT filesystems reasonably growable? Thanks for all your work on this! live well, vagrant
signature.asc
Description: PGP signature
