After installing and booting a Fedora Workstation Beta 1.3 image[0] and performing an update, the system becomes unusable. The same procedure seems to work correctly on an x86_64 system. [0] - https://kojipkgs.fedoraproject.org/compose/40/Fedora-40-20240313.0/compose/Workstation/aarch64/images/Fedora-Workstation-40_Beta-1.3.aarch64.raw.xz Reproducible: Always Steps to Reproduce: 1. Write disk image with arm-image-installer (`sudo arm-image-installer --image=/home/nielsenb/Desktop/Fedora-Workstation-40_Beta-1.3.aarch64.raw.xz --target=rpi4 --media=/dev/sda --resizefs`) 2. Insert uSD card into Raspberry Pi 4b 3. Power on 4. Complete Gnome first boot wizard 5. Start gnome-software 6. Navigate to "Updates" tab, wait for checking for updates to complete 7. Click "Download" 8. Wait for downloading to complete 9. Click "Restart & Update..." 10. Click "Restart and Install" button in modal that appears Actual Results: System goes to a TTY, showing system shutdown steps. Eventually screen goes black. System appears to never reboot on its own. Rebooting the system results in no boot, and nothing is displayed over HDMI. Expected Results: A successful reboot into the update installer, followed by a reboot into the updated system.
Proposed as a Blocker for 40-beta by Fedora user nielsenb using the blocker tracking app because: aarch64 is a supported platform, the Workstation image is release blocking, "the installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type".
Are you sure this isn't a dupe of #2242759?
(In reply to Peter Robinson from comment #2) > Are you sure this isn't a dupe of #2242759? My understanding is that only applies to system upgrades (so, say from Fedora 39 -> 40). This is just a regular update.
> My understanding is that only applies to system upgrades (so, say from > Fedora 39 -> 40). This is just a regular update. I believe gnome-update does a similar offline upgrade so I believe it may be the same problem. Do you still see the issue if you use "sudo dnf upgrade --refresh" on the command line and reboot?
yeah, the actual mechanism is essentially identical between `dnf system-upgrade`, `dnf offline-upgrade` and GNOME Software or Discover offline update/upgrade.
gnome-software uses PackageKit for package updates. What precisely PackageKit does under the hood I do not know, I only know it uses dnf, though it their own cache, not sharing data with the `dnf` command. Pity you do not see an actual error message, which could explain what precisely has got wrong. In any case, there's nothing gnome-software itself can do about it and I'm not sure whether PackageKit can. The bug #2242759 is filled against "distribution", which feels odd. Should it be dnf(4) instead? What about bug #2267968? Can that be related, as the reporter mentions black screen?
> The bug #2242759 is filled against "distribution", which feels odd. Should > it be dnf(4) instead? Well it's technically rpm because the rpi4 doesn't have a RTC and if the time isn't correct it can't properly verify the signatures due to cert times, so it's complicated. > What about bug #2267968? Can that be related, as the reporter mentions black > screen? No, that is the device not booting at all. I believe this is a dupe of 2242759. *** This bug has been marked as a duplicate of bug 2242759 ***
It's against distribution because we had a bunch of different ideas for fixing it, some of which weren't in rpm or dnf. It's one of those team-effort things that isn't clearly just a bug in one component. If we could at least agree on a plausible fix, I'd reassign it to whatever component we agreed to try and fix it in. But so far we didn't even manage to come up with a really plausible fix proposal, I don't think.
(In reply to Peter Robinson from comment #7) > > I believe this is a dupe of 2242759. > Confirmed dupe. Just doing an update via dnf and rebooting manually works fine.