Bug 2258073

Hi Vitaly,

As we are approaching the beta freeze and the 100% code complete deadline for the F40 changes, I am checking in with change owners on status of the work. Have you any updates you could share on how this change is going? Is it still on track for F40?


Thanks!
Aoife

It's all implemented.

The cloud image has been implemented using kiwi, so there is a dependency
on bug 2260081 / https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages

Currently the cloud image can only be tested by doing a kiwi image build
on the local machine, there will be no cloud images available for download
until the KiwiBuiltCloudImages change proposal is complete too.

so the "Fedora Cloud SIG: Add UKI enabled images as an option to Download Fedora Cloud" part of the scope is not complete, but everything else is? (Aoife is on vacation, this is your Temporary Substitute Change Wrangler speaking)

(In reply to Adam Williamson from comment #3)
> so the "Fedora Cloud SIG: Add UKI enabled images as an option to Download
> Fedora Cloud" part of the scope is not complete, but everything else is?
> (Aoife is on vacation, this is your Temporary Substitute Change Wrangler
> speaking)

Yes, that is correct.

Do you have any estimate whenever the infrastruture changes needed for
bug 2260081 will be deployed in time for the deadlines?  Or should I
better go for plan b and get fedora-kickstart.git changes ready too?

I guess the releng team would be best placed to answer that, but unofficially, if I were you, I'd have kickstart changes in my back pocket...

https://pagure.io/fedora-kickstarts/pull-request/1020

Do we need to change the status of the BZ somehow to reflect that we're actually 100% code ready (means no changes to Fedora packages are needed? The rest will happen asynchronously when infrastructure is ready.

The states we really have the ability to indicate are "testable" (MODIFIED) and "100% complete" (ON_QA), but that has to mean "testers and users can actually use the thing in a relatively normal way", not "we have all the code somewhere but there isn't a practical way for anyone else to use it".

Well, yes, don't have UKI based images produced or published yet but in fact it is already possible to use something like Gerd's kickstarts to produce such images locally (and it's actually fairly common to use Fedora this way). We have this mentioned in 'How To Test' of the proposal. This is, of course, not as convenient as grabbing something existing but IMO still deserves mentioning.

reading the scope of the change again, personally I'd say it'd be reasonable to call it MODIFIED, then. Overall the optional prebuilt downloadable images read as just one part of the Change, not the main point of it.

(In reply to Adam Williamson from comment #10)
> reading the scope of the change again, personally I'd say it'd be reasonable
> to call it MODIFIED, then. Overall the optional prebuilt downloadable images
> read as just one part of the Change, not the main point of it.

Yes, let's move this to MODIFIED.

We got a Cloud image into the Beta-1.10 compose:
https://dl.fedoraproject.org/pub/alt/stage/40_Beta-1.10/Cloud/x86_64/images/Fedora-Cloud-Base-UEFI-UKI.x86_64-40-1.10.qcow2

so, marking this ON_QA.

(In reply to Adam Williamson from comment #12)
> We got a Cloud image into the Beta-1.10 compose:
> https://dl.fedoraproject.org/pub/alt/stage/40_Beta-1.10/Cloud/x86_64/images/
> Fedora-Cloud-Base-UEFI-UKI.x86_64-40-1.10.qcow2

I've just uploaded the image to Azure and I was able to start a CVM using it. Cool, thanks!

The only apparent issue I've noticed is failing systemd-pcrphase-initrd.service:

[root@vkuznets-f40 ~]# systemctl status systemd-pcrphase-initrd.service
× systemd-pcrphase-initrd.service - TPM2 PCR Barrier (initrd)
     Loaded: loaded (/usr/lib/systemd/system/systemd-pcrphase-initrd.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Thu 2024-03-21 16:29:40 UTC; 55s ago
       Docs: man:systemd-pcrphase-initrd.service(8)
   Main PID: 213 (code=exited, status=203/EXEC)
        CPU: 792us

This, however, is most likely not an image problem. I'll try to investigate tomorrow.
In any case this shouldn't block anything I guess.

> The only apparent issue I've noticed is failing
> systemd-pcrphase-initrd.service:

I was hoping the switch to use the systemd-pcrphase dracut module in kernel-ark fixes that.
So maybe that didn't work for some reason, or maybe that change lands in fedora only when the kernel jumps to 6.8

I found and reported SELinux problem with pcrextend: https://bugzilla.redhat.com/show_bug.cgi?id=2270929 but it is *not* the
reason of the unit failure. We don't get the log file created in /run/log/systemd/. I'm afraid that we get some sort of a race
and systemd-pcrphase-initrd.service is either colliding with something else which tries using TPM or something like that.

(In reply to Gerd Hoffmann from comment #14)
> > The only apparent issue I've noticed is failing
> > systemd-pcrphase-initrd.service:
> 
> I was hoping the switch to use the systemd-pcrphase dracut module in
> kernel-ark fixes that.

The switch fixes the problem indeed (we have /usr/lib/systemd/systemd-pcrextend missing in the initramfs),
the thing is that the switch hasn't happened in Fedora-40 just yet as the last kernel build (kernel-6.8.1-300.fc40)
hasn't reached the repo yet and 6.8.0-0.rc6.49.fc40 is buggy. I've confirmed that updating the kernel manually
to https://koji.fedoraproject.org/koji/buildinfo?buildID=2423429 resolves the issue.

One more thing: in case 'systemd-ukify' is installed, 60-ukify.install script currently tries to rebuild the UKI 
upon install. I've opened a PR against systemd to fix that:

https://github.com/systemd/systemd/pull/31930

For now, avoid installing systemd-ukify to the image or override KERNEL_INSTALL_UKI_GENERATOR variable in 
kernel-install config to workaround the issue.

fyi: aarch64 images are broken, fix just landed, next rebuild should be fine.
https://pagure.io/fedora-kiwi-descriptions/c/436e9d6e484ae4f9ba6b91ba0cf462eaf4905d59

F40 was released on 2024-04-23, so I am closing this tracker. If this Change was not completed, please notify me ASAP.