-------- Forwarded Message --------
Subject: How we can make CoreOS Image support AArch64?
Date: Wed, 29 Jul 2020 14:09:09 +0800
From: Fu Wei <wefu(a)redhat.com>
To: Peter Robinson <perobins(a)redhat.com>, coreos(a)lists.fedoraproject.org
Recently, We have tried to make Fedora 32 CoreOS image by coreos-assembler successfully.
git clone https ://github.com/coreos/coreos-assembler.git
we didn't need to do any modification on coreos-assembler, so that means all the necessary part of Fedora Support have been upstream.(If I misunderstand this, please correct me )
But it seems we only have x86 image can be download here: https://getfedora.org/coreos/download
So How we can make AArch64 image available on this website?
we plan to make some effort on this, could you help me?
Senior Software Engineer
Red Hat Software (Beijing) Co.,Ltd.
Hello Silverblue and IoT teams. The FCOS team got together with Fedora releng last week to discuss the
issue regarding package layering that periodically plagues us (https://github.com/coreos/fedora-coreos-tracker/issues/400).
The solution we believe will help all OSTree based editions involves creating an archive repo where
any package that has made it to the Fedora stable repositories can be accessed at a later time. In
general, we think this should solve the problem because we should be able to install packages that
won't require updating the base layer.
- help solve the same problem for Fedora CoreOS, Fedora Silverblue, and Fedora IoT
- don't add to mirror network requirements
- i.e., store/host the content somewhere else. AWS is a candidate here.
- keep traditional systems behavior the same
- don't enable archive repo(s) by default on non-ostree distributions
Since it can take a long time to create repos for large package sets we may end up creating more than
one repo that gets updated at different cadences. For example:
- One that gets updated weekly
- all packages obsoleted before X date
- large package set, so we run it once a week
- One that gets updated nightly
- all packages obsoleted after X date
- small package set, so we can run it nightly
This is still a work in progress and the design may take a few turns as we work out the details and/or
find new information.
Having this new repository will help us in Fedora CoreOS as we have a stable stream that lags behind
Fedora stable repos. It should also help Fedora Silverblue when they move to a release cadence that
doesn't match the bodhi updates repos. I'm not sure how much of a problem this currently is in Fedora
IoT, but I imagine Fedora IoT has similar problems.
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2020-07-15/fedora_core...
Meeting started by dustymabe at 16:29:09 UTC. The full logs are
* roll call (dustymabe, 16:29:12)
* Action items from last meeting (dustymabe, 16:32:42)
* bgilbert enabled LogBot (bgilbert, 16:33:06)
* jdoss and dustymabe were able to pin podman to 1.9.3 in
testing-devel stream. the next stream will contain podman 2.x and we
can gather feedback on the update from users there. (dustymabe,
* Discussion: OKD release schedule and blocking FCOS releases on OKD e2e
tests (dustymabe, 16:37:14)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/562
* OKD will release roughly bi-weekly, alternating with the FCOS
releases (lorbus, 16:38:45)
* AGREED: The group agrees it would be a good idea to trigger OKD
tests on new builds of FCOS so we can get feedback about breakage
sooner than later. It's possible the breakage is a regression in the
base OS OR a desired change that OKD needs to adapt for. Either way
running tests will help both FCOS and OKD. (dustymabe, 16:56:06)
* Change deadline for FCOS releases (dustymabe, 16:59:54)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/571
* AGREED: In order to get a little more clarity and reliability for
our releases we'd like to implement a guideline that if changes
don't land by the previous Friday of a scheduled release then we
won't hold the release for that change. This gives the release
wrangler some clear guidelines about when it's safe to proceed with
running the release. (dustymabe, 17:09:38)
* ACTION: bgilbert to update the ticket (bgilbert, 17:10:18)
* forwarding NIC renaming udev rules from the initramfs (dustymabe,
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/553
* AGREED: We haven't seen a lot of users needing this functionality
just yet so we'd prefer to wait to add that functionality. What we
have for propagating networking karg information a bit hacky, but is
required for now in order to not require every user who needs static
networking to specify networking information twice. We'd prefer to
not further the behavior for now. (dustymabe, 17:25:22)
* open floor (dustymabe, 17:26:30)
* if you want to see OKD running on FCOS (and a general overview of
FCOS) check out the presentation we did yesterday:
https://www.youtube.com/watch?v=ErF_0xQmxrU (dustymabe, 17:28:13)
* LINK: https://github.com/coreos/coreos-installer/releases/tag/v0.3.0
Meeting ended at 17:31:40 UTC.
* bgilbert to update the ticket
Action Items, by person
* bgilbert to update the ticket
People Present (lines said)
* dustymabe (96)
* bgilbert (37)
* lorbus (35)
* zodbot (22)
* jlebon (18)
* lucab (10)
* cverna (6)
* cyberpear (6)
* slowrie (6)
* jdoss (3)
* miabbott (2)
* siddharthvipul (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot