Hello everyone. A typical work week. Let’s go over everything.
BeagleBoard Rust Imager
GitHub Migration
The migration of BeagleBoard Rust Imager to GitHub has now been completed. I have also created v0.0.4 release which brings a lot of fixes and marks the end of the migration.
Eject After flashing
In prior versions of BeagleBoard Rust Imager, I did not eject the SD card after flashing. This would cause weird issues on Linux like not being able to remount the SD card without removing it first. So, the flasher now ejects the SD card after flashing on Linux.
Windows and MacOS still do not eject after flashing.
Windows Customization Fixing
Last week Maique Correa Garcia created an issue regarding flashing failure on Windows. On investigating it further, I found that the customization step (which sets username, hostname, etc) was causing the failure on Windows.
I was able to figure out the initial error quickly. It seems that Windows does not seem to know the size of the SD card which does not have a valid partition table. This meant that when mbrman crate was trying to guess the size by seeking to the end, it would fail on Windows. The solution to that was to only try reading the MBR partition table.
However, after fixing that, I quickly ran into another problem. To give some context, the flow of bb-imager SD card flashing is as follows:
- Open the SD card as std::fs::File in platform dependent manner.
- Write the OS image to the SD Card File.
- Read the MBR table from the SD Card File.
- Open/create
sysconf.txt
in the FAT32BOOT
parition of the SD Card. - Append the entries to
sysconf.txt
.
For some reason, Windows would fail on step 4. In fact, I was not able to read anything from the BOOT
partition on Windows, even though the same code worked fine on Linux.
I did try various things, and tried looking at RPI-imager for inspiration, but was not able to solve the problem. Maybe the problem is something with the way fatfs works.
I then moved onto alternative approaches like having a memory layer on top of the base image which would allow applying customizations in memory, before writing to an SD card. However, this turned out to be a dead end since that would mean needing to have Seek
support in the Os Image file, which is not always possible (since the images can be compressed as XZ). I also did not want to create a temporary copy of the extracted image, since that is problematic on devices with limited storage (The flasher can be run on our boards as well).
In the end, I settled on having a separate flashing implementation for Windows, which creates a temporary copy of the extracted OS Image, applies customizations to this copy, and then writes the modified Os Image to an SD Card. I feel like if your machine is running something as heavy as Windows, it should probably be fine to use 8G of temporary file storage.
Update Crates
I have pushed new versions of the following crates:
Isaac Parker’s Contributions
I would like to thank Isaac Parker for his contributions last week. Hopefully, BeagleBoard Rust Imager will attract more external contributions with time.
UI Code Improvement
I am using iced as the GUI toolkit for BeagleBoard Rust Imager. It is a cross-platform GUI library for Rust, inspired by Elm. Since the UI code in iced is also just normal Rust (as opposed to Slint which has a separate language for UI), it can be a bit daunting for new contributors, especially the ones who only want to contribute to the UI.
While I have no plans to change the toolkit right now, I decided to isolate the code to a single module, to hopefully make the code more readable and maintainable in the long run. Checkout the PR for more details.
Implement File Times for UEFI
I have created a PR to implement fs File Times for UEFI. This involves adding conversion methods from Unix Time to UEFI Time. I would like to thank everyone involved with the algorithms present here.
Ending Thoughts
This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.