Posts by tmihai20

    I had posted initially in another thread, but I had a very similar issue (3 HDDs were exhibiting issues that could be seen in dmesg). The errors I was seeing were like below. Out of the 3, only 2 are actually used and I had issues with the shares coming from the 2 HDDs with problems.



    My issue was caused by a SATA power extension cable that the 3 HDDs were connected to. I am using a big case and the cables from the power supply are not long enough to reach all HDDs. My solution came from another forum where someone has posted the fix, fortunately. This may help other people. The only funny thing is that my NAS may have had the issue for a long time, but a kernel update actually revealed it. The same thing happened to the poster in the other forum (issue was visible after a kernel update).

    Oh wow, this thread is being revived after 7 years. The browser interface is not the best, even when it is designed to be responsive. There is no application on Android that can connect to OMV and change anything like in the web interface. I, for one, am not interested in using the browser. I was using an app that is not even in Play Store anymore (it looks like I still have it because of cloud backups). That app had a few generic widgets like drive status. There are some generic apps today, but I don't want to see running stats, I want to be able to easily modify OMV specific stuff. Whenever I want to do this, I just go to my desktop/laptop and type away. Most of the time I have to do very small stuff like add a new share or an user.

    EDIT: Question:

    In folder /etc/ a few files of extension *.distrib.dpkg-dist were left there, are they to be removed-deleted? Examples are:

    I think those are there because the update process was instructed to save the old files. Whenever a conf file is updated, you should be normally asked about what you want to do. My machine does not have any of those files, but I updated from an older 6.x to an older 7.x.

    Oh wow, someone still using XU4. Have you tried running the fix script?

    Code
    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/fix6to7upgrade | sudo bash

    I would also post in THIS thread. It is a more general one where people that had issues have been posting.

    The script isn't meant to do the upgrade. It is meant to fix broken upgrades from the omv-release-upgrade command. So, there should be no choice. Always run omv-release-upgrade first.

    Fortunately for me everything went well and everything is working well. It is good to know people should use "sudo omv-release-upgrade", then the script if needed.

    First of all, welcome to OpenMediaVault forums and I honestly commend you for asking. OMV is not meant to be used by a certain category of people. Its design makes it useful for complicated setups and for simple setups. I think you will find OMV to be quite fun to use. You can do everything on the web interface or you can use it as a Linux machine with SSH and so on. The only time you have to use the terminal would be when upgrading to a newer version (there are always guides and scripts to upgrade from version n to version n+1 - this is actually the recommended way to upgrade, to not skip versions).


    I started using OMV on an oDroid XU4, graduated to another oDroid H2+ (x86 platform) and now I am using an older desktop. Plex works pretty well, but I have moved away from it and I am using JellyFin.

    Fortunately I found the answer. The issue that I was seeing was due to one package that I was installing to get Nvidia hardware acceleration for JellyFin and other tools. I switched to the non-Proxmox kernel, I removed the Proxmox kernel, I rebooted the server, I reinstalled the Proxmox kernel and I saw a message that package firmware-misc-nonfree will be removed. The Nvidia kernel modules were compiled successfully and everything is back to normal now. I rebooted my server one more time and now functionality is back again.

    I am usually updating packages from time to time and today I ran into an issue with the current Proxmox kernel 6.2.16-11-bpo11-pve. It seems there are no kernel headers available for it, so nvidia modules are not compiling for this kernel


    Code
    sudo apt install linux-headers-6.2.16-11-bpo11-pve
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    E: Unable to locate package linux-headers-6.2.16-11-bpo11-pve
    E: Couldn't find any package by glob 'linux-headers-6.2.16-11-bpo11-pve'

    I don't know what kernel I was using before. I think backports are enabled. Could the kernel headers come from some other repo that is not enabled right now? Should backports be enabled or not? What could happen if backports are enabled?

    I did not search on Reddit. I lost a lot of time with this issue and for now it seems to not manifest itself anymore. I rebooted with the Proxmox kernel and I cannot see any issues now.

    I noticed a strange issue that I initially blamed it on a few power outages. I am using the latest available OMV 6 with the latest Proxmox kernel 6.2.16-11-bpo11-pve. The HDD in question is new, it was purchased last year with another one. I know that the issues shown in dmesg should mean that the HDD turned bad and today I booted into GParted Live and Seatools Bootable to check all HDDs. None of the tools are showing any errors with the HDD in question, I let it run the Short Generic Test. SMART information is clean and I cannot see any dmesg errors in GParted Live, Seatools Bootable or Ubuntu 22.04 Live. I even tried changing the SATA port. I don't know when the issue appeared, but I noticed sometime at the end of last year that my snapraid sync and scrub jobs were hung for a long time and that the snapraid.content on the affected drive is different than the ones on the other content drives.


    Could this be related to the installation or the kernel? I have not tried booting into the mainline OMV kernel or any other older kernels. I also realized I didn't change the SATA cable with a new one to rule out a bad cable. What puzzles me the most is that booting into anything else but OMV shows no error on the affected drive. One strange behavior of the affected drive is that it appeared as not mounted at some point - mountpoint was completely empty. All data on it was visible after a reboot - that scared me the most and then I started doing some basic checks that led me to running Seatools Bootable and checking it in a Live CD environment. I can read and write on it now without any issues. I fear that if I were to send it for warranty I would just get it back as functional.


    I am pasting the dmesg logs below.



    Edit: I just booted with the non Proxmox kernel 6.1.0-0.deb11.13-amd64 and I cannot see any issue with any disks. I ran snapraid and I also copied a large file to the affected disk for testing. I need to be able to use OpenCL, that is why I want to use Proxmox kernel.

    Check for dead/sleeping processes. There was a power cut recently and I noticed sounds coming from my NAS. I did not pay attention to it for a few days, then I investigated. I found out that the snapraid sync job was running for a few days already (it should just sync new files and there were not that many). Any snapraid operation finished with errors about snapraid content. All my data drives had errors at filesystem level and I had to fsck all of them. I deleted the wrong snapraid content tmp files and now setup seems to be ok.


    What I am suggesting is to check your data drives first and see if there are any errors on them (you need to do it from a live distro on USB). What is that nightly service doing? Why do you need it to be running nightly? I am doing scrub and sync once a week.

    I apologize for reviving an old thread, but I am trying to achieve the same hardware decoding for JellyFin using a GTX 1060, but with OMV 6. Were you able to do this using the nouveau drivers?


    Edit: To answer my own question, I found the needed steps. I am pasting them below. They are working on the proxmox kernel (version 6.2 at the time of the post). Installing nvidia-driver also blacklisted nouveau driver. I also wanted to have OpenCL also available. nvidia-smi and clinfo are both reporting working capabilities.


    To get hardware acceleration in JellyFin I also had to install libnvidia-encode1 (as I found HERE). It appears to be needed on Debian, for Ubuntu it is libnvidia-encode.


    Code
    #for Debian
    sudo apt install libnvcuvid1 libnvidia-encode1
    #to test capabilities
    /usr/lib/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device cuda=cu:0 -hwaccel cuda -hwaccel_output_format cuda -i /path/to/the/media -an -sn -vframes 1 -f null -


    PS: Starting with Proxmox kernel 6.2.16-20-bpo11-pve, package firmware-misc-nonfree should not be installed anymore. I was getting errors with nvidia kernels dkms build and I did not know why. Even after following my own advice I could not get it to work. I switched back to the non-Proxmox kernel, I removed the Proxmox kernel, I rebooted my server,I reinstalled the Proxmox kernel and then I rebooted my server one more time. During the installation of the current Proxmox kernel I saw a message about the firmware-misc-nonfree package that it will be removed.


    PPS: I updated to OMV7 and I followed my own previous guide, with minor changes. The official JellyFin Hardware Acceleration page should be consulted before installing anything, as well as the Debian official support page for Nvidia cards. Repos and packages are slightly different, nvidia-opencl-icd package is not mentioned anymore.


    PPPS: Backports should also be disabled.

    I postponed the upgrade as much as I could. I was very pleasantly surprised to see that the upgrade went quite smooth, with one exception. After the upgrade I was not able to login on the web interface (it was showing the login box) and after a bit of searching I realized that the openmediavault-engined service was masked. Everything was working well except the web interface. I must say I expected a lot more issues with the upgrade. It makes me think that the upgrade to OMV 7 would be easy as well.


    PS: even though there were probably no issues, I ran the script that fixes problems with OMV Extras plugins just to be sure. I like the new interface more than the old one, especially because it is a lot more mobile friendly.

    I started with an oDroid XU4 (similar platform as a RPi 3) and an external HDD. It served me well enough until I ran out of space on it. I moved to a NUC like device oDroid H2 (Intel Quad-core processor J4115) with 2 native SATA ports and one M.2 port. It also served me quite well for 2 years until I wanted to add more HDDs (I was already using a SATA splitter that was ok most of the times). I upgraded my desktop to an 12900K and I repurposed my old desktop with i7 Extreme 5820K and lots of SATA ports to be my NAS. It doubled my power consumption, but I was expecting it to be more than that. Basically I have quite a powerful NAS at zero cost to me. I tried searching for a good mini ITX board with a decent CPU, but I had to sell my existing mobo+CPU and even pay extra to get a mini ITX with less power, just for the form factor. I preferred to keep my possible hungry setup and use it (it was pretty stable for all these years).


    My 2 euro cents is to get whatever is cheaper. Ask around if anybody has old hardware that they are not using and use that, if you want to build a NAS now. Look for used hardware locally on your preferred sites like eBay or OLX. Think ahead about how it would be used so you don't have to buy a new build because your use cases have changed.

    I just upgraded my OMV from 5 to 6 and it went extremely smooth. I did have error 500 after install, although everything seemed to be good. For some unknown reason openmediavault-engined service was masked after rebooting a few times and after the upgrade finished successfully. There were a lot of messages during the upgrade, some errors, but there were no apparent errors about openmediavault-engined. I got the idea to check for this service from another post here in the forums. All I did was to unmask the systemd service.


    Code
    sudo systemctl unmask openmediavault-engined

    I am using a 1060 3GB for GPU acceleration and packages support for that very new Debian version was not there at the time of my install.


    A moderator can lock this thread, it has served its purpose. There is no need to divert it from its actual intended purpose.

    There is a thread for people doing gpu acceleration on OMV 6. You do not need to stay on OMV 5 and gpu acceleration is definitely not a reason to switch distros. Upgrades aren't that bad and if someone lets their server fall two versions behind, that is their fault. But they can still upgrade one version at a time to be on latest.

    I had clear instructions back then and they did not work on the state that the underlying Debian distro had back then with OMV 6.x. There were issues with the Debian packages. I had a clean installation, I think I did it twice because I kind of broke the OS once while trying to get it to work. I preferred to use the older version instead of having to either wait or troubleshoot a fairly new Debian install to get things working. It was a calculated choice, knowing that I will most likely have to reinstall everything if I ever want to move to OMV 7.x.


    Upgrades have always been an issue for OMV, I have read a lot of posts here about them. Maybe some lack the knowledge or the patience to do everything as described. Maybe some depend on plugins that are no longer supported in the newest version of OMV.


    I have played with NixOS for non-OMV reasons and it is not stable enough to be a NAS

    One could not necessarily be on the latest and greatest version of NixOS. NixOS is a double edged sword, it is its advantage and its weak point at the same time.


    Switching to that OS would mean that OMV is needed to build images for ARM devices as well

    I had to ask and I know that on ARM devices OMV can be installed on a compatible distro. ARM is well supported on NixOS and one does not really need to use the provided images to use NixOS.




    Thank you all for taking the time to reply. I knew the idea would get a NO from Volker, but I still had to ask, since there were no discussions about it. If I were in the developer's shoes this far in the project, I would also reply with NO to such an idea.