Beiträge von tmihai20

    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 libnvidia-encode1
    #for Ubuntu
    sudo apt install libnvidia-encode
    #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.

    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.

    I know it is a longshot, but it might be worth looking into what NixOS is about and how it could be used as the base of OMV. I have been using OMV since version 2.x and my overall issue is that whenever I want to be on the latest version I most likely have to start from scratch. It is even a lot more difficult if someone's OMV is 2 versions or more behind. I am using OMV 5.x right now because at the time of my setup (which was about May 15th 2022) OMV 6.x had issues with allowing me to use GPU acceleration in Plex or Jellyfin. I have run similar steps on OMV 6 and on OMV 5, but I was able to get it working only on OMV5 because OMV 6 had a very new version of Debian that did not yet have support for those packages.


    I definitely don't want to start a heated debate, but from what I have seen, Nix is the Swiss Army Knife of all distros and what I like the most about it is the fact that it has the best way of handling dependencies. One can have any version of any package (and they have most important packages) with any dependencies running in an isolated environment if needed. It can even run something on a shell based environment. I can even run anything once when needed and can cleanup those temporary installations. It can get nix config files from a git repo and has snapshots of all the previous versions of the OS. As long as the hardware does not break (SSD, USB stick or HDD is functional without any bad sectors), you can never break your installation.


    On the other hand, NixOS has a steep learning curve and can be intimidating because one can get lost in all the configs and NixOS is a little different than all the other OS-es. The good thing is that once a config is done, you kind of forget about it. Only after a colleague has shown it to me in action I was able to see how good it can be and how well it can work. My first initial impression was that we don't need another OS that appears to complicate things by trying to be good at everything. Please, please give it a fair chance.

    This is something I have been thinking for a long time. I would love to be able to have a better way to upgrade from one release to another. I do know that the latest version of OMV will always be based on the latest version of Debian, but please think of users that are using older versions of OMV and will not update because of the complicated path of the upgrade that may break things.

    I had the same issue after a fresh install. Default shell is dash, I wanted to use bash, so I changed the default shell to bash (/bin/sh now points to /bin/bash). Sorry for the very late reply. I think I have had this issue in the past. You need to keep checking what the default shell is from time to time.