Fedora Account System
Red Hat Associate
Red Hat Customer
Installing from aarch64 Server DVD image Fedora 45 Branched 20260927.n.0 on an offline RPi4 fails with a generic error message "An error occurred during the transaction". Installing from the same image when the RPi is connected to network works fine. Also installing from this image to a VM without network connection works fine. dnf.log contains following info: ... 2026-08-31T17:04:08+0000 [2668] DEBUG Failed to find rpm package of a running kernel in sack 2026-08-31T17:07:44+0000 [3667] ERROR [rpm] /mnt/sysroot/dnf.package.cache/kernel-7.2.7-300.fc45.aarch64.rpm: Header OpenPGP V4 RSA/SHA256 signature, key ID 655a4b02f577861e: BAD Reproducible: Always Steps to Reproduce: 1. Create install USB flash from Fedora-Server-dvd-aarch64-45-20260927.n.0.iso 2. Run OS install on RPi4 with EDK2 UEFI bootloader and no network connection Actual Results: Installation fails early in the process with a popup window containing a generic message: "The following error occurred while installing the payload. This is a fatal error and installation will be aborted. An error occurred during the transaction: The transaction process has ended with errors." Expected Results: Installation works fine. Additional Information: Attaching anaconda logs collected from the RPi.
Created attachment 2159397 [details] Anaconda logs from failed install attempt
Proposed as a Freeze Exception for 45-final by Fedora user jgroman using the blocker tracking app because: Installing from Server DVD image should work fully offline even on RPi4.
Proposing as a blocker: "When using a dedicated installer image that contains packages, the installer must be able to use the install medium as a package source." https://fedoraproject.org/wiki/Basic_Release_Criteria#Media_package_source Jaroslav, can you please verify that the ISO image checksum is correct (against the CHECKSUMS file)? Is this a repeatable failure, have you tried twice? Thanks.
ISO image checksum verified, failure is repeatable - tried 3 times.
Retested with the latest Fedora-Server-dvd-aarch64-45-20261003.n.0.iso, checksum verified, issue is still present.
+3 FE in https://forge.fedoraproject.org/quality/blocker-review/issues/2197 , marking accepted FE. Blocker proposal still open.
Created attachment 2160143 [details] Image 20261003.n.0 Anaconda logs
Isn't this the wrong-clock issue: https://bugzilla.redhat.com/show_bug.cgi?id=2242759 ? With network your clock gets updated with NTP before you start installing packages without it the system clock predates the GPG key validity / signatures?
Yeah, it seems very likely this is a variant of that.
Discussed during a blocker review meeting [1]. The outcome was: punt (delay decision) - we don't have a clear consensus on this, we will revisit it at future meetings if necessary [1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-10-05/
Maybe the overall fix is to assure that the buildtime /var/lib/systemd/timesync/clock is on the stage2 ramdisk. Then systemd-timesyncd can fast forward the clock if needed.
I had a look at date values during installation. Seems that image boots with date 2026-09-29 preset which gets later reverted to 2026-08-31 by rtc-efi driver (probably sourced from EDK2). Neither of those dates is current enough for package signature verification to pass, though, otherwise we could probably blame RPi4 EDK2 for causing this issue. I suppose such a condition might easily happen also on other systems with e.g. faulty RTC backup battery or just wrong time preset. Changing date to anything after 2026-10-03 manually in Anaconda is enough for installation to pass. Maybe "good enough" fix could be if Anaconda compared current system date to a known good info like some system file timestamp (or package signature validity start timestamp) and displayed warning in "Time & Date" section if the current date was older. Even just updating the error message to say something like "Package verification failed, check install media checksum and system time" would be much more helpful.
AGREED AcceptedFinalBlocker Discussed at the 2026-10-12 (blocker / freeze exception) review meeting: This is accepted as a conditional violation of all 'install must work' criteria, the condition being you're doing an offline install on a system without an RTC or with a dead RTC. We anticipate the possibility of this being waived if it turns out a reasonable fix isn't possible to implement in a short timeframe. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-10-12/f45-blocker-review.2026-10-12-16.00.log.txt
In terms of a source of a known-past date - I believe DVD installer images should have the repository .treeinfo file, which has a timestamp in it for when the repository tree was created. e.g. https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20261015.n.0/compose/Server/x86_64/os/.treeinfo has `timestamp = 1792043140` , which is 2026-10-15T15:51:50Z . I *think* that treeinfo timestamp should always be later than the timestamp on any package in the tree.
It may not be the same thing, but I've been getting the same crash since F43 with the same popup messages in the first (pre-comment) post. This won't be a full report; I just spotted this RHBZ and wanted to mention the similar failure mode. This is on a VMware VM with host-only and NAT network interfaces, both connected and working. Date has always been screwy; e.g. the right number but the wrong timezone (sometimes UTC, sometimes EDT). Installing 1909 packages is always OK, but it fails every time with 7412 packages (~11.5 GB). And it as I recall it fails with a trimmed-down number of packages; failure accurs when the package count gets around 4000. There's plenty of disk space and RAM. Packages come from a custom ISO (checksum verified) on a USB SSD. Packages are a mix of Fedora and RPM Fusion (a superset of %packages, to handle dependencies). Same crash if only Fedora packages are in %packages . dnf.log ends with: 2026-10-15T09:34:39+0000 [4258] INFO RPM callback transaction start, total 7412 2026-10-15T09:34:42+0000 [4258] INFO RPM callback transaction stop, total 7412 Things after the "Failed... in sack" message are different from the original post: 2026-10-15T09:32:54+0000 [3163] DEBUG Failed to find rpm package of a running kernel in sack 2026-10-15T09:34:09+0000 [4258] WARNING [rpm] /mnt/sysroot/tmp/dnf.package.cache/AMF-devel-1.5.2-2.fc45.noarch.rpm: Header OpenPGP V4 RSA/SHA256 signature, key ID 655a4b02f577861e: NOKEY 2026-10-15T09:34:10+0000 [4258] WARNING [rpm] /mnt/sysroot/tmp/dnf.package.cache/HandBrake-1.11.2-3.fc45.x86_64.rpm: Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEY 2026-10-15T09:34:10+0000 [4258] WARNING [rpm] /mnt/sysroot/tmp/dnf.package.cache/amrnb-11.0.0.0-23.fc45.x86_64.rpm: Header OpenPGP V4 RSA/SHA256 signature, key ID 6a2af96194843c65: NOKEY 2026-10-15T09:34:12+0000 [4258] ERROR [rpm] failed to open /mnt/sysroot/etc/group for id/name lookup: No such file or directory 2026-10-15T09:34:12+0000 [4258] ERROR [rpm] failed to open /mnt/sysroot/etc/group for id/name lookup: No such file or directory (repeats; a total of 173 of them)
I should have mentioned: I used basically the same method to install F42 Release on a physical machine. Main difference is that the custom ISO was on a local drive. Package count was 6915 .
Bruce, I very much doubt that's the same problem. All the details are different and in your case the message is "NOKEY", not "key ID 655a4b02f577861e: BAD". Probably best to file separately to avoid confusion. Thanks!
FEDORA-2026-cdca4ae3ef (anaconda-45.30-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-cdca4ae3ef
FEDORA-2026-cdca4ae3ef has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-cdca4ae3ef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-cdca4ae3ef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Verified with Fedora-Server-dvd-aarch64-45-1.1.iso on the same hardware as before. Installation now successfully completed fully offline.
FEDORA-2026-cdca4ae3ef (anaconda-45.30-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.