Move to Fedora 31! #200
Move to Fedora 31! #200
Conversation
|
Seems like we should set up f31 as |
|
As part of this process it would be nice to do an analysis of the rpm add/removes to see if there are any red flags. |
Yeah agreed. I mentioned it in the second commit message:
My initial reason for not doing it for this transition is that I didn't want to gate moving to f31 on getting
We have that with the lockfile diff, though I can print the rpm-ostree generated pkgdiff as a comment too. |
+1
Yeah I see that let's analyze the changes to see if there are any red flags. |
|
Added diff to first comment. And here's the interesting bit duplicated:
|
|
for the others:
|
|
we can merge this after coreos/coreos-assembler#854 correct? |
It was retired in f31 and obsoleted by systemd: https://bugzilla.redhat.com/show_bug.cgi?id=1735584
Likely missing some details, but let's add those as we go through this for f31. I think for f32, we'll want to leverage `next` more. E.g. directly promoting from `next` to `testing-devel` or something. For now, let's just document things as they are today.
jlebon
force-pushed
the
pr/bump-to-f31
branch
from
665a0be
to
0d39a35
Compare
|
OK, this one is ready to go! 🚀 |
Following coreos#200.
|
kola failures in CI
|
|
Right, so I think this is coreos/fedora-coreos-tracker#292. I think it was mostly decided that we'd ship with v1 at this point. So we need to tweak some knobs to default to that. And that should hopefully fix the podman tests. If it turns out we are shipping v2 in stable, we can always revert. |
|
And the last one is: Still looking into that one. |
|
@jlebon: that's likely a flake, I'd recommend re-running that test specifically. |
|
OK, that should be all the failures! |
|
One messy thing with this is that we don't have a way to cleanly distinguish between kargs we set by default, and ones users set. This is ostreedev/ostree#479 So in the future, we'll be by default staying with the non-unified hierarchy unless we do something like write a special systemd unit that changes the kargs. Not a blocker, just noting this. |
jlebon
force-pushed
the
pr/bump-to-f31
branch
from
524521a
to
e1470f0
Compare
|
still LGTM |
|
New podman failures, fun! |
|
OK so somehow adding back |
jlebon
force-pushed
the
pr/bump-to-f31
branch
from
e1470f0
to
d39ff35
Compare
|
OK, I think I got to the bottom of this finally. Just going to copy/paste from the relevant commit message: |
Pretty straight-forward. The one tricky bit is that we need to temporarily use the `fedora-next` repos since the repo structure still uses `development/` for now. We'll switch those over at GA.
For the same reason as: coreos#195 I.e.: coreos/fedora-coreos-tracker#290
FCOS is likely to ship with CGroupsV1 to start, since most of the containerization ecosystem isn't yet ready for V2. Pass the `systemd.unified_cgroup_hierarchy=0` karg to enable this. This should at least allow podman Kola tests to pass. For more information, see: coreos/fedora-coreos-tracker#292
In Fedora 31, NetworkManager includes an initrd module which replaces the legacy dracut networking one. The key bit is here: https://github.com/dracutdevs/dracut/blob/1fcc70fe57eea0ea658aa2de5c0044683fe85cf1/modules.d/40network/module-setup.sh#L11. It was initially in f30 as well, but was reverted due to issues: https://src.fedoraproject.org/rpms/NetworkManager/c/7d3054a9e366f1ebdd9d7854bf11a3069119d6da?branch=f30 (One thing that confused me at first: note that this isn't a systemd generator, it's run via the dracut cmdline hook.) The generator does seem to have feature parity wrt karg support: https://github.com/NetworkManager/NetworkManager/blob/ba64c162dc471740a405f9d59e7a132f0e290078/src/initrd/nmi-cmdline-reader.c Though I couldn't get it to work in my tests; `rd.neednet=1` does not result in a populated `resolv.conf`, which would of course cause Ignition to fail. Anyway, given that we tie pretty strongly into initrd networking for e.g. Ignition and the installer, I think I'd rather we stick with the status quo for now, and do the transition separately from the FCOS f31 rebase.
This is known to fail right now due to coreos/fedora-coreos-tracker#280.
jlebon
force-pushed
the
pr/bump-to-f31
branch
from
d39ff35
to
c327840
Compare
Woohoo! |
Following coreos#200.
We should match coreos/fedora-coreos-config#200 on general principle, but also specifically because we now also have a buildroot container that derives from this, and we want to support people building content in that buildroot that targets the host.
We should match coreos/fedora-coreos-config#200 on general principle, but also specifically because we now also have a buildroot container that derives from this, and we want to support people building content in that buildroot that targets the host.
We should match coreos/fedora-coreos-config#200 on general principle, but also specifically because we now also have a buildroot container that derives from this, and we want to support people building content in that buildroot that targets the host.
We should match coreos/fedora-coreos-config#200 on general principle, but also specifically because we now also have a buildroot container that derives from this, and we want to support people building content in that buildroot that targets the host.
We should match coreos/fedora-coreos-config#200 on general principle, but also specifically because we now also have a buildroot container that derives from this, and we want to support people building content in that buildroot that targets the host.
This seems not to run for me...I don't quite understand the initqueue stuff, still debugging. See also coreos#200 (comment)
This seems not to run for me...I don't quite understand the initqueue stuff, still debugging. See also coreos#200 (comment)
See individual commit messages.
Requires: coreos/rpm-ostree#1927
Marking as draft until the f30 release is completely done (and I'd like to investigate the
efivar-libsbit a little more).Diff from latest `testing` release