Closed dustymabe closed 3 years ago
Per the meeting today, I tracked down the two duplicate systemd-resolved issues https://github.com/systemd/systemd/issues/16531 and https://github.com/systemd/systemd/issues/9397 that I personally ran into when trying to setup DNS over TLS on Fedora Workstation. They seem to be fixed in systemd v246 which is currently in F33.
I think we are good on including systemd-resolved unless others have any other things that might be a blocker.
FYI, the rpmdb migration to sqlite will likely affect FCOS users with layered packages: https://bugzilla.redhat.com/show_bug.cgi?id=1876194#c3
One thing we could do to ease this is to:
echo %_db_backend bdb > /etc/rpm/macros.db
)stick with BDB in the first f33 FCOS release (according to https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb#Release_Notes, that's just echo %_db_backend bdb > /etc/rpm/macros.db)
Hmm yes though I think we should make this a treefile option, something like:
rpmdb: bdb|sqlite
.
Cross-linking: https://github.com/fedora-silverblue/issue-tracker/issues/73
Cross-linking: fedora-silverblue/issue-tracker#73
Luckily I did some digging and found a bug (that was already closed so it wasn't showing up in my initial search) for this that already has an update out to fix the problem: https://bugzilla.redhat.com/show_bug.cgi?id=1868215
FYI, the rpmdb migration to sqlite will likely affect FCOS users with layered packages: https://bugzilla.redhat.com/show_bug.cgi?id=1876194#c3
One thing we could do to ease this is to:
- stick with BDB in the first f33 FCOS release (according to https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb#Release_Notes, that's just
echo %_db_backend bdb > /etc/rpm/macros.db
)- make that release a barrier
- unstick BDB
We discussed this at the community meeting on Wednesday.
* AGREED: we'll keep bdb for the rpm database for at least the first
release of Fedora 33 and then make the transition with a barrier in
the fedora 33 timeframe (dustymabe, 16:53:20)
@jlebon opened a ticket to track some of the work and the eventual migration: https://github.com/coreos/fedora-coreos-tracker/issues/623
Executing the steps to move to a new major Fedora version.
Updating this repo:
1. bump `releasever` in `manifest.yaml`
2. update the repos in `manifest.yaml` if needed
3. run `cosa fetch --update-lockfile`
4. PR the result
Update server changes:
1. Set a new update barrier for N-2 on all streams.
See [discussion](https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629).
CoreOS Installer changes:
1. Update CoreOS Installer to know about the signing key used for the
future new major version of Fedora (N+1). Note that the signing
keys for N+1 won't get created until releng branches and rawhide
becomes N+1.
Release engineering changes:
1. verify that the `f${releasever}-coreos-signing-pending` Koji tag has
been created (this should have already been done by releng scripts on
branching)
2. `koji untag` N-2 packages from the pool (at some point we'll have GC
in place to do this for us, but for now we must remember to do this
manually or otherwise distRepo will fail once the signed packages are
GC'ed). For example:
- `koji list-tagged coreos-pool --quiet | grep fc30 | cut -f1 -d' ' | sort | uniq`
- Sanity-check the output, then pipe it to `xargs koji untag-build coreos-pool`
Updating this repo:
1. bump `releasever` in `manifest.yaml`
2. update the repos in `manifest.yaml` if needed
3. run `cosa fetch --update-lockfile`
4. PR the result
This is done over in:
Update server changes:
1. Set a new update barrier for N-2 on all streams.
See [discussion](https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629).
PR in:
CoreOS Installer changes:
1. Update CoreOS Installer to know about the signing key used for the
future new major version of Fedora (N+1). Note that the signing
keys for N+1 won't get created until releng branches and rawhide
becomes N+1.
PR in:
Release engineering changes:
1. verify that the `f${releasever}-coreos-signing-pending` Koji tag has
been created (this should have already been done by releng scripts on
branching)
Confirmed that those branches exist:
$ koji list-tags | grep coreos | grep 33
f33-coreos-continuous
f33-coreos-signing-pending
Release engineering changes:
2. `koji untag` N-2 packages from the pool (at some point we'll have GC
in place to do this for us, but for now we must remember to do this
manually or otherwise distRepo will fail once the signed packages are
GC'ed). For example:
- `koji list-tagged coreos-pool --quiet | grep fc30 | cut -f1 -d' ' | sort | uniq`
- Sanity-check the output, then pipe it to `xargs koji untag-build coreos-pool`
Requesting permission to untag these packages from the pool:
Requesting permission to untag these packages from the pool:
Done!
Current proposal for completing the transition of systems to systemd-resolved during upgrade: https://github.com/coreos/fedora-coreos-tracker/issues/646#issuecomment-707984576
updates:
New potential issue: https://github.com/coreos/fedora-coreos-tracker/issues/649
We discussed this in the community meeting today. Highlights:
testing
stream over to Fedora 33 in the cycle on or around November 17th (3 weeks from now). The testing
stream release (33.20201116.2.0
) going out today is based on F33.
Description
The tentative schedule for F33 is:
Currently the changes to Fedora are enumerated and linked from https://fedoraproject.org/wiki/Releases/33/ChangeSet. We should evaluate that change set to see if there is anything we need to do regarding those changes.
The following section will be updated/edited during investigation:
Noteworthy Fedora Changes from FCOS context
Changes we are considering making to FCOS
Other work F33 unblocks us on
OnFailure=
in targetsOther noteworthy changes Fedora 33 brings in