I apologize if these are clearly answered elsewhere, but I had several questions about developing using Fedora IoT and deploying Fedora IoT.
Before asking the questions, though, I do have to say "thank you" for the work on this. The ideas and approaches look innovative and it is nice to have this sort of development in a community project.
First, if I wanted to try out Fedora IoT on a piece of hardware with a custom kernel, what would be the right method to try out the custom kernel? In the past when using Fedora ARM, I could control the kernel that U-Boot loaded directly. With Fedora IoT, though, it isn't clear to me how to try this out without breaking the boot process.
Likewise, how would I try out some custom boot loaders and device trees? I am assuming that the process of trying these out with Fedora IoT might be similar to using a custom kernel. I am looking at a few different aarch64 devices and boards with special built-in security features that could be used at boot time for validating firmware and software (without a TPM). Further, there will likely be a need to support some custom I2C and SPI devices on these boards, which would require (based on past experience with arm7hl boards) custom device trees.
I have read through the libostree documentation (https://ostreedev.github.io/ostree/) and it gave me a few ideas on how individual files are managed, but I am still coming up to speed on libostree systems.
One additional question is how would I set up a repository mirror for Fedora IoT so that I could feed updates to IoT devices that are on a private network (i.e., don't have direct access to the usual Fedora IoT repositories)?
I am assuming that I would also have to also update the repository information somehow on the IoT devices themselves. Guidance on how to do that would also be greatly appreciated.
Along these lines, I would like to control the particular updates that roll into the update repository so that only those updates/snapshots that are tested and work well on the target hardware make it into the local mirrored update repository. Is there a simple way to manage this?
Finally, how does Fedora IoT handle transitions in the base Fedora distribution. Does it simply move forward (for example, from Fedora 33 to Fedora 34) on Fedora IoT devices without additional intervention or does the person managing the Fedora IoT device have to explicitly do something to transition from a Fedora IoT 33 base to a Fedora IoT 34 base, for example?
I apologize for all of the questions and if I missed it in the documentation.
Thanks!
Paul
Hi Paul,
I apologize if these are clearly answered elsewhere, but I had several questions about developing using Fedora IoT and deploying Fedora IoT.
There's never a need to apologize for asking questions, it probably means a project needs to improve their docs ;-)
Before asking the questions, though, I do have to say "thank you" for the work on this. The ideas and approaches look innovative and it is nice to have this sort of development in a community project.
First, if I wanted to try out Fedora IoT on a piece of hardware with a custom kernel, what would be the right method to try out the custom kernel? In the past when using Fedora ARM, I could control the kernel that U-Boot loaded directly. With Fedora IoT, though, it isn't clear to me how to try this out without breaking the boot process.
It's not straight forward to do this at the moment unfortunately, especially if the device can't be booted with with the default kernel. It's kind of on the todo list but unfortunately with all the things on the list it's not the highest of priorities.
Likewise, how would I try out some custom boot loaders and device trees? I am assuming that the process of trying these out with Fedora IoT might be similar to using a custom kernel. I am looking at a few different aarch64 devices and boards with special built-in security features that could be used at boot time for validating firmware and software (without a TPM). Further, there will likely be a need to support some custom I2C and SPI devices on these boards, which would require (based on past experience with arm7hl boards) custom device trees.
This is more straight forward, we require UEFI and the firmware needs to provide either DT or ACPI to the kernel. What ever firmware provides that doesn't matter to us and should work.
I have read through the libostree documentation (https://ostreedev.github.io/ostree/) and it gave me a few ideas on how individual files are managed, but I am still coming up to speed on libostree systems.
One additional question is how would I set up a repository mirror for Fedora IoT so that I could feed updates to IoT devices that are on a private network (i.e., don't have direct access to the usual Fedora IoT repositories)?
There's a few ways you can achieve that, but basically it's all just http based, so you proxy it, or mirror it's as part of the Fedora mirror system and there can be private mirrors in it, but then the endpoints would need to at least be able to query the mirror endpoints.
We're also planning on being able to be able to retrieve them via DNS SRV records but again, not quite there yet.
I am assuming that I would also have to also update the repository information somehow on the IoT devices themselves. Guidance on how to do that would also be greatly appreciated.
That ones easy :-)
All the config is in /etc/ostree/remotes.d/fedora-iot.conf
It can also be updated with a command like: ostree remote delete fedora-iot ostree remote add --set=gpg-verify=true --set=gpgkeypath=/etc/pki/rpm-gpg/ --set=contenturl=mirrorlist=https://ostree.fedoraproject.org/iot/mirrorlist fedora-iot 'https://ostree.fedoraproject.org/iot'
Along these lines, I would like to control the particular updates that roll into the update repository so that only those updates/snapshots that are tested and work well on the target hardware make it into the local mirrored update repository. Is there a simple way to manage this?
Not currently, one way to handle it would be through branches, there's investigation being done into a bunch of this sort of thing but there's nothing that's usable as yet.
Finally, how does Fedora IoT handle transitions in the base Fedora distribution. Does it simply move forward (for example, from Fedora 33 to Fedora 34) on Fedora IoT devices without additional intervention or does the person managing the Fedora IoT device have to explicitly do something to transition from a Fedora IoT 33 base to a Fedora IoT 34 base, for example?
We have 3 streams, stable, devel and rawhide as documented in the link below, stable is the latest stable Fedora release, devel is the release that's headed to stable, and rawhide is the main Fedora devel. We actively move to the latest stable with each release. We could possibly do more nuanced streams but to date we've only had a small team so it's a matter of resources to deal with all the pieces and do actual development and enhancements.
https://docs.fedoraproject.org/en-US/iot/rebasing/
I apologize for all of the questions and if I missed it in the documentation.
No, they were good questions, I would be happy for suggestions to improve the documentation too.
Regards, Peter
-
Paul Graham -
Peter Robinson