1:06 p.m.
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