Boot path should always try to set hardware clock, but not err out
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- linux, shell
调研方向
从 03-console-setup.sh 和 hwclock --systz 的调用开始。检查 HARDWARECLOCK 未设置时以及 hwclock 报告不支持的操作时的行为；完成标准是默认尝试设置内核时区，而不会因该预期失败而进入 emergency_shell。
由索引模型根据 Issue 内容生成。
描述
From #musl:
16:53 <arnd> khem, ericonr: they sort-of have a point that the situation is broken: the kernel's behavior is absurdly broken but kept for backwards compatibility with a hack that dates back to the early 1990s. Whichever program calls settimeofday the first time after boot decides whether the kernel uses normal UTC behavior or MS-DOS compatible RTC-is-localtime.
16:54 <arnd> If /sbin/init doesn't do this but something else calls settimeofday() with a non-zero TZ offset later, it all goes wrong
16:55 <arnd> So if settimeofday() is either not available (on rv32) or disabled and returns -ENOSYS, the init task should just continue
16:57 <ericonr> arnd: I assume the kernel is hardcoded to use UTC on such on such archs?
16:58 <arnd> yes, the logic to do the timewarp is still there, but there are no other callers
16:59 <ericonr> I guess you still need to call it where available, otherwise some other application can force a sudden time warp >.<
16:59 <arnd> I don't think there are any distros that actually try to use the timewarp code, though setting the kernel timezone is still done sometimes
17:00 <arnd> any sane /sbin/init implementation does the same as the busybox variant
From 03-console-setup.sh:
if [ -n "$HARDWARECLOCK" ]; then
msg "Setting up RTC to '${HARDWARECLOCK}'..."
TZ=$TIMEZONE hwclock --systz \
${HARDWARECLOCK:+--$(echo $HARDWARECLOCK |tr A-Z a-z) --noadjfile} || emergency_shell
fi
This means that
- we only try to set the kernel timezone when
HARDWARECLOCKis set, which means a badly behaved application can force a time warp by callingsettimeofday(0, some_tz)as root. - our
initof choice, runit, never callssettimeofday(), which means for safety reasons we should always try to set the kernel timezone, and defaulting toUTCis entirely reasonable. - On some archs (and maybe at some point even some kernels?), this command can error out, so
|| emergency_shellis also wrong there.
- 主要语言
- C
- 星标
- 247
- 派生
- 67
- 平均合并
- 3 天 12 小时
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
void-linux/void-runit 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 67/100
void-linux/void-runit#141 · 1 个 reaction ·
-
elogind service starts after sound device initialization, causing permission failures可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 4/5 3-5 天 新手友好度 45/100
void-linux/void-runit#135 · 10 条评论 ·
-
难度 3/5 1-2 天 新手友好度 25/100
void-linux/void-runit#127 ·
-
难度 4/5 3-5 天 新手友好度 25/100
void-linux/void-runit#125 · 4 条评论 ·
-
key file and source not passed to keyscript可能已有人在做 @shaohme 于 834 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 35/100
void-linux/void-runit#120 ·
查看 void-linux/void-runit 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 63/100
维护者通常 1 天内回复
-
research-radar
难度 2/5 1-3 小时 新手友好度 63/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
-
"systemctl is-system-running --wait" may hang indefinitely for non-root users可能已有人在做 @alexonea 今天认领。 未关闭bug 🐛 systemctl
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
testing: DISK test reads the wrong directory entry offset on H89可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
FujiNetWIFI/fujinet-lib#115 · 1 条评论 ·
维护者通常 1 天内回复