Update: I managed to temporarily remove watchdog, and the reboot issue still persists.
Beiträge von mortee
-
-
Hi from the future everyone, I am having this same issue. I'm on HC2, and recently I got myself to upgrade to OMV 7. Ever since, my system reboots without any shutdown procedure every time I try to run dpkg --configure -a or systemctl daemon-reload or the other usual suspects.
The bad news are:
- my system uses u-boot (so I assume that means not petitboot)
- I don't have /etc/udev/rules.d/99-odroid-circuitpython.rules at all
and the problem still occurs. So in any case, the above two don't seem to be causing this error.
Funny thing, I tried the previous tip regarding watchdog, but systemctl disable --now watchdog also triggered the reboot.
I'm not sure whether the error below may or may not influence this bug:
Code
Alles anzeigen$ sudo systemctl status watchdog × watchdog.service - watchdog daemon Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Thu 2025-06-26 17:53:51 CEST; 3min 45s ago Process: 2924 ExecStartPre=/bin/sh -c [ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module (code=exited, status=1/FAILURE) Process: 2926 ExecStopPost=/bin/sh -c [ $run_wd_keepalive != 1 ] || false (code=exited, status=0/SUCCESS) CPU: 124ms Jun 26 17:53:51 nas systemd[1]: Starting watchdog.service - watchdog daemon... Jun 26 17:53:51 nas sh[2925]: modprobe: FATAL: Module softdog not found in directory /lib/modules/6.6.88-current-odroidxu4 Jun 26 17:53:51 nas systemd[1]: watchdog.service: Control process exited, code=exited, status=1/FAILURE Jun 26 17:53:51 nas systemd[1]: watchdog.service: Failed with result 'exit-code'. Jun 26 17:53:51 nas systemd[1]: Failed to start watchdog.service - watchdog daemon. Jun 26 17:53:51 nas systemd[1]: watchdog.service: Triggering OnFailure= dependencies.
The irony is that reinstalling it (or anything, for that matter) doesn't work, since the system reboots at this point:
-
Even so, it is useful in many cases.
No doubt about that - I really meant it sounds awesome!
-
Now this can be done with omv-regen
Wow, this sounds amazing! Why on Earth haven't I stumbled upon this, while frantically googling for a system restore solution for THREE DAYS now? This should somehow be made more obvious/visible.
That said, it assumes the user has access to the old OMV system when deciding to migrate. So it won't work if the system disk is dead, and only backups created using omv-backup is available.
My method only assumes the latter, and the output of dpkg --get-selections from the old system.
-
I just managed to move my configuration from (borg) backup onto a completely fresh install on a new SD card, after the previous one failed. If someone is still interested, I might share the process details here.
-
Thanks, disabling the testing repo did fix the issue. It also unlocked a few major updtaes, like docker-ce. I wonder why it was enabled in the first place?... I don't remember having a reason to enable it manually anytime in the past...
-
Code
Alles anzeigenReading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: openmediavault-omvextrasorg 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 52.8 kB of archives. After this operation, 21.5 kB of additional disk space will be used. Err:1 https://openmediavault-plugin-developers.github.io/packages/debian shaitan-testing/main armhf openmediavault-omvextrasorg all 6.2 404 Not Found [IP: 185.199.108.153 443] ** CONNECTION LOST **
-
-
With all due respect, no matter how many times I watch the login prompt on the console timeout, or reboot the system, or upgrade OMV - the only thing that triggers the regeneration of the file (and thus the message) is when I manually update a network interface on the UI.
-
-
My bad, apparently when I actually modify a network interface, the file does get updated. But not on reboot, nor on OMV upgrade. The point is, it keeps displaying outdated version information.
-
Exactly the same.
-
Since I already ran this command manually, it said that the file is in the correct state, and the reload_issue state didn't need to run. After making some manual changes to the file, the command did indeed restore it to the correct state, and ran reload_state too.
Anyway, this apparently doesn't happen neither on reboots nor on system upgrades.
-
Weird, I'm subscribed to this topic (I created it), but I never received any notification about replies.
`omv-salt deploy run issue` indeed updates the file for me too, but apparently I have to run it manually, it doesn't get updated on OMV upgrades nor network interface changes.
-
I just discovered that I have an /etc/issue file dated from almost a year ago, and it shows OMV version 6.0.21-1, while currently I have 6.3.2-2.
Made me think whether this is supposed to be regenerated on updates and/or network interface changes. Or is it generated only once on installation, and never refreshed again?
-
-
What you are looking for, you need to enable in System >> Monitoring
Also that. Okay, it's maybe a tad confusing, having two completely different things under the same name, and also enabling graphs shows an empty chart instead of giving a hint about what's missing for it to work correctly... Anyhow, I hope I can get it to work now.
-
-
Okay, so I've had this weird issue of all my performance graphs in the UI were empty since like OMV 3 or 4, but I haven't given this much thought.
Even though under System / Power Management "Monitoring" is checked, Diagnostics / Performance Statistics says "System monitoring is disabled. To enable it, please go to the settings page" in all categories.
Now I decided to look at the bottom of this. From what I found online, I guess those graphs make use of collectd and rrcached, so I started looking for references to those in the syslog. And sure enough, I found such entries:
CodeMar 24 11:33:15 nas folder2ram[384]: start /var/lib/rrdcached Mar 24 12:08:13 nas monit[1833]: HttpRequest: error -- client []: HTTP/1.0 400 There is no service named "rrdcached" Mar 24 12:08:13 nas monit[22591]: There is no service named "rrdcached"
I think it's relevant that /etc/systemd/system/ doesn't have any rrcached entry indeed.
As expected, those don't work either:
Code
Alles anzeigen$ sudo systemctl enable rrcached.service Failed to enable unit: Unit file rrcached.service does not exist. $ sudo omv-salt deploy run collectd [...] ID: unmonitor_collectd_service Function: cmd.run Name: monit unmonitor collectd || true Result: True Comment: Command "monit unmonitor collectd || true" run Started: 13:10:35.932226 Duration: 48.878 ms Changes: ---------- pid: 31833 retcode: 0 stderr: There is no service named "collectd" stdout: ---------- ID: stop_collectd_service Function: service.dead Name: collectd Result: True Comment: The service collectd is already dead Started: 13:10:36.023096 Duration: 173.765 ms Changes:
(There IS a /etc/systemd/system/collectd.service.d/openmediavault.conf, but it's dependent on rrcached, so I assume that's reported as missing because of this.)
I should add that it appears to be functional when invoked using systemctl:
Code
Alles anzeigen$ sudo systemctl start rrdcached $ systemctl status rrdcached ● rrdcached.service - LSB: start or stop rrdcached Loaded: loaded (/etc/init.d/rrdcached; generated) Active: active (running) since Thu 2022-03-24 13:03:30 CET; 1min 27s ago Docs: man:systemd-sysv-generator(8) Process: 26706 ExecStart=/etc/init.d/rrdcached start (code=exited, status=0/SUCCESS) Tasks: 7 (limit: 4440) Memory: 6.8M CPU: 101ms CGroup: /system.slice/rrdcached.service └─26711 /usr/bin/rrdcached -B -F -f 3600 -w 900 -b /var/lib/rrdcached/db/ -j /var/lib/rrdcached/journal/ -> Mar 24 13:03:30 nas systemd[1]: Starting LSB: start or stop rrdcached... Mar 24 13:03:30 nas rrdcached[26706]: rrdcached started. Mar 24 13:03:30 nas systemd[1]: Started LSB: start or stop rrdcached.
So, what might have gone wrong, and how do I fix it?
-
Okay, thank you. That was my primary goal: to learn what's the recommended channel to get notified, since my idea didn't work.