Beiträge von cwlucas41

  • Upgraded CPU, load average monitoring parameters not updated

    I recently updated the CPU on my Precision Tower 5810 from a Xeon E5-1603 v3 (4 cores, no HT) to a E5-2690 v4 (14 cores + HT). It's amazing what you can get for $25 on ebay.


    The upgrade went great and it solved a performance issue I was having. Before upgrading, I was occasionally receiving loadavg (1min) > 8 and loadavg (5min) > 4 monitoring alerts.


    However, after upgrading I still occasionally receive loadavg monitoring alerts. The puzzling part is that the alert thresholds are still loadavg (1min) > 8 and loadavg (5min) > 4 while I would expect them to be loadavg (1min) > 56 and loadavg (5min) > 28 due to /proc/cpuinfo showing 28 processor units.


    The monitoring code (link) is:

    Code
        if loadavg (1min) > {{ grains['num_cpus'] * loadavg_1min_mult | float(1.0) | round(1) }} for {{ loadavg_1min_cycles }} cycles then alert
    if loadavg (5min) > {{ grains['num_cpus'] * loadavg_5min_mult | float(1.0) | round(1) }} for {{ loadavg_5min_cycles }} cycles then alert


    I suspect what is happening is that grains['num_cpus'] is cached.


    I was wondering if I can invoke this code (link) to update the grains info, but I could not find a way to execute it after reading the developer section of the website and searching on the forum.

    Code
    refresh_grains:
  module.run:
    - saltutil.refresh_grains:
      - refresh_pillar: True


    This obviously isn't critical, but my understanding of the code is that the stale 'num_cpus' info is causing false positive monitoring alerts for me.


    Any advise on how to correct this appreciated!

  • Issue with NUT on fresh OMV 7.x install - "Service nut-driver-enumerator has been enabled, and is dead"

    I think I have something here:


    This is the output of root@omv:~# systemctl status nut-driver* -a after a reboot


    I think this is showing me that the nut-driver-enumerator.service started and exited successfully leaving the service in the dead state.


    If I restart the service with systemctl restart nut-driver-enumerator.service, then the following lines are added to the above output.



    Again, it is showing that nut-driver-enumerator.path stays running, but nut-driver-enumerator.service exits successfully quickly after starting.


    ---


    This is problematic because the deployment code tries to ensure the service is running, sees that it is dead, and causes the deployment to fail.


    I don't know what the right thing to do here is, but it does seem to be related to 7.x because of https://github.com/openmediava…effc81cb002d3336ed312057a


    The "Iterating with a systemd deployment" section of the NUT installation instructions indicate that nut-driver-enumerator.service should be started, but I think the problem is that the salt deployment is expecting the service to be long-lived and remain active.


    The manual mentions that "[service] naming did change from 2.7.4 and older releases, through 2.8.0". As far as I can tell, bullseye used 2.7.4 and bookwork uses 2.8.0. So, ultimately, I think this is an problem related to how OMV interacts NUT 2.8.0.


    ---


    I suspect that the plugin salt state file needs to be modified. However, I don't know enough about salt or NUT to know for sure if I have found the root cause or how to better assert that the nut-driver services are in the correct state.

  • Issue with NUT on fresh OMV 7.x install - "Service nut-driver-enumerator has been enabled, and is dead"

    Also, I just tried again to enable the UPS standalone service to see if the issue resolved itself. I largely the same error as before.


    It seems the failing part is:

  • Issue with NUT on fresh OMV 7.x install - "Service nut-driver-enumerator has been enabled, and is dead"

    Code
    root@omv:~# sudo lsusb
Bus 004 Device 002: ID 8087:8002 Intel Corp. 8 channel internal hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:800a Intel Corp. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0bc2:ab21 Seagate RSS LLC Backup Plus Slim
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Code
    root@omv:~# sudo lsusb | grep American
Bus 001 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
    Code
    root@omv:~# sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 5: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
    |__ Port 11: Dev 3, If 0, Class=Human Interface Device, Driver=usbfs, 12M
    Code
    root@omv:~# sudo lsusb -v | grep "American"
Bus 001 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
  idVendor           0x051d American Power Conversion
  iManufacturer           1 American Power Conversion

  • Issue with NUT on fresh OMV 7.x install - "Service nut-driver-enumerator has been enabled, and is dead"

    Zitat von votdev

    What is the output of systemctl status nut.target and systemctl status nut-driver.target and systemctl cat nut-driver-enumerator.service

    Code
    root@omv:~# systemctl status nut.target | cat
● nut.target - Network UPS Tools - target for power device drivers, data server and monitoring client (if enabled) on this system
     Loaded: loaded (/lib/systemd/system/nut.target; enabled; preset: enabled)
     Active: active since Tue 2024-01-02 07:54:21 EST; 1 day 5h ago

Jan 02 07:54:21 omv systemd[1]: Reached target nut.target - Network UPS Tools - target for power device drivers, data server and monitoring client (if enabled) on this system.
    Code
    root@omv:~# systemctl status nut-driver.target | cat
● nut-driver.target - Network UPS Tools - target for power device drivers on this system
     Loaded: loaded (/lib/systemd/system/nut-driver.target; enabled; preset: enabled)
     Active: active since Tue 2024-01-02 07:54:21 EST; 1 day 5h ago

Jan 02 07:54:21 omv systemd[1]: Reached target nut-driver.target - Network UPS Tools - target for power device drivers on this system.

  • Issue with NUT on fresh OMV 7.x install - "Service nut-driver-enumerator has been enabled, and is dead"

    Soma - yes it is connected to the data port with the provided USB cable. I'm trying to enable it in Standalone mode, and the driver configuration in the UI matches exactly the /etc/nut/ups.conf file I provided above. It is using the usbhid-ups driver.


    The same UPS worked for me running OMV 6.x on a Raspberry Pi 4. It did not require any configuration on my part as I installed the UPS plugin, enabled it, and everything worked. It also used the usbhid-ups driver.


    When I set up my new machine on OMV 7.x is when I hit this problem.

  • openmediavault-nut - shutdown the server, but keep the UPS running

    Zitat von kamild1996

    I also have my router connected to the UPS. Since I seldom need to have the server up and running on battery, my idea is to have the server gracefully shutdown after 60 seconds and let the router run for much longer than it would have ran if the server was still on. Once the power is back on for good but UPS battery hasn't been drained, I'd use Wake-on-LAN to boot the server back up.


    My use case is very similar to this. I'm now thinking about having a pi monitor the UPS (Type C configuration from typical setup documentation) and orchestrate power on/off events for my OMV server (in a Type B configuration).


    Since I'm having trouble with the NUT plugin in OMV 7.x (thread on issue) anyway, maybe I'll try something like this.

  • OMV6 Boot Device Note Found after Clean Install

    For anyone else who stumbles upon this in the future, I had a similar issue and this is how I resolved it.


    I was trying to install OMV on a Dell Precision 5810 and the machine would not boot to the grub menu using either legacy or UEFI boot options (with SecureBoot disabled). However, I could boot the OMV installer from USB drive and I could also boot Ubuntu Server after an install and also proxmox. I was unable to boot either OMV or debian netinst after installing either.


    The information above helped!


    I learned that in the UEFI boot menu, the Dell machine seemingly always looks for /EFI/BOOT/bootx64.efi. Even when I manually created a boot target and entered /EFI/debian/grubx64.efi, it would be reset to bootx64.efi after a reboot.


    I found the easiest way to solve this was the following steps:

    1. Use a tool like super grub 2 to boot OMV by booting super grub 2 from USB and then choosing the "debian" grub entry.
    2. Once OMV is booted, run dpkg-reconfigure grub-efi-amd64 as root and choose "Yes" when prompted with
    Zitat

    Some EFI-based systems are buggy and do not handle new bootloaders correctly. If you force an extra installation of GRUB to the EFI removable media path, this should ensure that this system will boot Debian correctly despite such a problem. However, it may remove the ability to boot any other operating systems that also depend on this path. If so, you will need to make sure that GRUB is configured successfully to be able to boot any other OS installations correctly.


    Force extra installation to the EFI removable media path?


    After this completes, reboot the machine and it should boot up into OMV without needing a USB boot first. I like the "super grub 2" solution here because it is a mechanism to boot OMV directly and fix the problem without manually changing things.


    More detail is available in the Debian UEFI wiki.


    ---


    It seems that Debian does not perform installation of the removable media path by default (and OMV inherits this). Other distros like Ubuntu do set it up by default which is why I was able to boot Ubuntu after installation but not Debian or OMV.


    Sorry for spamming an old thread, but I lost a good few hours to this problem and I want to expand on the answer that helped me so that others don't do the same.