{"id":11252,"date":"2025-03-23T09:27:32","date_gmt":"2025-03-23T16:27:32","guid":{"rendered":"https:\/\/jasonsblog.ddns.net\/?p=11252"},"modified":"2025-03-23T09:27:32","modified_gmt":"2025-03-23T16:27:32","slug":"introducing-rpi-image-gen-build-highly-customised-raspberry-pi-software-images","status":"publish","type":"post","link":"https:\/\/jasonsblog.ddns.net\/index.php\/2025\/03\/23\/introducing-rpi-image-gen-build-highly-customised-raspberry-pi-software-images\/","title":{"rendered":"Introducing Rpi-Image-Gen: Build Highly Customised Raspberry Pi Software Images"},"content":{"rendered":"\n

An interesting new project from the Raspberry Pi Foundation, but this one paragraph caught my interest as it implied some legislative requirements forthcoming, at least to begin with in the UK. With the move to have Windows and macOS lockdown what software you can run<\/a> matching iOS and Android, coopting opensource projects, moving to this AI garbage… What do they have planned to limit your use of the internet and computers? Microsoft’s AI requirement and taking snapshots of your screen<\/a> periodically shows their hand at surveillance of what you’re doing, being indexed and searchable. And security vulnerabilities and hacking is the impetus for a control scheme being forced on end users, as the WEF has been fearmongering cyberattacks<\/a> for some time, as well as propagandizing it in movies and television… If you think I’m stretching, look at the WEF brain transparency presentation in the Microsoft AI link above. <\/p>\n\n\n\n

\n

Auditing software, and being able to generate a list of the security vulnerabilities of a deployed device, is critically important. A Software Bill of Materials (SBOM) in a standardised format should be one of the output artefacts of any software build system. rpi-image-gen produces an SBOM for every build and provides output format customisation options to the user, allowing them to feed that into other systems \u2014 for example, to generate a list of CVEs. By providing an SBOM and tracking security vulnerabilities, you are helping to give consumers of your image confidence in the software deployed on their device. In the not-too-distant future, there will be legislative requirements in this area<\/strong>, and we believe Raspberry Pi is well placed in the industry to provide customers with what they need.<\/p>\n<\/blockquote>\n\n\n\n

https:\/\/www.raspberrypi.com\/news\/introducing-rpi-image-gen-build-highly-customised-raspberry-pi-software-images\/<\/a><\/p>\n\n\n

<\/div><\/div><\/div>\n\n\n

By Matt Lear<\/p>\n\n\n\n

When it comes to software on Raspberry Pi devices, one size doesn\u2019t always fit all. Raspberry Pi OS<\/a> is ideal for many applications, but we recognise that it doesn\u2019t suit every use case or deployment model, particularly in a product that has a specific purpose. If you\u2019re building an embedded system or an industrial controller, you\u2019ll need complete control over the software resident on the device, and home users may wish to build their own OS and have it pre-configured exactly the way they want. For developers and organisations that require a custom software image, a flexible and transparent build system is essential; to support these customers, we have created rpi-image-gen<\/a>, a powerful new tool designed to put you in complete control of your Raspberry Pi images.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

rpi-image-gen is an alternative to pi-gen<\/a>, which is the tool we use to create and deploy the Raspberry Pi OS distribution. rpi-image-gen is designed to generate highly customised software images for Raspberry Pi devices, and offers a very granular level of control over file system construction and software image creation.<\/p>\n\n\n\n

Why we created rpi-image-gen: a purpose-built solution for our customers<\/h2>\n\n\n\n

There are a number of community-maintained build systems which already exist and which support Raspberry Pi devices. These offer several customisation options and are used by many Raspberry Pi customers today, so you may be wondering why we decided to create our own. rpi-image-gen was most definitely not born out of a \u2018not-invented-here\u2019 mindset; there are valid reasons why our customers would benefit from a tool designed, from scratch, to provide the flexibility we know they need to deploy software on their products.<\/p>\n\n\n\n

By supporting a build system that has the benefits of Raspberry Pi OS distribution packages, we have one set of sources to maintain, which means that when software gets improved or fixed in one place, it\u2019s automatically made available everywhere. Consolidating around centralised package-based delivery of software and updates makes a lot of sense. In addition, being able to help reduce software build time, provide guaranteed ownership of support, and reuse standard methodologies to ensure authenticity of software were all of paramount importance, and among the reasons why we created a new home-grown build tool for Raspberry Pi devices.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

How rpi-image-gen works: a new approach to building images<\/h2>\n\n\n\n

Similar to pi-gen, rpi-image-gen leverages the power, reliability, and trust of installing a Debian Linux system for the device. However, unlike pi-gen, rpi-image-gen introduces some new concepts which serve to dictate the build footprint and installation.<\/p>\n\n\n\n

Specifying your image: profiles, image layouts, and config files<\/h3>\n\n\n\n

A profile<\/em> is essentially a collection of descriptive layers which group together Debian packages and installation operations. These collections can be selectively picked and customised further, and form the foundation of the software image. The image layout<\/em> describes how the output software binary image will be created and laid out on-disk for programming into the device, including the types of file systems, partition table entries, image formats, etc. A config file<\/em> is a \u2018top level\u2019 text file, written in easy-to-understand .ini<\/code> syntax, which defines the profile and image layout that rpi-image-gen uses to build the device image.<\/p>\n\n\n\n

The config file is typically associated with the underlying device hardware and product, so it can specify applicable attributes accordingly: for example, defining the sizes of individual partition images to match the onboard eMMC size, or using a layout which uses particular mount options for file systems, fine tuning options exposed by lower levels, or selecting a specific Raspberry Pi device class to target. Likewise, different derivatives of config files can be used to tailor the installation to the product\u2019s functional requirements. You could, for example, utilise a Bluetooth audio layer to pull in device support; or use a particular layer to add in a minimal Wayland desktop which runs in a kiosk mode, to install a default set of containers, to seed a default environment for distribution to third-party developers, and so on. There is no limit to the possibilities.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Example builds: custom images in action<\/h2>\n\n\n\n

There is a small number of examples<\/a> in the tree which demonstrate different use cases of rpi-image-gen. All create bootable disk images and serve to illustrate how one might use rpi-image-gen to create a bespoke image for a particular purpose. The number of examples will grow over time and we welcome suggestions for new ones. Let\u2019s pick two of them and take a closer look: slim and webkiosk. <\/p>\n\n\n\n

slim: create a small, lightweight image<\/h3>\n\n\n\n

slim<\/a> is an incredibly simple illustration of how to create a lightweight image containing a small number of essential packages that will boot on your Raspberry Pi. This image alone is not incredibly useful, but it shows how a custom configuration can be created and built upon in order to keep the size of the file system minimal. A small number of layers are pulled in by the profile (e.g. Debian base, core utilities, Linux kernel, and boot firmware), then a Raspberry Pi OS\u2013style disk image is created with some headroom to run apt update<\/code> and install a few packages.<\/p>\n\n\n\n

webkiosk: create an image that boots into a browser kiosk mode<\/h3>\n\n\n\n

webkiosk<\/a> builds upon a profile that, once again, pulls in a minimal number of components. It then adds, via a custom hook, other packages which are needed to support running the Chromium web browser in kiosk mode under Wayland. This image auto-boots into the browser using a custom systemd<\/code> service and runs it full-screen with VT switching disabled. The Wayland compositor used (Cage) is a single-instance compositor, which is ideal for deployments that need to prevent user intervention via keyboard or mouse; for example, users should not be able to switch out of one window and into another via standard keyboard shortcuts.<\/p>\n\n\n\n

\"\"
Install it onto an SD card using Raspberry Pi Imager<\/a>; here\u2019s one we made earlier<\/figcaption><\/figure>\n\n\n\n

What you leave out is just as important as what you include: how to control both<\/h2>\n\n\n\n

As well as being able to configure the build and device image the way you want, it\u2019s important to be able to exclude from the package-based installation things that would otherwise be installed as part of the profile. One way to do this is via dpkg<\/code> options, which are supported by the tool underpinning rpi-image-gen. The mmdebstra<\/code>p engine drives device file system creation, with bdebstrap<\/code> above it providing a highly customisable framework and a descriptive textual representation of layers. A layer is written in YAML, which is human-readable and easy to understand. Excluding assets from a package install is as easy as using dpkg --path-exclude<\/code> and\/or --path-include<\/code> options in YAML for the particular layer that is pulled in by the profile.<\/p>\n\n\n\n

Security, trust, and compliance: what this means for our customers<\/h2>\n\n\n\n

Auditing software, and being able to generate a list of the security vulnerabilities of a deployed device, is critically important. A Software Bill of Materials (SBOM) in a standardised format should be one of the output artefacts of any software build system. rpi-image-gen produces an SBOM for every build and provides output format customisation options to the user, allowing them to feed that into other systems \u2014 for example, to generate a list of CVEs. By providing an SBOM and tracking security vulnerabilities, you are helping to give consumers of your image confidence in the software deployed on their device. In the not-too-distant future, there will be legislative requirements in this area, and we believe Raspberry Pi is well placed in the industry to provide customers with what they need.<\/p>\n\n\n\n

One advantage of creating anything from scratch is the ability to make it exactly the way you want \u2014 to own it and shape it over time. We like to think that we understand the needs of our customers well, and we try to put them at the forefront of a significant part of our software development effort. It\u2019s important that customers can trust us to help them resolve their problems, and can rely on our support for their product deployment. We\u2019re proud to offer them a Raspberry Pi-supported build system which generates auditable software for their products in a way that is flexible and efficient for their engineering teams to use.<\/p>\n\n\n\n

Visit the rpi-image-gen GitHub repository<\/a> to get started. There, you\u2019ll find documentation and examples to guide you through creating custom Raspberry Pi images. We encourage you to explore the repository and provide feedback to help us improve the tool further.<\/p>\n","protected":false},"excerpt":{"rendered":"

An interesting new project from the Raspberry Pi Foundation, but this one paragraph caught my interest as it implied some legislative requirements forthcoming, at least to begin with in the UK. With the move to have Windows and macOS lockdown what software you can run matching iOS and Android, coopting opensource projects, moving to this […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7],"tags":[],"class_list":["post-11252","post","type-post","status-publish","format-standard","hentry","category-tech","category-world"],"blocksy_meta":[],"featured_image_src":null,"author_info":{"display_name":"Jason","author_link":"https:\/\/jasonsblog.ddns.net\/index.php\/author\/jturning\/"},"_links":{"self":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts\/11252","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/comments?post=11252"}],"version-history":[{"count":1,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts\/11252\/revisions"}],"predecessor-version":[{"id":11253,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts\/11252\/revisions\/11253"}],"wp:attachment":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/media?parent=11252"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/categories?post=11252"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/tags?post=11252"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}