Closed eikowagenknecht closed 3 years ago
For reference, this is what it looks like and should look like with an OH2 installation:
Cannot reproduce on a fresh install.
Run systemctl list-timers
and show output. Eventually do systemctl reset-failed
.
Run systemctl start firemotd.service
to regenerate motd and see after some minutes if that made a difference (login again).
Thanks for trying to reproduce this.
openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2021-01-14 21:51:49 CET 10h left Wed 2021-01-13 21:51:49 CET 13h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2021-01-14 23:27:36 CET 12h left Thu 2021-01-14 07:35:19 CET 3h 40min ago apt-daily.timer apt-daily.service
Fri 2021-01-15 00:00:00 CET 12h left Thu 2021-01-14 00:00:22 CET 11h ago logrotate.timer logrotate.service
Fri 2021-01-15 00:00:00 CET 12h left Thu 2021-01-14 00:00:22 CET 11h ago man-db.timer man-db.service
Fri 2021-01-15 06:16:10 CET 19h left Thu 2021-01-14 06:39:19 CET 4h 36min ago apt-daily-upgrade.timer apt-daily-upgrade.service
n/a n/a Wed 2020-12-23 04:58:19 CET 3 weeks 1 days ago firemotd.timer firemotd.service
openhabian@pi-openhab3:~ $ systemctl reset-failed
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or other units.
Authenticating as: ,,, (openhabian)
Password:
==== AUTHENTICATION COMPLETE ===
openhabian@pi-openhab3:~ $
openhabian@pi-openhab3:~ $ systemctl start firemotd.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'firemotd.service'.
Authenticating as: ,,, (openhabian)
Password:
==== AUTHENTICATION COMPLETE ===
openhabian@pi-openhab3:~ $
Unfortunately I updated yesterday so currently "0" is the correct value:
openhabian@pi-openhab3:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Not sure it it's possible to downgrade some not-so-important package to test this.
Is the duplicate configuration of sources on purpose? If not, should I open another Issue or do you think this is related?
W: Target Packages (main/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB.UTF-8) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Packages (main/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB.UTF-8) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
Is the duplicate configuration of sources on purpose? If not, should I open another Issue or do you think this is related?
Depends and no. Just delete either of those files depending on which OH version you want to keep running.
openhabian@pi-openhab3:~ $ systemctl start firemotd.service
Not sure if it's possible to downgrade some not-so-important package to test this.
A firemotd run regenerates all of the banner so you can change anything that would affect this.
Or just install some package with an explicit older version (apt-cache madison pkg .... apt install pkg=
Depends and no. Just delete either of those files depending on which OH version you want to keep running.
Ok, the current content is the same anyways:
openhabian@pi-openhab3:/etc/apt/sources.list.d $ cat openhab.list
deb https://dl.bintray.com/openhab/apt-repo2 stable main
openhabian@pi-openhab3:/etc/apt/sources.list.d $ cat openhab2.list
deb https://dl.bintray.com/openhab/apt-repo2 stable main
So I delete the openhab2.list (openhab 2 was never installed on this system, only openhab 3).
list-timers after the commands above:
openhabian@pi-openhab3:/etc/apt/sources.list.d $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2021-01-14 21:51:49 CET 10h left Wed 2021-01-13 21:51:49 CET 13h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2021-01-14 23:27:36 CET 11h left Thu 2021-01-14 07:35:19 CET 4h 10min ago apt-daily.timer apt-daily.service
Fri 2021-01-15 00:00:00 CET 12h left Thu 2021-01-14 00:00:22 CET 11h ago logrotate.timer logrotate.service
Fri 2021-01-15 00:00:00 CET 12h left Thu 2021-01-14 00:00:22 CET 11h ago man-db.timer man-db.service
Fri 2021-01-15 06:16:10 CET 18h left Thu 2021-01-14 06:39:19 CET 5h 6min ago apt-daily-upgrade.timer apt-daily-upgrade.service
n/a n/a Wed 2020-12-23 04:58:19 CET 3 weeks 1 days ago firemotd.timer firemotd.service
6 timers listed.
Pass --all to see loaded but inactive timers, too.
A firemotd run regenerates all of the banner so you can change anything that would affect this.
Uptime, load etc. is always updated correctly on every login. That was the case before as well, only apt updates were always 0.
Or just install some package with an explicit older version (apt-cache madison pkg .... apt install pkg=)
That doesn't seem to work because only the newest version is shown (example here is for tzdata, which I updated yesterday):
openhabian@pi-openhab3:/etc/apt/sources.list.d $ apt-cache madison tzdata
tzdata | 2020e-0+deb10u1 | http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
After a system reboot list-timers output is:
openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2021-01-14 12:10:51 CET 6min left n/a n/a systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2021-01-15 00:00:00 CET 11h left Thu 2021-01-14 00:00:22 CET 12h ago logrotate.timer logrotate.service
Fri 2021-01-15 00:00:00 CET 11h left Thu 2021-01-14 00:00:22 CET 12h ago man-db.timer man-db.service
Fri 2021-01-15 01:21:48 CET 13h left Thu 2021-01-14 07:35:19 CET 4h 29min ago apt-daily.timer apt-daily.service
Fri 2021-01-15 06:56:51 CET 18h left Thu 2021-01-14 06:39:19 CET 5h 25min ago apt-daily-upgrade.timer apt-daily-upgrade.service
n/a n/a Thu 2021-01-14 11:55:43 CET 9min ago firemotd.timer firemotd.service
So it looks like the firemotd.timer was not working until I rebooted the system?
.timer file shows:
openhabian@pi-openhab3:~ $ cat /etc/systemd/system/firemotd.timer
[Unit]
Description=Daily generation of FireMotD stats
[Timer]
OnCalendar=*-*-* 00:00
RandomizedDelaySec=6h
Persistent=true
[Install]
WantedBy=timers.target
I'll keep an eye on this when the next apt updates are available.
According to https://www.freedesktop.org/software/systemd/man/systemd.time.html the usual syntax would be OnCalendar=*-*-* 00:00:00
or OnCalendar=daily
. Maybe this has to do something with the missing ":00" in the .timer file? (Just a guess!)
missing ":00" in the .timer file?
try for yourself but the link you quote also says my syntax is valid too
You're right, I missed that sentence. I tried
sudo systemctl reenable --now firemotd.timer
-> No change (still "n/a" as NEXT which I think is a bad thing and shows the timer's not working)Then I tried:
sudo systemctl stop firemotd.timer
sudo systemctl start firemotd.timer
-> Now finally it appears in the list with a next date:
openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2021-01-14 20:43:37 CET 7h left Thu 2021-01-14 07:35:19 CET 5h 52min ago apt-daily.timer apt-daily.service
Fri 2021-01-15 00:00:00 CET 10h left Thu 2021-01-14 00:00:22 CET 13h ago logrotate.timer logrotate.service
Fri 2021-01-15 00:00:00 CET 10h left Thu 2021-01-14 00:00:22 CET 13h ago man-db.timer man-db.service
Fri 2021-01-15 02:30:02 CET 13h left Thu 2021-01-14 11:55:43 CET 1h 32min ago firemotd.timer firemotd.service
Fri 2021-01-15 06:24:21 CET 16h left Thu 2021-01-14 06:39:19 CET 6h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Fri 2021-01-15 12:11:02 CET 22h left Thu 2021-01-14 12:11:02 CET 1h 17min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
No idea why that helped, though.
I can do all the enabling, diasabling and reenabling I like after that, it still shows up in NEXT (only when it's not currently disabled of course).
As said before, I did not tamper with the system at all (yet) because it's only an openHAB 3 test installation for me, so it's weird that you can not reproduce on a fresh install. I'll try again myself when I install openHAB 3 from scratch the next time.
Broken again (and there is an update available now, I dindn't install it so the tests can continue :-)):
I did not restart the system or even login in the meantime.
Try if this fixes your issue: in /etc/systemd/system, edit firemotd.{timer,service} In .timer [Timer] section, set Persistent=true RemainAfterElapse=true
In .service [Service] section RemainAfterExit=no
and systemctl daemon-reload and systemctl restart firemotd.timer. Also systemctl status firemotd.service and if running stop it
You can actually set OnCalendar=minutely for a test so you don't have to wait. Or add your own X.timer/X.service files.
Key to look for is what systemctl list-timers outputs for firemotd.timer next run
Thank you for taking the time to experiment with me here! This is getting weirder.
I edited the files as you said (Persistent was already on true, so I left that one as it was).
openhabian@pi-openhab3:/etc/systemd/system $ sudo nano firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ sudo nano firemotd.service
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl daemon-reload
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl restart firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2021-01-26 18:29:07 CET 5h 3min left Tue 2021-01-26 13:22:12 CET 3min 9s ago apt-daily.timer apt-daily.service
Wed 2021-01-27 00:00:00 CET 10h left Tue 2021-01-26 00:00:22 CET 13h ago logrotate.timer logrotate.service
Wed 2021-01-27 00:00:00 CET 10h left Tue 2021-01-26 00:00:22 CET 13h ago man-db.timer man-db.service
Wed 2021-01-27 06:53:09 CET 17h left Tue 2021-01-26 06:38:22 CET 6h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET 22h left Tue 2021-01-26 12:18:22 CET 1h 6min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a n/a Tue 2021-01-26 13:25:14 CET 7s ago firemotd.timer firemotd.service
So apparently nothing changed (yet). Then I set OnCalendar=minutely followed by another service restart:
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl daemon-reload
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl restart firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2021-01-26 16:33:36 CET 3h 7min left Tue 2021-01-26 13:25:14 CET 1min 1s ago firemotd.timer firemotd.service
Wed 2021-01-27 00:00:00 CET 10h left Tue 2021-01-26 00:00:22 CET 13h ago logrotate.timer logrotate.service
Wed 2021-01-27 00:00:00 CET 10h left Tue 2021-01-26 00:00:22 CET 13h ago man-db.timer man-db.service
Wed 2021-01-27 00:12:22 CET 10h left Tue 2021-01-26 13:22:12 CET 4min 3s ago apt-daily.timer apt-daily.service
Wed 2021-01-27 06:09:52 CET 16h left Tue 2021-01-26 06:38:22 CET 6h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET 22h left Tue 2021-01-26 12:18:22 CET 1h 7min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Now it shows up in the list.
But what's weird is the date. See "LEFT: 3h 7min". Currently it's 13:26. I just set it to minutely, so shouldn't that be like... next minute (?)
2 hours later it still is there:
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2021-01-26 16:33:36 CET 29min left Tue 2021-01-26 13:25:14 CET 2h 38min ago firemotd.timer firemotd.service
Wed 2021-01-27 00:00:00 CET 7h left Tue 2021-01-26 00:00:22 CET 16h ago logrotate.timer logrotate.service
Wed 2021-01-27 00:00:00 CET 7h left Tue 2021-01-26 00:00:22 CET 16h ago man-db.timer man-db.service
Wed 2021-01-27 00:12:22 CET 8h left Tue 2021-01-26 13:22:12 CET 2h 41min ago apt-daily.timer apt-daily.service
Wed 2021-01-27 06:09:52 CET 14h left Tue 2021-01-26 06:38:22 CET 9h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET 20h left Tue 2021-01-26 12:18:22 CET 3h 45min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
... but after the time has passed, it's back to before (= not working):
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-01-27 00:00:00 CET 5h 11min left Tue 2021-01-26 00:00:22 CET 18h ago logrotate.timer logrotate.service
Wed 2021-01-27 00:00:00 CET 5h 11min left Tue 2021-01-26 00:00:22 CET 18h ago man-db.timer man-db.service
Wed 2021-01-27 00:12:22 CET 5h 23min left Tue 2021-01-26 13:22:12 CET 5h 26min ago apt-daily.timer apt-daily.service
Wed 2021-01-27 06:09:52 CET 11h left Tue 2021-01-26 06:38:22 CET 12h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET 17h left Tue 2021-01-26 12:18:22 CET 6h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a n/a Tue 2021-01-26 16:34:12 CET 2h 14min ago firemotd.timer firemotd.service
Also the count has not been updated at 16:33 apparently:
###############################################################################
############### pi-openhab3 #################################################
###############################################################################
## Ip = 192.168.40.41
## Release = Raspbian GNU/Linux 10 (buster)
## Kernel = Linux 5.4.83-v7l+
## Platform = Started Check for Raspberry Pi EEPROM updates.
## Uptime = 12 day(s). 6:54:23
## CPU Usage = 1.01% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 0.00, 5m: 0.03, 15m: 0.00
## Memory = Free: 2.86GB (76%), Used: 0.92GB (24%), Total: 3.78GB
## Swap = Free: 2.58GB (100%), Used: 0.00GB (0%), Total: 2.58GB
## Root = Free: 51.43GB (91%), Used: 4.57GB (9%), Total: 58.42GB
## Updates = 0 apt updates available.
## Sessions = 2 session(s)
## Processes = 126 running processes of 32768 maximum processes
###############################################################################
_ _ _ ____ _
___ ___ ___ ___ | | | | / \ | __ ) (_) ____ ___
/ _ \ / _ \ / _ \ / _ \ | |_| | / _ \ | _ \ | | / _ \ / _ \
| (_) | (_) | __/| | | || _ | / ___ \ | |_) )| || (_) || | | |
\___/| __/ \___/|_| |_||_| |_|/_/ \_\|____/ |_| \__|_||_| | |
|_| 3.0.0 - Release Build
Looking for a place to get started? Check out 'sudo openhabian-config' and the
documentation at https://www.openhab.org/docs/installation/openhabian.html
The openHAB dashboard can be reached at http://pi-openhab3:8080
To interact with openHAB on the command line, execute: 'openhab-cli --help'
openhabian@pi-openhab3:~ $ sudo apt-get upgrade
[sudo] password for openhabian:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
firmware-atheros firmware-brcm80211 firmware-libertas firmware-misc-nonfree firmware-realtek rpi-eeprom
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.9 MB of archives.
After this operation, 1,584 kB of additional disk space will be used.
I just set it to minutely, so shouldn't that be like... next minute (?)
For me that worked (although I used an additional service not the existing one). Did you do systemctl daemon-restart ?
Here's again what I use:
[21:52:24] root@openhab:/home/openhabian# cat /etc/systemd/system/firemotd.service
[Unit]
Description=Periodic FireMotD stats regeneration
After=network.target network-online.target
[Service]
Type=oneshot
User=root
Group=root
#RemainAfterExit=yes
RemainAfterExit=no
ExecStart=/usr/local/bin/FireMotD -S -D all &> /dev/null
[Install]
WantedBy=multi-user.target
[21:53:13] root@openhab:/home/openhabian# cat /etc/systemd/system/firemotd.timer
[Unit]
Description=Daily generation of FireMotD stats
[Timer]
OnCalendar=*-*-* 00:00
RandomizedDelaySec=6h
Persistent=true
[Install]
WantedBy=timers.target
Yes I did all the restarts as you can see in my second code box. I‘m totally lost why this happens the way it does, especially with the minutely setting that results in some hours.
Did a system reboot now for good measure and now it seems to kindof work, the update count has been updated. But the NEXT date is still way of for my current "minutely" setting (15min ago + 58min left != 1 minute):
openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-01-27 00:00:00 CET 42min left Tue 2021-01-26 00:00:22 CET 23h ago logrotate.timer logrotate.service
Wed 2021-01-27 00:00:00 CET 42min left Tue 2021-01-26 00:00:22 CET 23h ago man-db.timer man-db.service
Wed 2021-01-27 00:16:14 CET 58min left Tue 2021-01-26 23:02:28 CET 15min ago firemotd.timer firemotd.service
Wed 2021-01-27 06:49:57 CET 7h left Tue 2021-01-26 06:38:22 CET 16h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Wed 2021-01-27 09:36:15 CET 10h left Tue 2021-01-26 23:02:28 CET 15min ago apt-daily.timer apt-daily.service
Wed 2021-01-27 23:17:26 CET 23h left Tue 2021-01-26 23:17:26 CET 20s ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
6 timers listed.
Pass --all to see loaded but inactive timers, too.
If it‘s only me who is affected (seems to be that way?) it‘s probably best to write it off as some weird quirk that only happens in special circumstances and not spend too much time on this.
I‘ll reinstall everything with the new image you uploaded some days ago and see if that somehow fixes it.
ok I'll close this then. You can reopen it if you hit another issue but please make sure it's reproduceable before you open
Just for reference.. with the "minutely" setting and a reboot it continues to work. But it only fires about every few hours instead of every minute:
openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-01-27 08:59:43 CET 5min left Wed 2021-01-27 04:32:51 CET 4h 21min ago firemotd.timer firemotd.service
...
If I was to make an educated guess: this is because you didn't change RandomizedDelaySec so it's still 6h
openhabian@devpi:/etc/systemd/system $ cat t.timer
[Unit]
Description=generation of FireMotD stats every minute
[Timer]
#OnCalendar=*-*-* 00:00
OnCalendar=minutely
RandomizedDelaySec=0
Persistent=true
RemainAfterElapse=true
[Install]
WantedBy=timers.target
You are right. Didn't see the RandomizedDelaySec setting. That of course displays why the delay was longer. So now I set it to "0" (followed by daemon-reload and restart timer) and the first execution after that is just fine on the next full minute... and then it gets stuck again, so everything is back to start:
openhabian@pi-openhab3:/etc/systemd/system $ sudo nano firemotd.timer
[... change RandomizedDelaySec to 0...]
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl daemon-reload
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl restart firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-01-27 16:23:00 CET 27s left Wed 2021-01-27 16:22:23 CET 9s ago firemotd.timer firemotd.service
[...1 minute later...]
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
n/a n/a Wed 2021-01-27 16:23:38 CET 52ms ago firemotd.timer firemotd.service
also right before the next full minute ? It's n/a while running.
Ok, i checked this every few seconds now and it seems it's running (in n/a state) from :00 to ~:20 and then scheduled again to run the next full minute. Conclusion: Your proposed changes (
in /etc/systemd/system, edit firemotd.{timer,service} In .timer [Timer] section, set RemainAfterElapse=true
In .service [Service] section RemainAfterExit=no
and systemctl daemon-reload and systemctl restart firemotd.timer
) followed by a complete system restart seem to have fixed it.
For me it seems plausible, quoting the official documentation here:
Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running. There is no concept of spawning new service instances in this case. Due to this, services with RemainAfterExit= set (which stay around continuously even after the service's main process exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and then stay around forever.
Also RemainAfterElapse defaults to true, so it can probably be left out.
Maybe it's worth including this in the next distribution, since it fixed it for me and doesn't cause other side effects for you (as far as I understand)?
Maybe it's worth including this in the next distribution, since it fixed it for me and doesn't cause other side effects for you (as far as I understand)?
Issue information:
My openHAB 3 instance has been running for 22 days straight now so I though I'd check for linux updates. But nothing shows up in motd:
But updates are available:
Also there seems to be some duplicate configuration of sources (openhab / openhab2).
I have not touched anything systemwise. This is a default out-of-the-box installation.
System information:
Pi4, installed with the 1.6.2 image.
cat /etc/os-release
anduname -m
: