Automatic upgrade starts right after resume, before the network is up, and installs nothing
还没有人认领这个 Issue。
评估
调研方向
Start by reading the mintupdate-automation-upgrade.timer and service configuration, then trace how the upgrade is triggered after suspend or hibernate and how it depends on NetworkManager. The journal and mintupdate.log examples show the failure window and the misleading successful exit status. Done means an automatic run waits until networking is usable after resume and reports or handles a failed cache refresh appropriately.
由索引模型根据 Issue 内容生成。
描述
Linux Mint 22.3, mintupdate 7.1.4, laptop on Wi-Fi that is usually asleep or hibernated at midnight.
When the daily time passes while the machine is asleep, mintupdate-automation-upgrade.timer (Persistent=true) starts the service as soon as it wakes up. On this laptop that is 0.1 to 0.2 seconds after resume, while NetworkManager is still disconnected. mintupdate-cli then can't resolve any repository and nothing gets installed. The next attempt is the following day.
The service has After=network-online.target, but that target is reached once at boot and stays active through suspend, so it doesn't hold the service back on resume.
One example from the journal:
Oct 22 13:51:22.693 systemd-sleep: System returned from sleep operation 'hibernate'.
Oct 22 13:51:22.829 systemd: Starting mintupdate-automation-upgrade.service - Update Manager automatic upgrades...
Oct 22 13:51:24.282 NetworkManager: manager: NetworkManager state is now DISCONNECTED
Oct 22 13:51:28.059 NetworkManager: manager: NetworkManager state is now CONNECTED_GLOBAL
Oct 22 13:51:35.931 systemd: Finished mintupdate-automation-upgrade.service - Update Manager automatic upgrades.
and the matching part of /var/log/mintupdate.log:
W:Failed to fetch https://mirror.vnet.sk/ubuntu/dists/noble/InRelease Could not resolve 'mirror.vnet.sk'
[same for every other repository]
Error: mint-refresh-cache could not update the cache.
Between Oct 5 and Oct 29 there were 25 automatic runs. 10 failed like this, and 9 of those 10 started within 0.2 s of a resume from suspend or hibernate. Four days in a row (Oct 22 to 25) got no updates.
The service still exits with status 0 after these runs, so systemctl reports them as successful and the only trace is in mintupdate.log.
- 主要语言
- Python
- 星标
- 424
- 派生
- 191
- 平均合并
- 23 天 14 小时
- 30 天内合并 PR
- 1
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
linuxmint/mintupdate 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
linuxmint/mintupdate#1107 ·
-
BUG
难度 2/5 1-3 小时 新手友好度 68/100
linuxmint/mintupdate#1089 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 74/100
linuxmint/mintupdate#1041 · 1 条评论 ·
-
FEATURE REQUEST
难度 1/5 1 小时以内 新手友好度 65/100
linuxmint/mintupdate#910 ·
-
难度 1/5 1 小时以内 新手友好度 65/100
linuxmint/mintupdate#903 ·
查看 linuxmint/mintupdate 的全部 Issue
相似的 Issue
-
good first issue test
难度 2/5 1-3 小时 新手友好度 85/100
ANCORATE/EncryptHome#8 ·
-
PluginProvider.storeInstance races and clobbers the dedup cache for concurrent loads可能已有人在做 @Wilson0511 今天认领。 未关闭needs-triage
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
community documentation good first issue
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100