Hi guys.
I am running a balena system, where i have a config file stored in the host boot partition. More precisely i am running a RevPi Core 3 based system, where a config for a kernel module is stored in /mnt/boot/config.rsc
I need some way of editting this particular file from within my container. What are my options?
Best regards,
Mathias
@Mathias host bind mounts are not supported, so there is no way to do this to my knowledge.
Damn… Would there be a way of symlinking it to somewhere that can be accessed ?
I considered symlinking it to /var/lib/docker/volumes/<APP_ID>_resin-data/_data, but the dynamic part of the APP_ID, makes it a bit hard to do more generically.
Is there a way to overcome this issue? Eg. Add some script to the host system, that automatically resolves APP_ID and creates the symlink to /mnt/boot/config.rsc ?
This is a restriction (intended) on the balenaCloud/supervisor side, the OS can bind mount just fine. So I guess if you made modifications to the OS/supervisor then you could circumvent this, but it is really outside of anything I have ever tried to do, sorry.
This is a very old topic, but nonetheless, I’m curious if there was a change regarding the mounting of the boot partition within a container?
What I’m trying to accomplish is to save data outside of the container scope, so even if the containers are removed, the data is still saved on the device. And another use case is creating a file on the boot partition using a PC and executing a function based on that file (just like the ssh file on Raspbian, but with a different use case).
Thanks in advance! Any other solutions are also welcome!
Hi @bversluijs
It seems named volumes would just work for your intended use case. Let us know if it doesn’t so we can look for other alternatives.
Cheers,
Nico.
Hi @ntzovanis,
Thanks for your answer. I’m familiair with the named-volumes, but I can’t access the boot partition (the FAT partition) of the SD card from within the container.
I’d like to use this, because then I can save some data which I can access (or other users can access) when the SD card is inserted in their PC. Or to instruct the device with custom data, for example, adding the file force-ap to force the Wi-Fi chip to function as access point.
Thanks in advance!
Hey @bversluijs I’d like to understand a bit more about the data you’re trying to transfer. This is an unusual request in that usually once an SD card has been installed within a device, it stays there, and any data is extracted via network connection and functions such as turning the WiFi chip into an access point are done via software.
The boot volume is actually very small and is not a recommended place to store data in the first place, which is why it is inaccessible from the container. If you did want a removable storage device I’d recommend using a USB flash drive which you can then format in any way you like and you’d also be able to access it from your container without having to get involved with the partitions of the host operating system. Here’s an example on how to do something similar: Hot plugging USB devices in balenaOS | by Tomás Migone | The Startup | Medium
Additionally, for turning the device into a WiFi access point, we have a few examples on balenaHub which achieve the same thing from a container.
We work on the basis that you should be able to do everything you need to whilst remote to the device, and where removing the SD card is not an option, but let us know if these alternatives help.
Hi @chrisys,
Thanks for your answer! It’s definitely an unusual request, but it’s something we’ve been thinking about for quite a while now.
We have 2 scenario’s:
We have a main web application and API for all our devices. We create multiple custom applications for customers, but they have one thing in common, and that is registering and sending data to our main web application. They register with openBalena, so openBalena knows about the device, but the main web application gives them their unique serial number and some extra information. We’d like to save this data on the boot drive (just like the config.json of Balena), just so all “main” data is stored on the boot drive. This way, we can automatically print stickers when inserting the SD card in a custom printing module or for debugging purposes.
We have an application that uses the WiFi chip as an access point when not connected to WiFi. This is custom software and works great. However, we’d like to have a “force” option, so the device will be forced to use that access point. We’ll implement something that will check if the file exists, force the AP and removes the file (or something like that). This will only be used as a fallback.
Thanks for the extra clarification here!
OK I understand the scenario now. I think the way we would anticipate this to be implemented within the existing architecture would be to link everything based on the UUID of the device. I totally get that you need to add extra information, and so I personally would hold the additional information in a database alongside the UUID so I could query it. Would it not be more practical from your side to be able to print stickers based upon a database entry and UUID rather than having to pull an SD card and insert it into a module? I’m assuming this is some kind of manufacturing or provisioning process? As I mentioned this is kinda unusual because we don’t really consider any physical interaction with the SD card outside of the device itself, since this is a primary storage device, and a lot of our supported devices don’t have removable media as their primary disk. Nevertheless, I will record your request here as a pattern internally so we can track it - just for info, we track all feature requests and feedback to try to establish when the same requirement occurs multiple times so we can appropriately prioritise addressing it.
This is an interesting one too, and again, we’re avoiding interacting with the primary storage device directly, i.e. you shouldn’t have to pull the boot media, modify it and return it to the device to achieve what you want to do. I think I’d try to implement it using a GPIO pin - maybe a jumper or something, although it does mean that the software wouldn’t be able to remove it without some careful logic. Either way, as above, your request here will be logged so we can prioritise if it keeps cropping up. Just wondering, did you find the WiFi connect project? It sounds similar to your application.
If you want to brainstorm anything else to try to get your use case answered let’s keep the discussion going!
Thanks for looking into it Chris!
As a response to your answers:
This is a provisioning process as well as a “replacement” process. But primarily a provisioning process. We’d like to flash and provision more than 1 device at the same time, preferably with balenaEtcher Pro. The biggest issue however is that there’s no way of knowing which SD card has which credentials and information (for example, the unique serial number created while provisioning). The Pi doesn’t have a serial number that’s accessible from software and from the outside world (the 2D sticker doesn’t match the software serial number of the Pi). So we’re looking into other ways, where one of those ways is inserting the SD card and reading out the UUID and printing the sticker for that UUID.
A GPIO was one thing we were thinking of, but the SD card was a more user-friendly option (don’t get me wrong, it’s not super user-friendly, just better than a GPIO for non-techies haha). But maybe we should implement a USB detection script, this is probably more user-friendly than the SD card and most people are familiair with USB sticks 
A USB stick is a much better idea! Good thinking!
The serial number issue is exactly why that feature was implemented on the balenaFin - it has the same ID stored in an EEPROM and accessible via software as printed on the board.
Anyhow, good luck with your project!
I have another use case for the same request: changing the uart_mode for a compulab device by updating the /mnt/boot/extra_uEnv.txt file from within a container.