Kernel Manager terminology is misleading (“SUSPENDED” vs. “Not Installed”)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- python
- Domain
- desktop, operating-systems
Research direction
Start at the Kernel Manager entry point launched from Update Manager via View → Linux Kernels. Inspect how the kernel list labels the active kernel and other entries, and how installed kernels are distinguished from repository versions. Done means the terminology no longer implies that uninstalled kernels are suspended and the installed-versus-available presentation is clear.
Written by the indexing model from the issue text.
Description
Hi team,
I’d like to report a small but important UX issue in the Kernel Manager (the module launched from Update Manager via View → Linux Kernels). The Kernel Manager labels the currently running kernel as ACTIVE, which is clear and correct. However, all other kernels in the list are labeled SUSPENDED, even when those kernels are not installed on the system and do not exist in /boot.
In most Linux contexts (systemd, power management, PipeWire, kernel modules), “suspended” means:
installed
present
loaded but idle
But in the Kernel Manager, “SUSPENDED” is used to mean:
not installed
not present on disk
simply available in the repository
This can easily lead users to believe they have many kernels installed when they do not.
Suggested improvements:
Replace “SUSPENDED” with a clearer term such as:
“Not installed”
“Available”
“Repository version”
Visually separate:
Installed kernels
Available kernels
This would make the Kernel Manager’s behavior match Linux conventions and reduce confusion about what is actually on the system.
Thanks for considering this — the tool is very useful, and this small change would make it even clearer.
- Dominant language
- Python
- Stars
- 425
- Forks
- 190
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from linuxmint/mintupdate
-
BUG
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
linuxmint/mintupdate#1089 ·
-
BUG
Difficulty 1/5 Under an hour Newbie friendliness 88/100
linuxmint/mintupdate#1062 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
linuxmint/mintupdate#1041 · 1 comment ·
-
FEATURE REQUEST
Difficulty 1/5 Under an hour Newbie friendliness 65/100
linuxmint/mintupdate#910 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
linuxmint/mintupdate#903 ·
All issues in linuxmint/mintupdate
Similar issues
-
bug server
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sportsdataverse/sportsdataverse-py#641 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
googleapis/google-cloud-python#18532 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day