Skip to content

MintUpdate GUI hangs when tray auto‑refresh runs, but works fine when launched manually #1088

Description

@pyz0123-cpu

Description:
When MintUpdate is launched manually from the terminal (mintupdate &), it runs flawlessly — apt and Flatpak updates complete, and the GUI remains responsive. However, when MintUpdate is started automatically via the tray icon (autostart instance), the GUI eventually hangs during its scheduled refresh.

Steps to reproduce:

Run mintupdate & in terminal → MintUpdate works normally.
Allow MintUpdate to autostart in tray after login.
Wait for scheduled auto‑refresh.
Observe: GUI hangs, tray icon shows “could not refresh updates.”

Observed behavior:
Tray instance freezes during auto‑refresh.
Error message: “could not refresh the list of updates.”
Apt logs show mirror mismatch errors (e.g., File has unexpected size … Mirror sync in progress).

Flatpak updates sometimes stall.

Expected behavior:
MintUpdate’s tray auto‑refresh should behave the same as manual launch — complete updates without freezing, or at least report errors gracefully.

Environment:
Linux Mint 22 (Noble base)
MintUpdate version: 7.1.x
OEM kernel in use
Apt shows deferred phased updates (dnsmasq-base, libpfm4)
Flatpak integration enabled

Additional notes:

Manual MintUpdate launch works fine every time.
The bug only affects the tray auto‑refresh instance.
Likely related to MintUpdate’s error handling when apt/Flatpak encounter mirror sync mismatches.

Activity

  1. pyz0123-cpu commented on Sep 5, 2026

    @pyz0123-cpu
    Author

    Addendum for Bug Report
    Additional observation:
    When MintUpdate is launched manually from the terminal (mintupdate &), the GUI flashes up, runs perfectly, and correctly reports “system is up‑to‑date.” However, if the GUI is already open and I manually initiate a refresh from within it, the application hangs in the same way as the tray auto‑refresh instance.

    Steps to reproduce (extended):

    Run mintupdate & in terminal → GUI opens, reports “system is up‑to‑date.”
    With the GUI open, click Refresh.
    Observe: GUI hangs, identical to tray auto‑refresh behavior.

    Implication:
    MintUpdate’s startup check works correctly, but its refresh routine (manual or automatic) fails when apt/Flatpak encounter mirror sync mismatches. This suggests the bug lies specifically in the refresh logic, not in the initial launch sequence.

  2. pyz0123-cpu commented on Sep 5, 2026

    @pyz0123-cpu
    Author

    Additional observation:
    On my laptop (same Linux Mint version), MintUpdate behaves normally — both startup and manual refresh succeed. The hang only occurs on my desktop system. This suggests the issue may be environment‑specific (mirror selection, Flatpak configuration, or phased updates) rather than a universal MintUpdate bug.

    Environment comparison:
    Desktop: Linux Mint 22, kernel 6.17‑1032‑oem → MintUpdate hangs on manual/tray refresh.
    Laptop: Linux Mint 22, newer kernel (e.g., 7.0.x) → MintUpdate runs normally, refresh succeeds.

    Implication:
    The issue appears kernel‑specific. MintUpdate’s refresh routine fails on the older OEM kernel but works fine on newer kernels. The new oem kernel is not available yet. The OEM is EOL. So this is on Canonical. They are late.

    So I believe this to me an older OEM kernel issue - not Mint's specifically -- FYI. Just my opinion.

  3. pyz0123-cpu commented on Sep 5, 2026

    @pyz0123-cpu
    Author

    Status update:
    MintUpdate is behaving normally this morning. The GUI launches cleanly, the refresh routine completes without hanging, and both apt and Flatpak checks succeed. This suggests the issue may have been tied to temporary external conditions (mirror sync state, phased‑update timing, or kernel‑specific behavior) rather than a persistent MintUpdate defect.

    Kernel context:
    Desktop: Kernel 6.17‑1032‑oem (older OEM branch, now past EOL).
    Laptop: Newer OEM kernel (linux‑oem‑7.x).
    The hang only occurred on the desktop’s older OEM kernel. The laptop never exhibited the issue.

    Implication:
    The behavior appears kernel‑dependent. MintUpdate’s refresh routine may be more sensitive to apt/Flatpak mirror conditions on the older OEM kernel. Once external conditions stabilized (mirror sync completed, phased updates advanced), MintUpdate began functioning normally again.

    Why this matters:
    This supports the idea that MintUpdate itself is functioning correctly, and the earlier hang was triggered by the combination of:

    An expired OEM kernel,
    Mirror sync mismatches (File has unexpected size),
    Phased updates being deferred,
    Flatpak metadata timing.

    MintUpdate may still benefit from more graceful error handling during refresh on older kernels, but the root cause appears external to Mint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions