Posts by mischka

    There are more options... connect a USB3 LAN adapter and use it only for the pihole container or operate a pihole-lxc only with the USB3 LAN adapter. I haven't done this in OMV yet, but in Proxmox I use a USB3 LAN adapter exclusively for an OMV VM with Jellyfin container. I always had problems with the OMV VM and the virtual LAN. Since using the adapter, that's a thing of the past. Disadvantage: You need a second LAN port or a network switch. Such an adapter is available for less than 10 euros. For pihole, a 100Mbit adapter to USB2 would also be sufficient.

    I don't think I've misconfigured anything. The video hardware acceleration of the Asus N100 did not run under Debian 11 (kernel 6.1.x). You can't "pass it through" or configure it incorrectly. Under the "old" hardware (i5-7500T, J4105, J5040) the video hardware acceleration in the Jellyfin container works perfectly. In the OMV-VM/Jellyfin container under Proxmox on a Fujitsu Esprimo Q558 (I5-8500T), the video hardware acceleration also works perfectly.

    With the iso I linked to, the Asus N100 board only had problems with video hardware acceleration, everything else worked. The network was running at 1GBit. I had installed OMV 6 as a test. Video hardware acceleration probably requires a kernel >= 6.2. With the Proxmox kernel 6.2.x, the video hardware acceleration worked and was passed through to the Jellyfin container, but Jellyfin was no longer reachable/usable. Before OMV 7 I don't do any more experiments with the board. OMV 6 now runs on an Esprimo Q556/2 with i5-7500T (cheap leasing returns via Ebay). The idle power consumption is no greater than that of the Asus board. Of course, things look different under load. But most of the time, OMV runs idling for me.

    The only advantage of a raid (from raid 1) for me is the availability.

    Cons Raid:

    1. Hardware has to be purchased additionally, because you need a backup HD despite the raid.

    2. Additional power is consumed for the raid plates.

    3. In case of virus attack, broken files, etc., all HDs are affected, therefore Raid is not a backup

    Cons without Raid: In the case of defective data HD, the data from the backup must be restored in a time-consuming manner. The NAS is not available at this time.

    The backup HD's must be able to be switched off. Otherwise, in the event of a virus attack, it affects them in the same way as the data HD. In addition to a backup NAS, which is only turned on for the purpose of backup, I use a backup HD. With both, I perform time-delayed backups of the data.

    Agrees... those who can read have a clear advantage. :) Since it doesn't get into the bios and POST isn't shown, it's not an OMV problem, as you've already noticed. The board (Z97E-ITX/ac) has digital video outputs and inputs (DVI-I, HDMI, HDMI-In and DisplayPort), no VGA. What would I do? Check if a small speaker/beeper is installed on the board or reinstall if available, replace cables and treat sockets with contact spray. Maybe try DVI-I to HDMI with a cable. If that doesn't help, make the board "naked", i.e. take out all plug-in cards and remove one if two DDR3 DIMM are installed (GPU of the CPU uses system memory) -> no picture (POST)/BIOS) then plug the single RAM into the other slot -> still no picture, the same game with the second DDR3 DIMM. Still no picture, then I don't know what to do and would reach into my rich spare parts box (RAM, boards, etc.). Attention, one of the two HDMI sockets is an HDMI-in. There's no picture of it either.

    Use a different cable and/or a different video output port (the board shouldn't only have HDMI). I think this is a cable and/or connection problem on the board and/or on the monitor. If the GPU of the board were defective, the bios would report violently at startup (POST) with built-in beepers.

    Maybe this is a help/solution: https://www.vikash.nl/exclude-client-devices-with-pi-hole-5/. You create a group in pihole in which the pi with OMV is in it and this group can bypass pihole. In OMV you enter a DNS (which you have already done). In your router, you need to check the box for the Pi with OMV "to assign the same ip forever". I haven't tried this myself, because I use a Dell Wyse 3040 for pihole/unbound for a good reason.

    A short time ago, this was already an issue:

    As far as I know, the Odroid HC2 has a Samsung Exynos 5422 (Cortex-A15 / Cortex-A7) as SoC and it is only 32 bit capable. The successor HC4 has an Amlogic S905X3 (Cortex-A55) SoC. It is 64Bit capable.

    I assume that the network works (otherwise execute the command omv-firstaid in the terminal/SSH) and OMV fails at DNS resolution. Under OMV/Network/Interfaces, select the network interface, then click on Edit and enter a DNS server under Advanced Settings/DNS Server (Google (1.1.1.1) or any other). I have entered the local Ip4 address of my Fritzbox. This then forwards the DNS request via pihole. And as Somas said, don't use apt-get update and apt-get upgrade. Use the command "omv-upgrade" or update via the OMV web interface.


    Ich gehe davon aus das das Netzwerk funktioniert (ansonsten im Terminal/SSH den Befehl omv-firstaid ausführen) und OMV an der DNS Auflösung scheitert. Unter OMV/Netzwerk/Schnittstellen die Netzwerkschnittstelle auswählen, dann auf Bearbeiten klicken und unter Erweiterte Einstellungen/DNS Server einen DNS Server eintragen (Google (1.1.1.1) oder irgend einen anderen). Ich habe bei mir die lokale Ip4 Adresse meiner Fritzbox eingetragen. Die leitet dann die DNS-Anfrage über pihole weiter. Und wie Somas schon sagte nicht apt-get update und apt-get upgrade verwenden. Verwende den Befehl "omv-upgrade" oder aktualisiere über die Web-Oberfläche von OMV.

    is the shutdown command better than sleep?

    It's hard to say. It depends on the hardware. It is important for me whether it starts again on request via WakeOnLan. My Asrock itx board only boots via WakeOnLan if it has been shut down via autoshutdown. This also works in the event of a short-term power interruption/short-term power failure. After shutdown, WOL requires normal boot from disk. A Brix J3160 from Gigabyte, for example, only starts via WakeOnLan if it has been sent to sleep via autoshutdown. I think that the hibernation mode costs a bit more power and the OMV is available again faster via WOL. The data/system is in RAM. In the event of a short-term power failure, however, the PC will not boot up again in sleep mode via WOL.

    Primary NAS:

    Asrock J5040 itx board

    PicoPSU 120Watt + 12V/50 Watt Power Supply

    8GB RAm (2x4GB DDR4)

    Old airy ITX case

    16 GB Sata SSD (Sandisk U110) for system and Jellyfin containers

    4TB SATA SSD for data (Transcend)

    Backup NAS:

    Dell Wyse 5070 Thin Client with J4105 and 65 Watt Power Supply

    8GB Ram (2x4GB DDR4)

    System + Jellyfin on built-in 16GB eMMC

    4TB Sata m.2 SSD for data (Transcend)

    Dell Wyse only occasionally in operation to back up the primary NAS.

    Primary and backup NAS run fanless.

    This can be reversed. The line Remove "Blacklist R8169" in

    /etc/modprobe.d/blacklist-r8169.conf

    sudo apt purge r8168-dkms

    sudo reboot

    The last thing I would try would be to install the pve kernel. Install OMV > plugin >Openmediavault kernel and then Proxmox kernel 6.2.x install, restart and run omv-firstaid in the terminal, edit the Network.

    Maybe it helps to install the RTL8168 driver and blacklist the RTL8169 driver, see:


    sudo apt-get install r8168-dkms

    echo "blacklist r8169" > /etc/modprobe.d/blacklist-r8169.conf

    sudo reboot


    Step-by-step - Debian Bullseye Realtek RTL8168 Driver Installation • Page 2 of 3 • tutorialforlinux.com
    InstallingGNU/Linux Debian Bullseye Realtek RTL8168 Driver Setup Guide Hi! The Tutorial shows you Step-by-Step How to Install Realtek RTL8168 Wireless Driver…
    tutorialforlinux.com