Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#69 0 commenti 2 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
linux, shell

Direzione di ricerca

Inizia con 03-console-setup.sh e l’invocazione di hwclock --systz. Verifica il comportamento quando HARDWARECLOCK non è impostato e quando hwclock segnala un’operazione non supportata; il lavoro è completato quando, per impostazione predefinita, viene tentato l’impostazione del fuso orario del kernel senza passare a emergency_shell per questo errore previsto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
C
Stelle
245
Fork
67
Merge medio
2g
PR unite (30g)
2

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di void-linux/void-runit

Tutte le issue di void-linux/void-runit

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.