Posts by m4tt0

As OMV7 has just been released, I suppose many users are wondering whether to upgrade, now, later or not at all. I certainly did.

Obviously, forums typically underrepresent those having no issues compared to those, who experience issues and are looking for help.

I'm posting to counter that picture: I just upgraded from 6 -> 7 and had absolutely no issues whatsoever.

I came from OMV4 -> 5 -> 6 -> 7. This was by far the smoothest upgrade experience I've ever had!

A big, big THANK YOU, votdev and ryecoaaron. Great job, indeed!

Just circling back after upgrading to OMV7:

With OMV7 kernel Linux 6.1.0-18-amd64 the issue is gone. My Digital Devices card runs without problems again.

Thanks for the hint, Carsten12 . I just tried it, but it didn't help. The build script pulls the git version and succeeds. The ddbridge driver throws a "No LNBH25 found!" error in dmesg when booting though.

There has been an exchange on the debian mailinglist on this issue. Here the link:

Bug#1051613: linux-image-6.1.0-12-amd64: 6.1.0-12 breaks loading DVB ddbridge module and others

According to that thread, there was a bug in debian 6.1.0-12, which was supposed to be fixed in 6.1.0-13 unsigned. I don't know why I still encounter it with the -13 kernel in OMV6. No big deal for now, as I simply reverted to the -11 one. I just hope it will be properly patched in the next kernel iteration, whenever it arrives.

Just confirming that it is a kernel issue as the drivers load correctly when booting the old kernel Linux 6.1.0-0.deb11.11-amd64...

Dear All,

I've just updated my OMV installation and realized that my dvb devices are lost. I've been using a Digital Devices Cine S2 for many years.

I tried to reinstall the linux drivers (which sometimes helped in the past), but it didn't fix the problems now.

From the boot log I get the following errors:

2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: Port 3: Link 0, Link Port 3 (TAB 4): DUAL DVB-S2
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: 0 netstream channels
2024-01-23T14:43:25+0100 myrs kernel: dvbdev: DVB: registering new adapter (DDBridge)
2024-01-23T14:43:25+0100 myrs kernel: dvbdev: DVB: registering new adapter (DDBridge)
2024-01-23T14:43:25+0100 myrs kernel: dvbdev: DVB: registering new adapter (DDBridge)
2024-01-23T14:43:25+0100 myrs kernel: dvbdev: DVB: registering new adapter (DDBridge)
2024-01-23T14:43:25+0100 myrs kernel: dvbdev: DVB: registering new adapter (DDBridge)
2024-01-23T14:43:25+0100 myrs kernel: dvbdev: DVB: registering new adapter (DDBridge)
2024-01-23T14:43:25+0100 myrs kernel: intel_rapl_common: Found RAPL domain package
2024-01-23T14:43:25+0100 myrs kernel: intel_rapl_common: Found RAPL domain core
2024-01-23T14:43:25+0100 myrs kernel: intel_rapl_common: Found RAPL domain uncore
2024-01-23T14:43:25+0100 myrs kernel: failing symbol_get of non-GPLONLY symbol lnbh25_attach.
2024-01-23T14:43:25+0100 myrs kernel: DVB: Unable to find symbol lnbh25_attach()
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: No LNBH25 found!
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: port_attach on port 0 failed
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: fail3
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: fail2
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: fail1
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: fail0
2024-01-23T14:43:25+0100 myrs kernel: ddbridge 0000:09:00.0: fail
2024-01-23T14:43:25+0100 myrs kernel: ddbridge: probe of 0000:09:00.0 failed with error -1

A quick google search indicated that this is likely a kernel issue and not directly related to OMV itself.

I'm running Linux myrs 6.1.0-0.deb11.13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1~bpo11+1 (2023-10-08) x86_64 GNU/Linux

Has anybody else encountered this? And could you let me know how to best fix this?

Thanks ryecoaaron. Rebooted and it's gone. Closing as "solved".

Cheers, ryecoaaron. I've executed the commands. The reboot will need to wait until my family stops watching telly...

Btw, the level of responsiveness and support you have been and are providing to me and others on this forum, regularly, is beyond belief. Just as all the work you are putting in advancing the OMV infrastructure. I've been using OMV for many years, it is the backbone of my home IT system, it has been getting more and more intuitive over the years, and, yes, I LIKE the new compose plugin as well!

Cheers, mate, for everything you do for us! I do appreciate it, a whole LOT!!!

I'm in the final stages of reconfiguring all kind of storage on my OMV server. Amongst others, I have removed an old mergerfs ("MyFarm"), which I don't need anymore. I've also resolved an old Raid5 configuration and moved it to a new mergerfs ("DATA") + snapraid configuration. Everything works without problems.

I've just found a relic of the old "MyFarm" mergerfs, which IMHO should not be there anymore, i.e. my /srv directory contains an "old" mountpoint /srv/38e633b3-.... I remember it stemming from the old "MyFarm" pool. Indeed, there neither is an entry related to it in /etc/fstab, nor in /etc/openmediavault/config.xml. I've researched where the mountpoint is coming from and found it stemming from "systemd".

