Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Sprzęt: dysk sieciowy IOmega Home Media Network Hard Drive Cloud Edition zmodyfikowany do działania z Debianem Squeeze.
Problem: czas po ustawieniu via rdate jest okej, po reboot'cie cofam się do 1970.
Co ciekawe, po ogarnięciu obsługi polecenia hwclock, doszedłem do momentu w którym
root@Phobos:/var/log# hwclock
zwraca Sun 08 Jun 2014 02:11:21 PM CEST -0.572212 seconds
Czyli mua. jednak
root@Phobos:/var/log# date Thu Jan 1 01:26:06 CET 1970
Strefa czasowa ustawiona po bożemu za pomocą dpkg-reconfigure tzdata
Idąc po nitce do kłębka, znalazłem takie coś
root@Phobos:/var/log# service hwclock.sh Usage: hwclock.sh {start|stop|reload|force-reload|show}. start sets kernel (system) clock from hardware (RTC) clock. stop and reload set hardware (RTC) clock from kernel (system) clock.
Czyli, logicznie rzecz biorąc, start ustawi RTC -> SYS
root@Phobos:/var/log# service hwclock.sh start root@Phobos:/var/log# date Thu Jan 1 01:20:48 CET 1970
A takiego. Ktoś ma pomysł dlaczego tak się dzieje? Ustawienie z palucha działa
root@Phobos:/var/log# hwclock -s root@Phobos:/var/log# date Sun Jun 8 14:15:14 CEST 2014
Do rebootu rzecz jasna. Workaroundy z rdate w /etc/rc.local są niedopuszczalne.
Offline
Jak wykonasz z roota:
hwclock --systohc --utc;
to coś się poprawia?
Offline
root@Phobos:/lib/udev/rules.d# date -s 0 Sun Jun 8 00:00:00 CEST 2014 root@Phobos:/lib/udev/rules.d# hwclock --systohc --utc; root@Phobos:/lib/udev/rules.d# date Sun Jun 8 00:00:11 CEST 2014
Mam rebootować?
Znalazłem jeszcze /lib/udev/rules.d/85-hwclock.rules. Według skryptu hwclock.sh, jeśli w /dev znajduje się katalog .udev, skrypt ma się zakończyć bez ustawiania czasu. Czyli wychodzi na to, że udev coś szwankuje.
Offline
Ewidentnie w Udevie a raczej w Systemd, który połknął Udeva, czego rezultaty masz przed nosem na załączonym monitorze. xD
Umiesz liczyć, licz na siebie:
cat /usr/local/bin/czas #!/bin/bash echo -e "Godzinę nastawiam ;)\n"; rm -f /etc/adjtime rdate -s -p ntp.task.gda.pl; hwclock --systohc --utc; echo -e "Czas nastawiony ;)\n"; exit 0;
ls -l /etc/cron.hourly/czas lrwxrwxrwx 1 root root 19 2013-11-21 /etc/cron.hourly/czas -> /usr/local/bin/czas
SOA#1
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2014-06-08 14:57:52)
Offline
Eno że to Squeeze, na jaju 2.6.31; uzbrojony w rm -rf zadbalem, by żadne systemd'owe ścierwo nie skalało mi systemu. Nie po to mam sprzętowy zegar wspomagany CR2032 żeby bawić się w rdate :>
Offline
To zobacz, czemu hwclock nie zapisuje czasu w biosie, może jakiś sprzęt ciężki, albo masz jakąś blokadę modyfikacji czasu w biosie włączoną?
Offline
Zapisuje, w pierwszym poście udowowniłem że
ja napisał(-a):
Kod:
root@Phobos:/var/log# hwclockzwraca Sun 08 Jun 2014 02:11:21 PM CEST -0.572212 seconds
Czyli mua.
Po zepsuciu daty poleceniem date -s i wykonaniu service hwclock.sh stop data jest prawidłowo (czyli z wcześniejszą błędną nastawą) zapisywana w RTC, co potwierdzaja instrukcje
root@Phobos:~# date Sun Jun 8 15:11:40 CEST 2014 <-- jest okej root@Phobos:~# date -s 0 <--psuję Sun Jun 8 00:00:00 CEST 2014 <--zepsułem root@Phobos:~# /etc/init.d/hwclock.sh stop <--zapisuję Saving the system clock. root@Phobos:~# date <--sprawdzam Sun Jun 8 00:00:12 CEST 2014 <--w systemie zepsulem root@Phobos:~# hwclock <--sprawdzam RTC Sun 08 Jun 2014 12:00:16 AM CEST -0.857529 seconds <--też jest zepsute xD
Reasumując: dostęp do zegara jest, jest on zapisywany, ale z bliżej niewyjasnionych przyczyn przy bootowaniu systemu data z RTC nie jest wciągna do zegara systemowego. Obszedłem do wykomentowując trzy linie w hwclock.sh, sprawdzające obecność udeva, jednak nie jestem zadowolony z tego rozwiązania i wolałbym żeby działało jak wcześniej, systemowo.
Offline
Strony: 1