Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Boot path should always try to set hardware clock, but not err out

Abierto
#69 0 comentarios 2 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
linux, shell

Línea de trabajo

Comienza con 03-console-setup.sh y la invocación de hwclock --systz. Comprueba el comportamiento cuando HARDWARECLOCK no está establecido y cuando hwclock informa de una operación no compatible; se considera terminado cuando, de forma predeterminada, se intenta establecer la zona horaria del kernel sin pasar a emergency_shell por ese fallo esperado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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 HARDWARECLOCK is set, which means a badly behaved application can force a time warp by calling settimeofday(0, some_tz) as root.
  • our init of choice, runit, never calls settimeofday(), which means for safety reasons we should always try to set the kernel timezone, and defaulting to UTC is entirely reasonable.
  • On some archs (and maybe at some point even some kernels?), this command can error out, so || emergency_shell is also wrong there.
Lenguaje dominante
C
Estrellas
245
Forks
67
Merge medio
2 d
PR fusionados (30 d)
2

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de void-linux/void-runit

Todos los issues de void-linux/void-runit

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.