Hi Vagrant,
Thanks for your feedback!
Vagrant Cascadian <vagrant@debian.org> (2023-01-25):
> Well, empty space does compress quite well, at least!
:D
> 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 have no idea how much people care how much time is spent copying things
around, but I suppose that at least for those repeatedly copying things
around (e.g. for debugging purposes), more writes could mean accelerated
wear-and-tear?
(The only things in that area I'm familiar with is Pi images that contain
full-blown systems, which are in the 1-2G ball park already.)
> 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?
Yeah, I've seen you notice that you were aiming to allow for a little more
room, when you bumped sizes, rather than increasing them minimally. I'm
just wondering whether it makes sense (how often is that really useful?).
> 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
That looks much easier than anything we could come up with if we were
trying to concatenate 3 parts (the third one would need to be created
depending on the first one — fat or ext2). Requiring mount could be
considered a tad dangerous, but big red warnings and all that…
> 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)
I'm working on it right now, trying to also reduce code duplication in
debian-cd for easier long-term maintenance. I should have some proof of
concept by tomorrow, but we need to find a better location that under
unrelease/, so it won't be deployed right away.
> 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.
Yes!
> Another option would be to use a growable filesystem, and then grow it
> to whatever size needed? Are FAT filesystems reasonably growable?
Just to be sure, are we talking about something like the following?
- cat both parts as usual to get complete_image.img (via README);
- fallocate to make it bigger for those who want more stuff;
- fdisk to extend the partition to the new end of disk (making sure
not to change the beginning, firmwares are picky as you know; not
lose the signature, etc);
- fatresize or resize2fs to extend the filesystem;
- mount, copy, umount;
- hope that none of this changed tricky parts that would break the
board-specific firmare/bootloader/config/etc.
I've used fatresize on FAT32 partitions in the past (for USB storage
on Intel-based machines, but nothing firmware/bootloader-related) quite
successfully. A quick grep through its source report this claim:
The FAT16/FAT32 non-destructive resizer.
All of this (if it works) seems reasonable enough, or at least I don't
think should be a big issue for experienced users.
But I suspect less advanced users wanting to toy with an ARM board would
probably just follow the README to prepare the installer image, and rely
on an extra USB stick to hold the firmware part (and rely on mountmedia).
But again, I have no idea how common it is for the boards we support in
the installer to require loading firmware files during the installation
process…
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature