Random Musings

Raspbian on the Raspberry Pi is excellent, but the official image is large and includes various components that are not needed. The devices typically do not have screens, as they are used for playing music, functioning as GPS NTP time servers, or collecting data on power usage, which do not require a screen or graphical user interface. A base installation was created using the Debian installer on a Raspberry Pi, but the process was time-consuming. Cloning the image for new installations is cumbersome, especially since the image is outdated, requiring many package updates. Additionally, identical SSH keys and unique filesystem IDs across machines can lead to confusion when multiple SD cards are connected to the same PC. A more efficient method for generating basic Raspbian installations has been explored. The combination of multistrap and qemu-static enables the creation of a complete, up-to-date installation tree on an x86-64 Ubuntu desktop in a fraction of the time compared to using a Raspberry Pi. The base installation takes about five minutes, especially with package files cached. The use of multistrap allows for cascaded configurations, enabling the definition of a base configuration that can be built upon for specific applications. Improvements to the base configuration can be automatically incorporated into cascaded configurations, eliminating the need to document changes made for application-specific images. A collection of multistrap configuration files and shell scripts has been shared on GitHub for others to utilize. This includes a base installation configuration and a customized installation configuration with MPD. The shell scripts may require customization for individual environments, and it is recommended to read the README. A Debian-derived machine, such as Ubuntu, is necessary for this work, as multistrap relies on apt for package management.

A noteworthy point regarding timezones highlights the inconsistencies in the South Australian timezone (+9:30), which is visually represented on a map showing its misalignment. The timezone is centered at 142.5 °E, while South Australia extends from 129 °E to 141 °E. The map also indicates that part of Indonesia falls within the +9:00 timezone. This discrepancy illustrates the challenges faced by software that assumes timezone offsets from GMT are whole hours.

Lastly, it has been almost two years since the USB keyboard controller project was mentioned. The primary keyboard at home has been driven by various breadboarded versions of the project. On the hardware side, there has been a shift from using PIC to AVR due to unresolved bugs encountered during development.

The Raspberry Pi, a versatile single-board computer, is often utilized for various embedded applications, including media playback and server functionalities. Raspbian, the official operating system, is built on Debian and is tailored for the Raspberry Pi's hardware. However, the full image can be excessive for lightweight applications that do not require a graphical interface. The proposed method of using multistrap allows developers to create minimal installations tailored to specific needs, significantly reducing setup time and resource usage.

Multistrap is a tool that facilitates the creation of chroot environments, allowing for the installation of Debian packages in a controlled manner. By leveraging qemu-static, it is possible to emulate the Raspberry Pi architecture on a more powerful x86-64 machine, streamlining the installation process. This approach not only saves time but also ensures that the latest packages are included in the installation, reducing the need for extensive updates post-installation.

Cascaded configurations in multistrap enable users to build a hierarchy of setups, where a base configuration serves as a foundation for more specialized installations. This modularity simplifies maintenance and updates, as improvements to the base configuration can be propagated to all dependent configurations automatically. The shared GitHub repository provides a valuable resource for users looking to implement similar setups, with sample configuration files and scripts to assist in the process.

Overall, the combination of multistrap, qemu-static, and a structured configuration approach enhances the efficiency of deploying Raspbian on Raspberry Pi devices, making it a practical solution for various applications. The ongoing USB keyboard controller project illustrates the iterative nature of hardware development, highlighting the shift to AVR for improved reliability and functionality.Rasbian on the Raspberry Pi is great, but the official image is large and includes all sorts of stuff I don`t need (my Pis don`t generally have screens as I use them for playing music, or being GPS NTP time servers, or collecting data on my power usage not things which need, for example, a screen and a gui!). I did manage to cobble together a base install using the Debian installer on a Pi, but it took a loooong time, and cloning this image every time I want to do a new one is a bit of a pain; for one thing the image is quite old now so apt-get has to update a lot of packages to bring it up to current, and for another the machines all get the same ssh keys, and the filesystems all have the same unique` IDs (which tends to confuse things if you simultaneously plug 2 of the resulting SD cards into the same PC!). So I`ve been mucking around with a better way to generate basic Rasbian installs for the Pi. I`ve discovered that the combination of multistrap and qemu-static allows the building of a complete up-to-date installation tree on my x86-64 Ubuntu desktop in a tiny fraction of the time it would take to do the same thing on a Pi.

For my base install (which is indeed very basic) my machine takes about 5 minutes (with the packages files already in my apt-cacher-ng cache). Sometimes the longest step is copying all the data to the SD card! One of the nice things about using multistrap to do this is the ability to make cascaded configurations so I can define a base configuration which works for me, and then have other configurations which build on top of it for specific applications.

If I make improvements to the base, then regenerating one of the cascaded configurations will incorporate the improvements automatically. It also means I don`t have to remember or document what I did to the base image to get the application-specific image, because it is all there in the configuration file and associated scripts.

I`ve put a small collection of multistrap configuration bits and attached shell scripts up on github if anyone else wants to have a play with it. It includes one configuration file for a base install, and one for a customized install including MPD.

There`s a handful of shell scripts which do most of the work beyond getting the packages extracted these will almost certainly need customizing for your environment. You will definitely want to read the README. Oh, and you`ll need a Debian-derived (eg Ubuntu) machine to do the work, since multistrap relies on apt to do all the package work.

There`s a rather nice article about timezones and how wrong they can be, which shows clearly just how broken the South Australian timezone (+9:30) is. If you look at the beautiful map, you`ll notice that all of South Australia (and Northern Territory if it comes to that) is in red; that is, behind the timezone.

At 15 ° of longitude per hour (360 ° in 24 hours), the +9:30 timezone would be centred at 142. 5 ° E. South Australia extends from 129 ° E to 141 ° E (see wikipedia ). If you look closely at the map, you`ll see part of Indonesia (West Papua) which is on the +9:00 timezone. You can see that the white coloured section (the centre of the timezone, 135 ° E) is roughly in line with the centre of South Australia.

Surely this would make more sense All that broken software which assumes that timezone offsets from GMT are always a whole number of hours would just work! (I recently came across broken software which did in fact have non-integer timezones available. Well, sort of. They had a special case for India on +5:30, but that was all. ARRGGHH!). It has been nearly two years since I mentioned the USB keyboard controller project. For most of that time, my primary keyboard at home has been driven by one or another bread-boarded incarnation of it.

A few major points on the hardware side: I`ve given up on the PIC and gone back to AVR. I ended up with some bugs which I couldn`t resolve, a 🔗 External reference