This worked for me on OMV6 for now, installing the headers. Then everything else worked. For some reason my nginx proxy was not running if nvidia was not running (no idea when or how that became dependent on nvidia working but whatever). So I needed to do something quickly.
apt install linux-headers-amd64
Still intend to do OMV7 update over the weekend, does anyone know if you should uninstall nvidia and/or turn off backports before you do it for a smoother ride?
For anyone still on OMV6 having this issue, try installing this before you start the nvidia steps.
apt install linux-headers-amd64
Right on - What data do you recommend I capture in the screenshot, just in case?
So I guess it's time I get on the train . My biggest fear is losing my SNAPRAID/MERGEFS setup and pool.
Anyone running these have any problems and/or success?
Thanks for letting me know. These upgrades always terrify me but I'll have to take the plunge soon I guess.
Just saw this after starting my own thread. Exact same problems here. Hopefully the wizards can come up with a fix. The standard OMV6 guide I have been using a couple of years now no longer works with the latest kernel which is the same one you and I are on.
This was working, with some reading I am seeing every time the kernel updates, it will break. No big deal I can re-install, but this time it's not working.
Following OMV6 guide here:
[HowTo] Nvidia hardware transcoding on OMV 5 in a Plex docker container - Guides - openmediavault
Errors in step: apt install nvidia-driver firmware-misc-nonfree
I have backports off and Kernel 6.1.0-0.deb11-18 running. Could use some help resolving. No other changes to rig other than software updates in OMV6, nvidia drivers were working fine before some recent updates.
Loading new nvidia-current-470.223.02 DKMS files...
Building for 6.1.0-0.deb11.18-amd64
Building initial module for 6.1.0-0.deb11.18-amd64
Error! Bad return status for module build on kernel: 6.1.0-0.deb11.18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/470.223.02/build/make.log for more information.
dpkg: error processing package nvidia-kernel-dkms (--configure):
installed nvidia-kernel-dkms package post-installation script subprocess returned error exit status 10
dpkg: dependency problems prevent configuration of nvidia-driver:
nvidia-driver depends on nvidia-kernel-dkms (= 470.223.02-1) | nvidia-kernel-470.223.02; however:
Package nvidia-kernel-dkms is not configured yet.
Package nvidia-kernel-470.223.02 is not installed.
Package nvidia-kernel-dkms which provides nvidia-kernel-470.223.02 is not configured yet.
dpkg: error processing package nvidia-driver (--configure):
dependency problems - leaving unconfiguredErrors in make.log:
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock'
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock'
make[3]: *** [/usr/src/linux-headers-6.1.0-0.deb11.18-common/scripts/Makefile.modpost:127: /var/lib/dkms/nvidia-current/470.223.02/build/Module.symvers] Error 1
make[2]: *** [/usr/src/linux-headers-6.1.0-0.deb11.18-common/Makefile:1991: modpost] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-0.deb11.18-amd64'
make[1]: *** [Makefile:250: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-0.deb11.18-common'
make: *** [Makefile:80: modules] Error 2Please feel free to merge me in another thread if needed.
OMV6 wants to install a bunch of nvidia package updates today. I recall this breaks any custom installation of nvidia hardware accelerated drivers. Is there a list of packages we need to keep back?
Disregard, I'll explain what I did wrong in case it helps anyone in the future. I replaced the bad drive with a new drive but SnapRaid wanted me to name it exactly the same in the GUI as the drive I yanked. It's happier now. The UUID can be different but the name given in the GUI needs to match the drive you pulled to make it happy. Learning experience.
Hi all,
Snapraid dummy here. Had a drive go bad and instead of just replacing it I relocated my files to remaining drives had plenty of space. Now snapraid is missing that drive and doesn't run even though I removed it from the GUI. It wants a fresh drive and to rebuild that drive that was pulled.
At this point I am OK with starting over and using this as a learning lesson that a pulled drive must always be replaced and rebuilt. Unless there is a simple step I am missing.
If I wanted to start over, would I just delete the parity drive and/or the whole plugin and reinstall?
All right appreciate the advice. I guess it was just bad luck that the newest drive I added happened to be the one that failed. I was using it pretty much exclusively since it was getting all the new media and the old drives were sitting there basically unused. But I guess that’s just how it will work from now on considering how things work and were set up. Unless we start watching a lot of old media, the newest drive in the pool will always going to get hammered the most.
Thanks guys. I’m actually not looking to rebuild any drives. I didn’t lose any data, I just rsynced all the content from the failing disk to the mergerFS pool
Before I removed the then empty drive. I plan to run a snapraid sync after I pull the bad drive (not replacing it at all).
When I later DO add new empty drives, what is the proper procedure to balance mergerFS to populate the new drives with content so they are not the only ones getting slammed with new media? I think that’s what killed this drive. My other drives are all almost full so they weren’t being used at all and all the new media that I was adding was all landing on one drive. I’d much rather that spread out across all my drives. Old media rarely gets accessed so those drives just sit idle. Balancing data usage equally across all my drives would help that I think.
The big issue with drives and space for me has been 2160p content is getting bigger and I'm still a little too scared to convert everything down to x265. Some remux rips I have are huuuuuge.
Recovery going well by the way. Since I had enough space without the bad drive in the pool, I decided to remove the bad drive from mergerfs and then use rsync to sync the content to the mergerfs pool. Did not touch snapraid but I'll run a rebuild when it's done.
When I do add a new drive or drives to replace the bad one, I think I need to run a mergerfs balance or something and then rebuild my snapraid. Mergerfs was trying to fill the empty disk and slamming it with new content, since all my other drives were around 80% full and it was 0% full. My guess it that when you add an empty drive you should tell mergerfs to balance the pool so that drive quickly gets as full as the others already there, so you are continuing to use your volumes equally as new content is added. This one drive was doing all the work.
Turns Out I have a failing drive in my pool which may be the cause. But if it’s still slow after that I’ll look at my cpu next. I was hoping there may be a hidden Plex configuration or one to set in a cfg file to increase the playback buffer.
I appreciate all the great info here. It sounds like there are two schools of thought, one being to use snapraid itself to rebuild the drive (treat is as failed and remove it and replace with an empty new drive.
Since I don’t have a new drive yet and I’m waiting for a sale, but still have enough space left overall in my mergerFS pool I probably need to use the other method which is the rsync. I just need to make sure I run the right command and I’m not great at rsync and used to just use cp out of fear.
The drive that appears to be on its way to failure is a 15TB western digital drive.
Jumping into the thread as I want to do this too to be able to yank a failing drive from my mergerfs snapraid pool.
Here's what I am thinking the steps are (and I am wondering why I can't just Wetty in and run the rsync command?)
1. Disable snapraid in OMV GUI
2. Set up a share for the UUID of the drive I am about to remove from the mergerFS pool in the gui
3. Remove the failing drive from the mergerFS pool using the GUI
4. Root into Wetty
5. Run a special rsync command with the correct flags (little lost here)
rsync /SHAREDRIVE /MERGERFSPOOL
But probably with a bunch of flags etc
6. After rsync completes, delete the SHARE and UNMOUNT the failing volume/disk
7. Yank the failing drive from my server physically.
8. Re-enable Snapraid
Did I cover this pretty well? I think I just need the rsync command and the rest will be pretty easy.
I'm a little scared of data loss, I have plenty of free space to cover the removal of the drive (it's a 15 TB drive and the mergedFS volume overall shows 20TB of free space).
I assume the first step may be to remove the drive from MergerFS (which I hope then will move all its content to the other available drives as part of that removal?) then remove it from SNAPraid?
Is there a process documented somewhere? I am sure there is, just have not found anything concrete and I want to make sure I am careful and doing this right, especially since I do not have a new drive to swap in for the failing one just yet. But I want to get that failing drive (SMART reports it as WARN status) as soon as possible.
TIA!
I am hoping there's a setting somewhere I can adjust to fix this.
Lately, I've noticed that my mergerfs snapraid setup (one pool) is causing Plex playback to fail when a background service like copying/moving a file (such as a new media download) takes place. It's a minor inconvenience like a couple minutes of freezing/buffering issues but enough to be annoying.
Just wanted to make sure there wasn't a setting somewhere I could check or adjust to try and mitigate things? It seems pretty apparent that my storage gets hammered when moving a file around so if I can't avoid that, maybe a way to increase the plex buffer to handle it vs. the automatic setting?
I run all the latest OMV6 kernel and Linux 6.1.0-0.deb11.6-amd64 seems to be working for me however it's gone bad on me twice and I am not sure why it went bad the second time (the first time I let OMV update all the nvidia stuff to newer packages and that borked it good).
It might not be a bad idea to add extra steps to tell OMV to not ever update certain packages/components. Since we are using older nvidia drivers on OMV6, OMV6 seems to want to update those packages. I thought I was able to run a block updates on them but something went wrong and my plex eventually stopped working until I stopped running the nvidia env version. Once I ran through all the steps again, it's back, just not sure for how long.
Major kudos for the guide in the other thread, big fan of it and how it takes everything one step at a time with exactly what is needed and an explanation. The world needs more guides like this.
Thanks that’s what it was. I just started over with nvidia drivers. Definitely don’t let omv update what it wants. I assume it’s like the post says and since the nvidia v6 drivers aren’t compatible you can’t let omv update the v5 you installed.