Conversation
cevich
force-pushed
the
update_F35b
branch
6 times, most recently
from
9cb6f3c to
f9f484f
Compare
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
update_F35b
branch
3 times, most recently
from
c0821ab to
1fcc0a7
Compare
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
update_F35b
branch
3 times, most recently
from
9d70f60 to
927a6a9
Compare
|
Cirrus CI build successful. Image ID |
2 similar comments
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
update_F35b
branch
10 times, most recently
from
74379bc to
db3442c
Compare
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
update_F35b
branch
5 times, most recently
from
41a0b9e to
4d25f8d
Compare
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
In GCP, there are google services that must start on boot but we also
rely on the more generic cloud-init services to setup the VM.
Specifically, this is necessary to attend to rootfs resizing properly
before testing. However, there is a dependency loop created when both
are installed, that will result in messages like:
...network-online.target: Found ordering cycle on \
cloud-init.service/start
...network-online.target: Found dependency on \
google-network-daemon.service/start
...network-online.target: Found dependency on \
google-instance-setup.service/start
...network-online.target: Found dependency on \
network-online.target/start
...network-online.target: Job cloud-init.service/start \
deleted to break ordering cycle starting with \
network-online.target/start
Previously, this was addressed by depositing a customized
cloud-init.service file for Fedora VMs. However, at some point in the
past this step was dropped. Restore it.
Also, add a header-comment to this and another custom service file to
indicate where they came from.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
Cirrus CI build successful. Image ID |
The podman build process will install this if it's missing for any reason. That could result in inconsistent CI-vs-user experience. Installing it explicitly (here) forces new version requirements to come through the packaging system. Signed-off-by: Chris Evich <cevich@redhat.com>
Older versions of podman (<3.4.1) allowed logging into a registry using a FQIN. Newer versions do not. Fix this by stripping off any tag present in the FQIN while logging in. Signed-off-by: Chris Evich <cevich@redhat.com>
The F35 cloud image is now based on a BTRFS root filesystem. Since secondary storage provisioning is no longer tested by containers/storage support for runtime storage-expansion in Fedora images is being dropped. This significantly simplifies the build and runtime, but requires all repos using these images to remove calls to `growpart` and other runtime partitioning scripts. Signed-off-by: Chris Evich <cevich@redhat.com>
|
Cirrus CI build successful. Image ID |
1 participant
Depends on: #91 #92 #94 #98
Note: Deployment of these images need to include attention to re-introduction of auto-resize on both Fedora VMs.