Achso – ja das macht dann wiederum Sinn. In diesem Falle belasse ich die statische IP auf dem iPad so und lasse auch die AdHoc-Einstellungen bestehen wie sie sind.
cat /etc/systemd/network/08-wifi.network
Achso – ja das macht dann wiederum Sinn. In diesem Falle belasse ich die statische IP auf dem iPad so und lasse auch die AdHoc-Einstellungen bestehen wie sie sind.
cat /etc/systemd/network/08-wifi.network
manpage für systemd.network.
Okay – da schaue ich mal rein.
So wie es aussieht, wäre die Lösung damit das AdHoc-Lan, wie auch das normale Lan (eth0) korrekt laufen würde, der DHCP-Server. Ich verstehe daher nicht, warum du diesen nicht in Betrieb nehmen würdest?
Die Ausgaben:
systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-11-30 12:21:39 CET; 1h 26min ago
Docs: man:systemd-networkd.service(8)
Main PID: 144 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 2200)
Memory: 2.5M
CGroup: /system.slice/systemd-networkd.service
└─144 /lib/systemd/systemd-networkd
Nov 30 12:21:38 raspberrypi systemd[1]: Starting Network Service...
Nov 30 12:21:39 raspberrypi systemd-networkd[144]: Enumeration completed
Nov 30 12:21:39 raspberrypi systemd[1]: Started Network Service.
Nov 30 12:21:52 raspberrypi systemd-networkd[144]: wlan0: Gained carrier
Nov 30 12:21:53 raspberrypi systemd-networkd[144]: wlan0: Gained IPv6LL
Nov 30 12:22:05 raspberrypi systemd-networkd[144]: wlan0: Configured
Alles anzeigen
ls -la /etc/systemd/network
insgesamt 12
drwxr-xr-x 2 root root 4096 Nov 30 12:21 .
drwxr-xr-x 5 root root 4096 Nov 28 21:41 ..
-rw-r--r-- 1 root root 52 Nov 30 12:21 08-wifi.network
lrwxrwxrwx 1 root root 9 Sep 26 02:09 99-default.link -> /dev/null
ps aux | grep -i [d]hc
-> Das ergibt keine Ausgabe
Kannst Du lokal auf dem iPad, diese feste IP-Adresse nicht persistent/dauerhaft konfigurieren?
Doch das geht schon – das iPad merkt sich die Einstellungen des jeweiligen WLAN-Netzwerkes. Aber die Lösung mit DHCP wäre doch etwas eleganter, oder hätte ich durch dessen Aktivierung irgendwelche Nachteile?
dort einen DHCP-Server konfigurieren.
GIbt es diesbezüglich irgendwelche Anleitungen? Bis jetzt ist die Buster-Installation noch sehr "sauber" und ich möchte da jetzt nichts mehr verkonfigurieren.
Hier noch die Ausgaben:
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b8:27:eb:1d:83:e0 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:48:d6:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:fe48:d6b5/64 scope link
valid_lft forever preferred_lft forever
Alles anzeigen
route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
ip n s
Welche IP-Adresse hat das Gerät mit dem VNC-Viewer?
Es ist ein iPad und so wie es aussieht, bekommt es keinerlei Netzwerk-Informationen vom AdHoc-Netzwerk mitgeteilt.
EDIT:
Habe gerade dem iPad manuell eine IP-Adresse im gleichen Subnet zugewiesen (inkl. Netmask & Gateway) und siehe da: so kann ich mich mit dem PI über VNC verbinden... Das ist schon einmal ein grosses Ergebnis für mich, heisst das doch, dass die vorherigen Einstellungen in Ordnung waren.
EDIT2 :
– Das bestätigt dann aber wohl meinen Verdacht, dass es am DHCP-Server liegt – oder nicht? Falls ja: Wie kann ich diesen in Betrieb nehmen?
und als zweite Frage:
– Warum läuft mein Heimnetzwerk nicht mehr (angeschlossen via Netzwerkkabel)?
Hallo zusammen
Nachdem ich auf Raspbian Buster upgedatet habe (neue Installation), wollte ich nun mit dem Pi ein AdHoc-Netzwerk erstellen. Mit Hilfe des Forum habe ich das bereits einmal unter Stretch hinbekommen, da aber noch mit der interfaces-Lösung, welche gemäss mehreren User-Aussagen aber nicht mehr zeitgemäss ist. Daher wollte ich nun unter Buster die Lösung mit systemd-networkd und wpa_supplicant einrichten. Vorgegangen bin ich nach dieser Anleitung: *Klick*. Damit es keine Missverständnisse gibt; folgende Punkte habe ich ausgeführt:
Setup systemd-networkd
Setup unprotected ad-hoc interface using wpa_supplicant
Was funktioniert zurzeit:
– Ich habe ein AdHoc-Netzwerk mit dem Namen IBSS-RPiNet mit welchem ich mich verbinden kann
Und nun noch was zurzeit nicht funktioniert:
– Ich würde gerne mit VNC auf den Rechner zugreifen, dass klappt aber nicht und ich frage mich wieso?
– Das Heimnetzwerk ist auch nicht mehr sichtbar/erreichbar
VNC-Viewer – mit welchem ich auf den Pi zugreifen möchte, teilt mir nur mit: "Error - The computer's IP address could not be contacted" (VNC-Server auf dem Pi gibt mir unter "Konnektivität" die IP-Adresse 192.168.2.1 aus -> das habe ich auch so in der wlan-interface-Datei festgelegt)
Kann es allenfalls an einem DHCP-Problem liegen? Bei der Stretch-Lösung musste ich damals einen solchen installieren...
Schon einmal vielen Dank im Voraus für eure Hilfe.
Hi
Danke dir für deine ausführliche Antwort. Ja das ist richtig, dass mein Pi auch an einem LAN betrieben wird.
Zurzeit bezieht also mein PI die Systemzeit ausschliesslich von der RTC – auch wenn dieser am LAN hängt. Damit in letzterem Falle aber der NTP-Service genutzt wird, braucht es zusätzliche Software.
Hier kommt das in #64 erwähnte C# Progamm ins Spiel
Kann das denn nicht einfacher gelöst werden? Allenfalls irgendwie über die Boot-Reihenfolge der services?
Noch eine Bemerkung die Batterie der kleinen RTC hält nicht lange.
Hast du da genauere Werte? Denke zwar, dass wird nicht einfach nachvollziehbar sein, da wohl die Knopfbatterie schon bei der Auslieferung unterschiedliche Ladezustände hat (bei mehreren Modulen).
Bei mir sind es schon 2 Stück da werde ich mal eine CR2032 anschließen und Testen.
Wäre toll, wenn du dann deine Erkenntnisse teilen könntest.
ALSO – ich (oder wir) habe(n) einen Erfolg zu vermelden:
Die Systemzeit wird nun auch nach einem Stromunterbruch und ohne LAN korrekt ausgegeben! Wow!
Die service-unit "new_hwclock.service" ist ja auch nicht aktiviert (enabled), sondern wird via eine udev-Regel gestartet.
Da stellt sich auch die Frage, welche "Wirkung" in diesem Fall die Zeilen "Wants=" bzw. "After=" noch haben?
Vielleicht kann das md_fg ja noch abschliessend beantworten. Dann kann ich die new_hwclock-services noch aufräumen und habe dann endlich die längst ersehnte saubere RTC-Lösung.
Eventuell könnte man ja auch den Beitrag #83 von md_fg bereinigen (denn Kommentar noch löschen) und an einer geeigneten Stelle mit dem Beitrag #59 zusammenführen -> das wäre dann eine vollständige Anleitung zur Einrichtung der RTC (mit Buster).
Hier wäre noch die Ausgabe von systemd-analyze plot:
An dieser Stelle auf alle Fälle nochmals ein riesen Dankeschön an alle die zur Lösung beigetragen haben (insbesondere an rpi444 md_fg hyle )
Warum sollte new_hwclock.service vom dhcpcd.service abhängig sein.
Das war die Vermutung von md_fg (Beitrag #92). Deshalb die Frage, ob ich die den Inhalt von new_hwclock.service wieder analog Post #59 setzen soll.
Zurzeit stimmt die Systemzeit nach einem Reboot. Werde noch versuchen zu klären, ob dies auch nach einer Stromunterbrechung und ohne LAN der Fall sein wird.
Ich glaube ich habe zumindest einen Fehler entdeckt (wohl ganz im Sinne von "auch ein Blindes Huhn findet mal ein Korn")... Das hier hat mich etwas stutzig gemacht:
Ich habe mich gefragt, woher diese 8 Argumente denn überhaupt kommen sollen? In der Datei new_hwclock.service war in der Zeile "execStart=/sbin/...." ein Kommentar angehängt, also habe ich diesen testweise einmal entfernt und neu gestartet. Siehe da – die Fehlereinträge sind nun verschwunden:
systemctl status new_hwclock.service
● new_hwclock.service - Synchronize system clock from RTC
Loaded: loaded (/etc/systemd/system/new_hwclock.service; disabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2019-11-29 14:02:38 CET; 2min 0s ago
Process: 420 ExecStart=/sbin/hwclock --hctosys --utc (code=exited, status=0/SUCCESS)
Main PID: 420 (code=exited, status=0/SUCCESS)
Nov 29 14:02:27 raspberrypi systemd[1]: Starting Synchronize system clock from RTC...
Nov 29 14:02:38 raspberrypi systemd[1]: new_hwclock.service: Succeeded.
Nov 29 14:02:38 raspberrypi systemd[1]: Started Synchronize system clock from RTC.
journalctl _PID=420
-- Logs begin at Fri 2019-11-29 14:02:23 CET, end at Fri 2019-11-29 14:04:20 CET. --
-- No entries --
Bei systemd-analyze blame wird new_hwclock.service allerdings immer noch vor dhcpcd.service geladen. Muss ich das nun noch etwas ändern, oder kann das mit dem wegfallen der obigen Fehlermeldungen als "kein Problem" angesehen werden?
EDIT:
rpi444 Da warst du wohl schneller
Wurde die RTC nach #83 eingerichtet
Ja, ich bin genau danach vorgegangen. I
systemctl status new_hwclock.service
Hier gibt es mir einen Fehler aus:
● new_hwclock.service - Synchronize system clock from RTC
Loaded: loaded (/etc/systemd/system/new_hwclock.service; static; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2019-11-28 22:43:49 CET; 13h ago
Process: 321 ExecStart=/sbin/hwclock --hctosys --utc # Mit Buster getestet (code=exited, status=1/FAILURE)
Main PID: 321 (code=exited, status=1/FAILURE)
Nov 28 22:43:49 raspberrypi systemd[1]: Starting Synchronize system clock from RTC...
Nov 28 22:43:49 raspberrypi hwclock[321]: hwclock: 4 too many arguments given
Nov 28 22:43:49 raspberrypi hwclock[321]: Try 'hwclock --help' for more information.
Nov 28 22:43:49 raspberrypi systemd[1]: new_hwclock.service: Main process exited, code=exited, status=1/FAILURE
Nov 28 22:43:49 raspberrypi systemd[1]: new_hwclock.service: Failed with result 'exit-code'.
Nov 28 22:43:49 raspberrypi systemd[1]: Failed to start Synchronize system clock from RTC.
Alles anzeigen
Hier die Ausgabe von journalctl _PID=321 (zumindest nehme ich an, dass ich hier den PID-Wert des obigen Prozesses eingeben sollte):
-- Logs begin at Thu 2019-11-28 22:43:45 CET, end at Fri 2019-11-29 12:34:48 CET. --
Nov 28 22:43:49 raspberrypi hwclock[321]: hwclock: 4 too many arguments given
Nov 28 22:43:49 raspberrypi hwclock[321]: Try 'hwclock --help' for more information.
Die Ausgabe von systemd-analyze blame:
5.183s hciuart.service
3.491s apt-daily-upgrade.service
2.792s raspi-config.service
2.222s dev-mmcblk0p2.device
1.855s man-db.service
1.543s udisks2.service
1.331s lightdm.service
1.274s plymouth-quit-wait.service
1.024s dphys-swapfile.service
913ms plymouth-read-write.service
733ms systemd-fsck@dev-disk-by\x2dpartuuid-5e3da3da\x2d01.service
716ms keyboard-setup.service
662ms systemd-timesyncd.service
633ms systemd-logind.service
623ms dhcpcd.service
577ms ssh.service
499ms avahi-daemon.service
462ms wpa_supplicant.service
462ms user@1000.service
461ms networking.service
458ms systemd-udev-trigger.service
374ms rsyslog.service
357ms triggerhappy.service
342ms new_hwclock.service
341ms alsa-restore.service
335ms polkit.service
330ms logrotate.service
325ms systemd-journald.service
325ms gldriver-test.service
301ms rng-tools.service
281ms rpi-eeprom-update.service
279ms systemd-fsck-root.service
250ms fake-hwclock.service
211ms systemd-udevd.service
195ms systemd-tmpfiles-setup.service
194ms systemd-remount-fs.service
158ms boot.mount
149ms bluetooth.service
146ms systemd-modules-load.service
146ms sys-kernel-debug.mount
145ms dev-mqueue.mount
139ms systemd-journal-flush.service
134ms kmod-static-nodes.service
125ms systemd-update-utmp.service
109ms systemd-sysusers.service
105ms systemd-sysctl.service
96ms rc-local.service
95ms systemd-tmpfiles-clean.service
92ms user-runtime-dir@1000.service
92ms systemd-tmpfiles-setup-dev.service
86ms systemd-random-seed.service
83ms plymouth-start.service
80ms systemd-user-sessions.service
72ms console-setup.service
64ms systemd-update-utmp-runlevel.service
54ms nfs-config.service
46ms sys-kernel-config.mount
37ms run-rpc_pipefs.mount
32ms systemd-rfkill.service
32ms ifupdown-pre.service
19ms sys-fs-fuse-connections.mount
Alles anzeigen
Da hier new_hwclock.service vor hcpcd.service gestartet wird (zumindest gehe ich davon aus, da der hwclock-service schneller antwortet), habe ich deine Anpassungen – bis zur Zeile 14 – in der new_hwclock.service vorgenommen.
-----------
Nach dem daemon-Reload habe ich einen Reboot ausgeführt und dann nochmals die obigen Abfragen ausgeführt. Die Ausgaben sind nun wie folgt:
systemctl status new_hwclock.service
● new_hwclock.service - Synchronize system clock from RTC
Loaded: loaded (/etc/systemd/system/new_hwclock.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2019-11-29 12:54:23 CET; 8min ago
Process: 435 ExecStart=/sbin/hwclock --hctosys --utc # In Buster RTC Zeit als Systemzeit setzen (code=exited, status=1/FAILURE)
Main PID: 435 (code=exited, status=1/FAILURE)
Nov 29 12:54:23 raspberrypi systemd[1]: Starting Synchronize system clock from RTC...
Nov 29 12:54:23 raspberrypi hwclock[435]: hwclock: 8 too many arguments given
Nov 29 12:54:23 raspberrypi hwclock[435]: Try 'hwclock --help' for more information.
Nov 29 12:54:23 raspberrypi systemd[1]: new_hwclock.service: Main process exited, code=exited, status=1/FAILURE
Nov 29 12:54:23 raspberrypi systemd[1]: new_hwclock.service: Failed with result 'exit-code'.
Nov 29 12:54:23 raspberrypi systemd[1]: Failed to start Synchronize system clock from RTC.
Alles anzeigen
Die Ausgabe von journalctl _PID=435
-- Logs begin at Fri 2019-11-29 12:54:18 CET, end at Fri 2019-11-29 12:56:37 CET. --
Nov 29 12:54:23 raspberrypi hwclock[435]: hwclock: 8 too many arguments given
Nov 29 12:54:23 raspberrypi hwclock[435]: Try 'hwclock --help' for more information.
Die Ausgabe von systemd-analyze blame:
5.246s hciuart.service
4.962s apt-daily.service
2.370s dev-mmcblk0p2.device
1.830s udisks2.service
1.712s raspi-config.service
946ms dphys-swapfile.service
890ms systemd-fsck@dev-disk-by\x2dpartuuid-5e3da3da\x2d01.service
824ms ssh.service
790ms lightdm.service
773ms plymouth-quit-wait.service
761ms plymouth-read-write.service
760ms keyboard-setup.service
683ms systemd-timesyncd.service
671ms dhcpcd.service
639ms avahi-daemon.service
566ms wpa_supplicant.service
551ms polkit.service
501ms systemd-logind.service
493ms rpi-eeprom-update.service
473ms systemd-udev-trigger.service
459ms networking.service
362ms rsyslog.service
346ms user@1000.service
317ms gldriver-test.service
302ms systemd-fsck-root.service
282ms systemd-journald.service
274ms alsa-restore.service
248ms rng-tools.service
214ms systemd-udevd.service
207ms fake-hwclock.service
203ms triggerhappy.service
201ms systemd-remount-fs.service
194ms systemd-user-sessions.service
170ms systemd-tmpfiles-setup.service
159ms dev-mqueue.mount
145ms sys-kernel-debug.mount
136ms run-rpc_pipefs.mount
135ms systemd-modules-load.service
132ms kmod-static-nodes.service
128ms boot.mount
126ms systemd-update-utmp.service
122ms plymouth-start.service
121ms systemd-journal-flush.service
104ms systemd-update-utmp-runlevel.service
101ms bluetooth.service
98ms systemd-sysusers.service
95ms systemd-random-seed.service
90ms systemd-tmpfiles-setup-dev.service
85ms systemd-sysctl.service
75ms rc-local.service
72ms systemd-rfkill.service
61ms new_hwclock.service
56ms console-setup.service
52ms user-runtime-dir@1000.service
45ms nfs-config.service
41ms sys-kernel-config.mount
27ms ifupdown-pre.service
Alles anzeigen
Hinweis: Ich bin nicht zuhause, daher kann ich den Strom/Lan nicht trennen. Die Systemzeit wird aktuell nur korrekt sein, weil das LAN verbunden ist.
Nach ein wenig Nachdenken ist mir der Beitrag #59 in den Sinn gekommen, welcher ja die RTC-Zeit an das System weiter gibt (also genau, dass was bei mir eben nicht passiert).
Habe nun die udev-Rule und den Service angelegt – also Pi wieder vom Strom & LAN getrennt und ohne letzteres wieder neu gestartet.
Fazit: Funktioniert auch damit nicht.
So – mein Feedback:
Buster ist installiert – ging vom Download des Images bis zu den finalen Updates nach der Installation insgesamt eine gute Stunde.
Dann habe ich mich an die Anleitung von md_fg gehalten und diese durchgespielt. Aktueller Stand:
– RTC wird erkannt und gibt auch die richtige Zeit aus
– Nach einem Neustart (Strom war weg) und ohne LAN zieht das System aber die Uhrzeit nicht mehr richtig (es nimmt die letzte bekannte Uhrzeit als der Pi noch am Strom hing)
– Hänge ich das LAN wieder an, updated das System die Zeit
Ich könnte nun natürlich wieder anfangen herumzuspielen und Sachen zu verändern, aber das lasse ich diesesmal ganz schön sein und frage euch was zu tun ist?
Was mir aufgefallen ist: systemctl status hwclock.service ist zwar "masked" (wie es ja sein soll) - aber auch inactive.
● hwclock.service
Loaded: masked (Reason: Unit hwclock.service is masked.)
Active: inactive (dead)
Ist das richtig so?
--------
EDIT: Hier noch ein paar Ausgaben:
systemctl status hwclock.service
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: active (running) since Thu 2019-11-28 22:03:36 CET; 26min ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 274 (systemd-timesyn)
Status: "Synchronized to time server for the first time [2606:4700:f1::1]:123 (2.debian.pool.ntp.org)."
Tasks: 2 (limit: 2200)
Memory: 3.0M
CGroup: /system.slice/systemd-timesyncd.service
└─274 /lib/systemd/systemd-timesyncd
Nov 28 22:03:36 raspberrypi systemd[1]: Starting Network Time Synchronization...
Nov 28 22:03:36 raspberrypi systemd[1]: Started Network Time Synchronization.
Nov 28 22:10:20 raspberrypi systemd-timesyncd[274]: Timed out waiting for reply from [2606:4700:f1::123]:123 (2.debian.pool.ntp.org).
Nov 28 22:22:02 raspberrypi systemd-timesyncd[274]: Synchronized to time server for the first time [2606:4700:f1::1]:123 (2.debian.pool.ntp.org).
Alles anzeigen
timedatectl (ohne LAN gleich nach dem Neustart)
Local time: Do 2019-11-28 22:06:48 CET
Universal time: Do 2019-11-28 21:06:48 UTC
RTC time: Do 2019-11-28 21:18:31
Time zone: Europe/Zurich (CET, +0100)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
timedatectl (mit angeschlossenem LAN)
Die Anleitung habe ich nur kurz überflogen und... Nicht empfehlenswert!
ok – überredet
Das Notfall Image würde ich auch nicht benutzen da ist ja schon vieles falsch oder sinnlos Konfiguriert.
Wo du natürlich recht hast...
Ich hoffe dann, ich kriege meine anderen beiden Sachen (Mediaplayer und iPad-Screen) auch unter Buster wieder hin.
wenn Du manuell:
sudo sh -x /etc/init.d/hwclock.shausführst.
Ausgabe:
+ BADYEAR=no
+ HWCLOCKACCESS=yes
+ HWCLOCKPARS=
+ HCTOSYS_DEVICE=rtc0
+ unset TZ
+ hwclocksh
+ [ ! -x /sbin/hwclock ]
+ [ ! -r /etc/default/rcS ]
+ [ ! -r /etc/default/hwclock ]
+ . /etc/default/hwclock
+ HWCLOCKACCESS=yes
+ HCTOSYS_DEVICE=rtc0
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ [ -r /lib/lsb/init-functions.d/40-systemd ]
+ . /lib/lsb/init-functions.d/40-systemd
+ _use_systemctl=0
+ [ -d /run/systemd/system ]
+ [ -n ]
+ [ hwclock.sh = init-d-script ]
+ [ hwclock.sh = ]
+ executable=/etc/init.d/hwclock.sh
+ argument=
+ prog=hwclock.sh
+ service=hwclock.service
+ systemctl -p LoadState --value show hwclock.service
+ state=bad-setting
+ [ bad-setting = masked ]
+ [ 1442 -ne 1 ]
+ [ -z ]
+ readlink -f /etc/init.d/hwclock.sh
+ [ bad-setting != not-found ]
+ _use_systemctl=1
+ systemctl -p CanReload --value show hwclock.service
+ [ no = no ]
+ [ = reload ]
+ [ 1 = 1 ]
+ set +e
+ set +u
+ [ -r /lib/lsb/init-functions.d/99-plymouth ]
+ . /lib/lsb/init-functions.d/99-plymouth
+ plymouth --ping
+ return
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ BADYEAR=
+ log_success_msg Usage: hwclock.sh {start|stop|reload|force-reload|show}
+ [ -n Usage: hwclock.sh {start|stop|reload|force-reload|show} ]
+ log_begin_msg Usage: hwclock.sh {start|stop|reload|force-reload|show}
+ log_begin_msg_pre Usage: hwclock.sh {start|stop|reload|force-reload|show}
+ log_daemon_msg_pre Usage: hwclock.sh {start|stop|reload|force-reload|show}
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z ]
+ FANCYTTY=1
+ true
+ echo -n [....]
[....] + [ -z Usage: ]
+ echo -n Usage: hwclock.sh {start|stop|reload|force-reload|show}
Usage: hwclock.sh {start|stop|reload|force-reload|show}+ log_begin_msg_post Usage: hwclock.sh {start|stop|reload|force-reload|show}
+ :
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 2
+ GREEN=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ /usr/bin/tput civis
+ /usr/bin/tput sc
+ /usr/bin/tput hpa 0
+ [ 0 -eq 0 ]
+ /bin/echo -ne [ ok
[ ok + /usr/bin/tput rc
+ /usr/bin/tput cnorm
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
.
+ log_end_msg_post 0
+ :
+ return 0
+ log_success_msg start sets kernel (system) clock from hardware (RTC) clock
+ [ -n start sets kernel (system) clock from hardware (RTC) clock ]
+ log_begin_msg start sets kernel (system) clock from hardware (RTC) clock
+ log_begin_msg_pre start sets kernel (system) clock from hardware (RTC) clock
+ log_daemon_msg_pre start sets kernel (system) clock from hardware (RTC) clock
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ echo -n [....]
[....] + [ -z start ]
+ echo -n start sets kernel (system) clock from hardware (RTC) clock
start sets kernel (system) clock from hardware (RTC) clock+ log_begin_msg_post start sets kernel (system) clock from hardware (RTC) clock
+ :
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 2
+ GREEN=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ /usr/bin/tput civis
+ /usr/bin/tput sc
+ /usr/bin/tput hpa 0
+ [ 0 -eq 0 ]
+ /bin/echo -ne [ ok
[ ok + /usr/bin/tput rc
+ /usr/bin/tput cnorm
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
.
+ log_end_msg_post 0
+ :
+ return 0
+ log_success_msg stop and reload set hardware (RTC) clock from kernel (system) clock
+ [ -n stop and reload set hardware (RTC) clock from kernel (system) clock ]
+ log_begin_msg stop and reload set hardware (RTC) clock from kernel (system) clock
+ log_begin_msg_pre stop and reload set hardware (RTC) clock from kernel (system) clock
+ log_daemon_msg_pre stop and reload set hardware (RTC) clock from kernel (system) clock
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ echo -n [....]
[....] + [ -z stop ]
+ echo -n stop and reload set hardware (RTC) clock from kernel (system) clock
stop and reload set hardware (RTC) clock from kernel (system) clock+ log_begin_msg_post stop and reload set hardware (RTC) clock from kernel (system) clock
+ :
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 2
+ GREEN=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ /usr/bin/tput civis
+ /usr/bin/tput sc
+ /usr/bin/tput hpa 0
+ [ 0 -eq 0 ]
+ /bin/echo -ne [ ok
[ ok + /usr/bin/tput rc
+ /usr/bin/tput cnorm
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm-256color != x ]
+ [ xxterm-256color != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
.
+ log_end_msg_post 0
+ :
+ return 0
+ return 1
Alles anzeigen
Auch hier taucht das Bad-setting mehrmals auf; denke das ist ein schlechtes Zeichen...
Dann noch eine Frage zur sudo nano /lib/udev/hwclock-set
Bei mir sind die Zeilen
zurzeit aktiv. Habe aber in anderen Beiträgen gesehen, dass diese teilweise inaktiv (mit #) gesetzt sind und in den Beitrag-Kommentaren hat dann auch jemand bestätigt, dass dies unter Buster funktioniert hat. Weiss jemand, was nun unter Buster korrekt/"richtiger" ist?
Wie ist jetzt die Ausgabe von: Code
ls -la /etc/init.d/hwclock.sh
systemctl cat hwclock.service
Das geht leider nicht; nach der Eingabe kommt dann:
Werde ich dann vielleicht noch nachholen. Ich brauche den Pi in rund zwei Wochen im Einsatz – und ich wollte die anderen bestehenden Installationen (du hast da ja auch mitgeholfen -> Mediaplayer und iPad-Monitor via AdHoc) nicht unnötig kaputt machen. Deswegen habe ich mich für das Update entschieden, in der Hoffnung, dass die Dinge dann auch noch laufen werden (ohne das ich alles nochmals neu machen muss).
Hmm – schaut nicht gut aus:
sudo systemctl enable hwclock
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Alles anzeigen
sudo systemctl start hwclock
Failed to start hwclock.service: Unit hwclock.service has a bad unit file setting.
See system logs and 'systemctl status hwclock.service' for details.
systemctl status hwclock
Und da war "systemctl enable hwclock" bzw. "systemctl enable hwclock.service" bzw. start/reloard-or-restart/status/disable usw., auch dabei ?
Nein, war es nicht. Aufgrund deines Inputs in Post #70 ist dies aber wohl offensichtlich notwendig. Ich werde das ausführen und schauen wie dann die Ausgabe von timedatectl ist...
Zurzeit sieht es wie folgt aus:
systemctl status systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
Hinweis: systemctl daemon-reload bringt die Warnungs-Meldung nicht weg.
timedatectl
Local time: Do 2019-02-14 22:39:31 CET
Universal time: Do 2019-02-14 21:39:31 UTC
RTC time: Do 2019-11-28 09:05:46
Time zone: Europe/Zurich (CET, +0100)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
Die RTC wird zumindest noch erkannt (d.h. kein i2c-Problem), zudem ist es die einzigste Zeit die korrekt ist (obwohl der Pi zurzeit mit dem Netzwerk verbunden ist).
PS: Kann den Pi erst heute Abend wieder vom Strom und dem LAN nehmen um die RTC-Funktion zu testen...
Da muss ich allerdings erwähnen: Ich habe rpi-update nicht ausgeführt! Nach Eingabe des Befehls kam da eine doch recht böse Systemwarnung, dass man rpi-update nicht ohne triftigem Grund ausführen solle – deshalb habe ich diesen Schritt dann übersprungen.