Recently Raspberry Pi publicly announced the release of their new rpi-image-gen tool, which is advertised as making custom Raspberry Pi OS (i.e. Debian for specific Broadcom SoCs) images in a much more streamlined fashion than with the existing rpi-gen tool, or with third-party solutions. The general idea seems to be that the user fetches the tool from the GitHub project page, before running the build.sh script with parameters defining the configuration file and other options.
The main advantage of this tool is said to be that it uses binary packages rather than (cross-)compiling, while providing a range of profiles and configuration layers to target specific hardware & requirements. Two examples are provided in the GitHub project, one for a ‘slim’ project, the other for a ‘webkiosk‘ configuration that runs a browser in a restricted (Cage) environment, with required packages installed in the final image.
Looking at the basic ‘slim’ example, it defines the INI-style configuration in config/pi5-slim.cfg, but even when browsing through the main README it’s still somewhat obtuse. Under device it references the mypi5 subfolder which contains its own shell script, plus a cmdline.txt and fstab file. Under image it references the compact subfolder with another bunch of files in it. Although this will no doubt make a lot more sense after taking a few days to prod & poke at this, it’s clear that this is not a tool for casual users who just want to quickly put a custom image together.
This is also reflected in the Raspberry Pi blog post, which strongly insinuates that this is targeting commercial & industrial customers, rather than hobbyists.
I wonder how does this thing fares in comparison to buildroot or yocto …
Seems analogous to the OpenWrt ImageBuilder tool – that also makes use of precompiled packages.
“this is targeting commercial & industrial customers, rather than hobbyists.”
That sums up the last 5 years of the RPi. They forgot about the kids and home brewers
when they saw the $$$$$
do you work for free?
are you a charity founded to “enable young people to realise their full potential through the power of computing and digital technologies”?
Boom Roasted
Are you?
Well…it makes sense. Kids and hobbyists more than likely don’t need this as they would simply be leveraging an image built by one of those commercial/industrial customers as they already do. Not that kids and hobbyists can’t use it but there’s probably a steep learning curve.
do they have an option to build an image that mounts root read-only, and logs to a ramdisk or tmpfs? had a consumer device with a custom rpi image in it, and it was still logging to the sd card and it died a couple years later.
crazy to make it easier to make a ‘custom image’ without actually adding the one necessary feature the stock image was missing all along??
+1
You can buy expensive industrial SD micro cards (SLC) that help slow down the SSD write death, but not writing at all unless absolutely necessary is a far better solution.
Anything other than SLC (and still some SLCs) will have writes occasionally occur even when you’re not writing. Reading is not benign on NAND flash. Just the downside of needing buckets of space.
i’d like to know more about this. does it detect that the block has decayed so much that it needs to be rewritten, even while it’s still readable today?
(this isn’t a problem with my pi because it has an enormous 2GB of memory and it never reads anything except right after boot time, but the decay itself might be a problem)
With yocto i would simply add IMAGE_FEATURES += “read-only-rootfs” to my image recipe and rebuild.
I recommend to have a look to NixOS, it’s quite natural to declare this kind of configuration.
+1
All my machines run Nixos nowadays. A bit aggravating to learn, but I can spin a new machine up with all the stuff I want with essentially 0 effort now. The fluidd interface on my rpi that runs my printer is just controlled by an option flag and a short nix file. No more messing around with proprietary installers that, while helpful, only reliably work with fresh installs and break on OS updates.
I wonder if anyone makes a battery-backed SRAM with an SD card interface…
Should check out dietpi, it’s pretty slick and one (Of many) feature is by default it logs to RAM (And never writes to disk, although it does support an hourly write if you want to have logging archives available).
My go-to solution there is to use Alpine Linux, which by default only uses the SD card to boot from. You can persist changes by writing them to the SD card, but otherwise everything runs in RAM. Only unpleasant thing is that it makes 512 MB RPi SBCs feel really restricted, but it’s great for production use.
I have a Pi 1B with no Wifi still, this could be really useful for packing up a custom installation
Having used the raspberry pi web-based provisioning system for CM4’s which was weirdly minimal but worked fine, discovering that everything changed for the CM5 and we now have to build a new system using this rather cryptic thing is a bit of a pain.
And even if it’s aimed at industrial customers it would be nice if they made the documentation a bit less obtuse, unless you’re a large company it’s very hard to know everything about Linux and all the intricacies or changes they keep introducing.
this is the story of pi. they implement something kind of meh, and then they force everyone to endure a drastic change once they figure out their earlier mistakes. they don’t have a back-and-forth with the community, just by fiat: here is something awful, and now here is something different and slightly less awful.