Beiträge von mortee

Update: I managed to temporarily remove watchdog, and the reboot issue still persists.

Zitat von mesa57

Code

sudo rm -f /etc/udev/rules.d/99-odroid-circuitpython.rules

With this change OMV7 on HC4 with Petiteboot works fine.

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:

$ 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:

$ sudo apt-get install --reinstall watchdog
...
Unpacking watchdog (5.16-1+b1) over (5.16-1+b1) ...
Setting up systemd (252.38-1~deb12u1) ...
D000002: fork/exec /var/lib/dpkg/info/systemd.postinst ( configure 252.36-1~deb12u1 )

Zitat von chente

Even so, it is useful in many cases.

No doubt about that - I really meant it sounds awesome!

Zitat von chente

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...

What is it supposed to look like?

$ systemctl list-dependencies --all --reverse openmediavault-issue.service
openmediavault-issue.service
● └─getty.target
●   └─multi-user.target
●     └─graphical.target

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.

Zitat von macom

How about the output of

journalctl -u openmediavault-issue

Code

-- Journal begins at Fri 2023-01-13 05:30:36 CET, ends at Sat 2023-03-25 01:39:11 CET. --
-- No entries --

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?

Yea, it worked. I'm not sure whether the systemctl enable was necessary, but I'm confident it didn't hurt anything.

Zitat von macom

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.

Zitat von Zoki

# systemctl enable rrdcached.service

OMG, thanks. In my original post I even recorded that I did try systemctl enable, but I misspelled the service name 🤦‍♂️ Now it's enabled, We'll see if it does the trick!

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:

Mar 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:

$ 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:

$ 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.