Hi ,
I got OMV 7 running on raspberry pi 5 with , USB 2.5g NIC .. but i had to run omv-firstaid from the console to configure the USB NIC
after i reboot it seems that the system losses all the USB NIC configuration and no matter how many times i configure it from the console the behaviour is the same
can you let me know what might be the problem ?
I have read on some sites that that Realtek chip is causing problems in some Linux kernels. On an amd64 system I would tell you to install another kernel, but since this is a Pi I wouldn't know how to tell you how to solve it. Maybe the Raspberry forum will have a solution.
In that case it seems that we would have to look for the reason in OMV, but it is strange, many people use USB NICs and they do not usually cause problems, I have done it myself (not with a PI). Maybe someone has some ideas.
This sounds like it might be related to my issue: RE: RPI updates - Ethernet dongle - Remote Mount
To summarize: I have two NAS boxes running OMV on RPI4 and Bookworm. Both NAS have the same ASUS USB-C2500 dongle and worked well under Bookworm, until an update to mostly RPI related was issued on Mar 11th. Since that day, I have to unplug and re-plug the dongle (I refer to this as the "dongle dance") during the OMV boot process in order to complete the boot sequence and get to the OMV UI. If I do not unplug/re-plug the dongle, the OMV will not boot but I can still get at the RPI command line (direct, not SSH which won't work until OMV finishes the boot sequence with the dongle dance.)
Once the dongle dance is performed, I get full bandwidth duplex mode. I am confident the issue has nothing directly to do with the Realtek driver and it's more of a OMV bootup sequence issue that halts until I perform the dongle dance. It was perfectly fine (no dongle dance needed) until the Mar 11th release.
I have looked at all the logs I can think of. The problem is the logs do not reference the dongle drivers at all without doing the dongle dance. So I can't tell what part of the process is broken but the CLI is telling me there is no connection to the router because there is no ethernet.
I've been patiently waiting for someone else to run into this as it seems there is not many in the 2.5 Ghz dongle community. 
These are not my primary media servers so I can live with it for awhile, it's only annoying.
I think both models run the same chip, but not perfectly confident on this.
I wonder if you need to run FirstAid, while I do not, is because it did work fine until the update for me so maybe I have a file already configured, while you don't. Seems odd you would have to keep doing that each time though.
It seems like it would be a trivial fix. We just need to get someone interested in helping us figure out what is halting during the boot and why the need to unplug the dongle.
You can try the following to see if it works, create a scheduled task in the OMV GUI to reboot the USB device after starting the server.
This could be the process, based this link
Identify the device using:
sudo lsusb -t
From the output of that command you must identify the bus and port
Example:
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
|__ Port 3: Dev 10, If 0, Class=Vendor Specific Class, Driver=r8712u, 480M
|__ Port 7: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12MSuppose the device is on bus 5 and port 3
In the OMV GUI create a scheduled task with the following command:
sleep 60; echo '5-3' | tee /sys/bus/usb/drivers/usb/unbind; echo '5-3' | tee /sys/bus/usb/drivers/usb/bind
- where 5-3 is equivalent to bus 5 and port 3 in this case.
- 60 is the number of seconds after startup to execute the following two commands, you can increase or decrease this value if necessary.
- In the "Time of execution" field of the scheduled task, choose "At reboot" (it is at the bottom). I'm not sure if this only works with reboot or starting the server from the shutdown state, you'll have to check.
- In the "User" field choose "root".
That scheduled task should reboot the USB NIC a minute after starting the server, that should avoid the manual disconnect and reconnect dance.
both have the same problem in OMV while both run smoothly in raspberry OS (
That doesn't make any sense. They are using the same kernel and if the device doesn't show up in the usb device list, then the network stack can't do anything about that. I can't think of anything magical that network-manager is doing to keep this working.
I just ordered the Asus version. I will get it tomorrow and can try to figure out how to fix this.
I just ordered the Asus version. I will get it tomorrow and can try to figure out how to fix this.
thank you for stepping in too ,, cant wait to hear from you
the device doesn't show up in the usb device list
Yes, that's strange.
When adults speak, children listen 
We will wait for your response, I'm curious. And thanks.
Maybe just a matter of adding/changing some dt_overlay on config.txt?!?
Raspberry Pi Documentation - The config.txt file
Note: haven't read it properly and have no Pi running.
I can try to use my USB-c 2.5 dongle if I find a USB-a to USB-c adapter once I rotate home.
Maybe just a matter of adding/changing some dt_overlay on config.txt?!?
What did you have in mind? I've never had to add anything for gigabit usb network adapters in the past.
What did you have in mind? I've never had to add anything for gigabit usb network adapters in the past.
Just some thought that cross the mind.
Perhaps something else is needed for lite versions to see the USB NIC since it's Realtek and there's no good stories with that brand on Linux. (AFAIK)
It's strange that the Desktop OS has no issues with it.
And since there's a bit of control on what modules can be passed to function via config.txt, might be one that will work.
Again, haven't read it proper for Pi 5.
Also just remembered
Does the dongle require high power?
There's a line to be changed to feed more power to the USB ports. Don't recall from where I read it.
It's either with vcgencmd or on the config.txt
desktop and lite use the same kernel. I know I disable bluetooth and wifi to save power on OMV installs but my desktop install has both enabled. So, I would think the desktop would have more issues with power. Hard to say until I have one in hand though.
Here are the Mar 11 releases changes that broke the NIC boot. Maybe there is a clue?
dphys-swapfile (20100506-7.1+rpt3) bookworm; urgency=medium * Don't run if root overlay is enabled -- Serge Schneider <serge@raspberrypi.com> Mon, 11 Mar 2024 16:47:00 +0000
linux (1:6.6.20-1+rpt1) bookworm; urgency=medium * Raspberry Pi OS release * Remove unecessary patches * Add rpi featureset * Import Raspberry Pi defconfigs * Allow initramfs generation to be skipped in postinst * Move initramfs-tools to recommends * Install overlays README * Don't sign arm64 kernels * Compress arm64 kernel * Disable unecessary architectures * Use GCC 12 * Add +rpt to abiname * Add epoch support in version string * Linux commit: 6f16847710cc0502450788b9f12f0a14d3429668 -- Serge Schneider <serge@raspberrypi.com> Thu, 07 Mar 2024 14:51:31 +0000
raspi-config (20240228) bookworm; urgency=medium [ Tim Gover ] * Allow EEPROM upgrades [ Simon Long ] * Check wayvnc service to determine status -- Simon Long <simon@raspberrypi.com> Wed, 28 Feb 2024 14:54:21 +0000
raspi-config (20240216) bookworm; urgency=medium [ Simon Long ] * Call panel functions to update wifi country status when setting -- Simon Long <simon@raspberrypi.com> Fri, 16 Feb 2024 13:18:03 +0000
raspi-config (20240214) bookworm; urgency=medium [ Simon Long ] * Remove VNC resolution setting for Wayland -- Simon Long <simon@raspberrypi.com> Wed, 14 Feb 2024 13:04:45 +0000
raspi-config (20240213) bookworm; urgency=medium [ Simon Long ] * Add Wayland switching for x86 images -- Simon Long <simon@raspberrypi.com> Tue, 13 Feb 2024 07:37:56 +0000
raspi-config (20240131) bookworm; urgency=medium [ Simon Long ] * Remove logind power key settings in do_boot_behaviour -- Simon Long <simon@raspberrypi.com> Wed, 31 Jan 2024 12:48:28 +0000
raspi-config (20240130) bookworm; urgency=medium [ Simon Long ] * Add labwc screen blanking -- Simon Long <simon@raspberrypi.com> Tue, 30 Jan 2024 07:43:59 +0000
raspi-config (20240111) bookworm; urgency=medium [ Simon Long ] * Add labwc switching -- Simon Long <simon@raspberrypi.com> Thu, 11 Jan 2024 14:39:54 +0000
raspi-firmware (1:1.20240306+ds-1+rpt1) bookworm; urgency=medium * New upstream version 1.20240306+ds -- Serge Schneider <serge@raspberrypi.com> Wed, 06 Mar 2024 16:42:23 +0000
openmediavault (7.0.2-2) stable; urgency=low * Fix problem when deploying file system quota. * Issue #1725: Add search field to shared folder page. -- Volker Theile <volker.theile@openmediavault.org> Sat, 09 Mar 2024 16:48:27 +0100
Just some thought that cross the mind.
Perhaps something else is needed for lite versions to see the USB NIC since it's Realtek and there's no good stories with that brand on Linux. (AFAIK)
It's strange that the Desktop OS has no issues with it.
Well that was true for Bullseye, where the driver integration seemed only half working (the dongle works but limited to half duplex.) When going to Bookworm/OMV7 the ASUS USB-C2500 worked fine up until the Mar 11 release.
linux (1:6.6.20-1+rpt1) bookworm; urgency=medium * Raspberry Pi OS release * Remove unecessary patches * Add rpi featureset * Import Raspberry Pi defconfigs * Allow initramfs generation to be skipped in postinst * Move initramfs-tools to recommends * Install overlays README * Don't sign arm64 kernels * Compress arm64 kernel * Disable unecessary architectures * Use GCC 12 * Add +rpt to abiname * Add epoch support in version string * Linux commit: 6f16847710cc0502450788b9f12f0a14d3429668 -- Serge Schneider <serge@raspberrypi.com> Thu, 07 Mar 2024 14:51:31 +0000
raspi-firmware (1:1.20240306+ds-1+rpt1) bookworm; urgency=medium * New upstream version 1.20240306+ds -- Serge Schneider <serge@raspberrypi.com> Wed, 06 Mar 2024 16:42:23 +0000
These 2 might have messed with something.
If you can revert to PRIOR those updates, maybe it's possible to check a diff somewhere/somewhow, specially the first one:
* Remove unecessary patches *This is me being analytical...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!