I've greped for the identfier in the /etc/systemd directory and found the following:

system/multi-user.target.wants/srv-38e633b3\x2d0da4\x2d40fa\x2d96a2\x2d8680e8063df3.mount:What = MyFarm:38e633b3-0da4-40fa-96a2-8680e8063df3
system/multi-user.target.wants/srv-38e633b3\x2d0da4\x2d40fa\x2d96a2\x2d8680e8063df3.mount:Where = /srv/38e633b3-0da4-40fa-96a2-8680e8063df3
system/multi-user.target.wants/srv-38e633b3\x2d0da4\x2d40fa\x2d96a2\x2d8680e8063df3.mount:Options = branches=/srv/dev-disk-by-uuid-095b0e6e-9bfe-4f4
0-853d-7d25281843ad:/srv/dev-disk-by-uuid-8c6c217f-6d5d-41b2-a0d1-0fb81d2d6631:/srv/dev-disk-by-uuid-1c04fa35-5995-4b24-ae4b-eae60638f88b:/srv/dev-d
isk-by-uuid-ce4d699d-7aba-473e-8807-47e5a1a557eb,category.create=epmfs,minfreespace=4G,fsname=MyFarm:38e633b3-0da4-40fa-96a2-8680e8063df3,defaults,a
llow_other,cache.files=off,use_ino
system/srv-38e633b3\x2d0da4\x2d40fa\x2d96a2\x2d8680e8063df3.mount:What = MyFarm:38e633b3-0da4-40fa-96a2-8680e8063df3
system/srv-38e633b3\x2d0da4\x2d40fa\x2d96a2\x2d8680e8063df3.mount:Where = /srv/38e633b3-0da4-40fa-96a2-8680e8063df3
system/srv-38e633b3\x2d0da4\x2d40fa\x2d96a2\x2d8680e8063df3.mount:Options = branches=/srv/dev-disk-by-uuid-095b0e6e-9bfe-4f40-853d-7d25281843ad:/srv
/dev-disk-by-uuid-8c6c217f-6d5d-41b2-a0d1-0fb81d2d6631:/srv/dev-disk-by-uuid-1c04fa35-5995-4b24-ae4b-eae60638f88b:/srv/dev-disk-by-uuid-ce4d699d-7ab
a-473e-8807-47e5a1a557eb,category.create=epmfs,minfreespace=4G,fsname=MyFarm:38e633b3-0da4-40fa-96a2-8680e8063df3,defaults,allow_other,cache.files=o
ff,use_ino

I'm not that familiar with systemd, but it seems to me that this relic mountpoint is created there. Could you let me know how I can rid of it? I think it should be removed from the configuration...

Yep, did that already. Twice. It was enabled initially, but the devices did not appear in the scheduled task. I then disabled it and renabled it again for both drives under devices, but it did not make a difference: The device was still not selectable when I tried to schedule a task for it...

Thanks, chente. W.r.t. the NVMe you could well be right: I've bought a very recent Samsung SSD 990 Pro. It seems there have been some firmware issues with it. I'll try to upgrade the firmware in the next couple of days. W.r.t. the USB drive, I'd be surprised. It's an 18TB WDC WD180EDF. I bought it about 2 years ago. The other USB I'm using is its predecessor, a 12TB WDC WD120EDAZ which runs without problems. Same vendor at least. Anyways, I'll look into it. Thanks again, mate!

My server currently contains 12 different drives, 2 NVMe SSDs, 8 internal HDDs and 2 external USB drives. I've recently replaced an old SSD with a newer one. I use SMART to monitor all of my drives. When I go to SMART -> Devices, SMART monitoring is enabled on all devices, including the new SSD and both of my external USB HDDs. However, when I go to SMART -> Scheduled tasks, the new NVME SSD and one of the two external USB HDDs are not listed. When I want to create a scheduled task for the missing ones, I cannot pick the two missing devices in the device drop-down list. I don't know why.

I've tried to disable monitoring for the two affected devices in the SMART -> Devices section and reenable it. I get random "504 - Gateway Time-out" errors (without further details), the page reloads, device monitoring seems re-enabled. However, I can still not create a scheduled task for the device in question. I've tried the same approach for the other drive. Same result. Running smartctl via CLI succeeds for both devices so obtaining the SMART states by itself should not be the problem.

Any idea what's going on here and/or I could debug further? Any advice appreciated...

I've done what you suggested and corrected the permissions of the docker folder (from 755 to 710) on the way. Everything worked without issues, including the restart of the docker environment. I was able to check that the metadata.db in the docker/volumes folder exists. journalctl -u docker did not expose any further errors. It seems it works now...

Cheers, ryecoaaron!!! Many thanks for your help!

You have contributed so much to the OMV code, that my machine basically is your machine...

I'll definitely try that! Could you just do me one more favor? Could you let me know what permissions the docker directory should have before I install it again?

The output of journalctl -u docker is attached as text file (had to zip it again).

Otherwise...

