Beiträge von mortee

    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:

    The irony is that reinstalling it (or anything, for that matter) doesn't work, since the system reboots at this point:

    Code
    $ 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 )

    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.

    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?

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

    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?

    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:

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


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


    So, what might have gone wrong, and how do I fix it?