On 2023-01-26, Cyril Brulebois wrote: > Vagrant Cascadian <vagrant@debian.org> (2023-01-25): >> 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? Nor I, really... so yes, just some extra writes that might be needless in most cases. >> 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?). It is mostly useful with new kernel versions where the module names/dependencies/indirect-dependencies have changed between kernel versions, and I haven't yet figured out which kernel modules go in which .udeb files. Similar for new boards, just trying to figure out which modules are needed at all. The main approach I use is appending all modules (or more selective modules) from /lib/modules/VERSION/ in a cpio archive that is appended to the debian-installer initrd.gz... then compare the lsmod results from a booted d-i... it is not the simplest process with many iteration cycles; any reduction in required steps is a huge benefit for that! It does seem similar to the use-case of loading extra firmware in the installer... appending selective firmwares or all the firmwares to the initrd as a way to make sure it is loadable early in debian-installer. Another use-case for more-free-space-by-default are things like raspberry pi boot firmware, which need to be loaded from the 1st FAT partition on the microSD. Do not recall off the top of my head how large rpi boot firmware is. I have manually copied it onto debian-installer SD card images in the past, possibly doing a partition/filesystem resize dance... >> 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… Ok, good! >> 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. Yeah, figured that was in-process :) >> 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. Yeah, that is basically what I was thinking. The biggest pain point is some boot firmware likes to be on particular raw offsets. Some offsets are incompatible with GPT (allwinner)... some load data from offsets that edge into 4MB (ti?) or even 16MB (rockchip!)... I think most partitioning tools default to creating with a 2MB offset for the first partition. Some models of raspberry pi require the boot firmare to be on the 1st fat partition. As long as you leave those first 16MB clear and don't use GPT partitioning... dare I say it ... I'm not aware of other issues that one would get tripped up on! > 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. Somehow I missed the existance of this, thanks! > 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). Yeah, that would likely cover most use-cases. Some rarer boards might be very limited in boot or installation media selections... "You need a USB port *and* a microSD slot? well, it technically has both... warm up your soldering iron... and get to it!" > 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… I have certainly biased my selection of boards over the years towards ones that did not need it... so cannot offer much help there. Quite a few boards only have wifi (or bluetooth networking?), which usually requires firmware (if supported at all), usually worked around with USB ethernet or USB wifi with free firmware... or USB-gadget ethernet... or a few other exotic options. :) live well, vagrant
Attachment:
signature.asc
Description: PGP signature