root@myrs:~# cat /etc/docker/daemon.json
{
  "data-root": "/srv/dev-disk-by-uuid-5c8e8fc1-94ee-431e-b45e-7939d6339072/docker"
}
root@myrs:~# ls -al $(docker info | grep "Docker Root Dir" | awk '{ print $4 }')
total 60
drwx--s--- 12 root users  4096 Jun 24 21:03 .
drwxr-xr-x  6 root root   4096 Jun 24 21:23 ..
drwx--x--x  4 root root   4096 Jun 24 14:27 buildkit
drwx--x--- 13 root root   4096 Jun 24 14:59 containers
-rw-------  1 root root     36 Jun 24 14:27 engine-id
drwx------  3 root root   4096 Jun 24 14:27 image
drwxr-x---  3 root root   4096 Jun 24 14:27 network
drwx--x--- 98 root root  12288 Jun 24 21:03 overlay2
drwx------  4 root root   4096 Jun 24 14:27 plugins
drwx------  2 root root   4096 Jun 24 21:03 runtimes
drwx------  2 root root   4096 Jun 24 14:27 swarm
drwx------  2 root root   4096 Jun 24 21:03 tmp
drwx-----x  2 root root   4096 Jun 24 21:03 volumes

Cheers ryecoaaron! Here you go...

Output of dpkg -l | grep -E "openmedia|docker":

ii docker-buildx-plugin 0.10.5-1~debian.11~bullseye amd64 Docker Buildx cli plugin.
ii docker-ce 5:24.0.2-1~debian.11~bullseye amd64 Docker: the open-source application container engine
ii docker-ce-cli 5:24.0.2-1~debian.11~bullseye amd64 Docker CLI: the open-source application container engine
ii docker-compose-plugin 2.18.1-1~debian.11~bullseye amd64 Docker Compose (V2) plugin for the Docker CLI.
ii openmediavault 6.4.5-1 all openmediavault - The open network attached storage solution
ii openmediavault-backup 6.1 all backup plugin for OpenMediaVault.
ii openmediavault-clamav 6.0.4-1 all openmediavault ClamAV plugin
ii openmediavault-compose 6.8 all OpenMediaVault compose plugin
ii openmediavault-cputemp 6.1.3 all cpu temperature plugin for openmediavault
ii openmediavault-diskstats 6.0.3-1 all openmediavault disk monitoring plugin
ii openmediavault-fail2ban 6.0.3 all OpenMediaVault Fail2ban plugin
ii openmediavault-flashmemory 6.2 all folder2ram plugin for openmediavault
ii openmediavault-kernel 6.4.8 all kernel package
ii openmediavault-keyring 1.0.2-2 all GnuPG archive keys of the openmediavault archive
ii openmediavault-kvm 6.2.15 all kvm plugin for OpenMediaVault.
ii openmediavault-mergerfs 6.3.7 all mergerfs plugin for openmediavault.
ii openmediavault-omvextrasorg 6.3.1 all OMV-Extras.org Package Repositories for OpenMediaVault
ii openmediavault-resetperms 6.0.3 all Reset Permissions
ii openmediavault-sharerootfs 6.0.2-1 all openmediavault share root filesystem plugin
ii openmediavault-snapraid 6.1 all snapraid plugin for OpenMediaVault.
ii openmediavault-symlinks 6.0.4 all OpenMediaVault symlinks plugin
ii python3-docker 4.1.0-1.2 all Python 3 wrapper to access docker.io's control socket

And here is the output of sudo apt-get -f install:

Reading package lists...
Building dependency tree...
Reading state information...0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

The latter is not surprising to me, as I guess omv-upgrade fixed the errors there already...

Sure, I appreciate your efforts! I've just reverted everything to "docker" again as the tests didn't work either.

Here you go. Screenshots from docker-compose Settings and the current shared folders again...

I'm pretty sure that I only changed the absolute path in the docker-compose Settings section, but I did not change the shared folder. In fact, I deleted the old docker shared folder, as my objective was to dereference my old SSD, because I wanted to swap it.

I saw no requirement to create another shared folder for docker, as only the absolute path is referenced in the docker-compose settings menu. This is obviously different for the compose entry in the same menu, where the shared folder is used and not the absolute path. It's a bit confusing why you want one or the other, but I didn't question it...

Yes, I've seen the error, but have no idea what the ra71... refers to.

I've rm -rf'ed the dockertest folder again. Recreated it. I removed the old "docker" shared folder completely. I've created a new shared folder "dockertest" and linked it to the empty "dockertest" directory. I then updated the docker path in docker-compose Settings (it is an absolute path, not a shared folder though). Saved the changes. Reinstalled docker. Same error...

Sorry, if I still misunderstand what you try me to do...

I have. Please look further right. There you see the "dockertest" folder I created following your recommendation. It was empty before I reinstalled docker. Now it contains a folder structure, which was not there before...

Didn't help. I created the new docker directory using "mkdir". Changed the shared folder accordingly (see screenshot). Same errors as in my original post, but attached as txt-file again...