Boot path should always try to set hardware clock, but not err out
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
- Área
- operating-systems
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
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.
- Lenguaje dominante
- C
- Estrellas
- 245
- Forks
- 67
- Merge medio
- 2 d
- PR fusionados (30 d)
- 2
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de void-linux/void-runit
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
void-linux/void-runit#135 · 10 comentarios ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
void-linux/void-runit#127 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
void-linux/void-runit#125 · 4 comentarios ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
void-linux/void-runit#120 ·
-
Runit hangs at system reboot Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
void-linux/void-runit#119 · 7 comentarios ·
Todos los issues de void-linux/void-runit
Issues similares
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 60/100
-
Nmap
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
flang:fir-hlfir
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
llvm/llvm-project#225935 ·