Bug 2269410
| Summary: | Updating via gnome-software on Raspberry Pi 4b results in unusable system | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brandon Nielsen <nielsenb> |
| Component: | gnome-software | Assignee: | Milan Crha <mcrha> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 40 | CC: | awilliam, gnome-sig, mcrha, pbrobinson, pwhalen, rhughes, robatino |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | aarch64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-03-14 09:41:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2187792 | ||
|
Description
Brandon Nielsen
2024-03-13 18:27:33 UTC
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. |