RPi and other SBC/armbian images

Zitat von crashtest

1. 1. I'm not using "prejudice". The quotes above are your own words. If you're not stating what you're using or doing, correctly, that leaves things in the same place - a basket load of unknowns.
   2. Further I have to work based on assumptions. The chief assumption is that the guide (if you used it) was followed accurately. Otherwise the potential variables become infinite.

I checked your syslog against my own. I saw where wsdd went off the rails. Again, with reference to the build process, I don't have anything else to offer for the reason "why".

But I will ask you a question:
The R-PI and Armbian builds are setup, by beginner users, in numbers between hundreds to thousands of times every week. You are the only one, that I'm aware of, to report the WSDD loop. And against really (really) long odds; you report that you have the exact same problem with two different builds with images coming for two separate sources (Armbian - Raspbian), on two separate hardware platforms (Tinkerboard and R-PI). Given the hundreds to thousands of installations that work, almost every time, can you explain that to me?

Here is what seems to be obvious to me:

- The commonality of the same error on two different builds and two different hardware platforms can't be ignored.
- This issue, whatever it is, almost has to be on your end. (Or the forum would light up like a Christmas tree.)

Is it something you're doing? Does it have something to do with software sources in your region? Is it some kind of weird firewall issue with your router, a VPN device, etc., etc.? In the bottom line, what is it? The answer to all these questions is, "I don't know".

The bottom line is, sorry, I can't help you.
___________________________________________________________

If you repost in a separate thread, I won't answer it. Perhaps someone with more experience than I have will answer it, and can guide you toward the source of this problem.

Alles anzeigen

I am your fan (OMV), I am using OMV since R-pi2 (OMV 3) and until now, using R-pi3, and Tinkerboard (R-pi4 not release yet), I don't have any issue and enjoy it for almost 1-2 years without being touch directly until one day (exactly around december 2020) my OMV 4 (after updated OS) have several issues

• Dropping the file transfer in the mid of process (only in ARMBIAN)
• wsdd looping

then, in January I bought new R-pi3B+ (which is already 802.11 ac and Gigabit Interface, it's worthed compared R-pi4) and R-pi4.

Since I am developing new products for our market in automobile so I need to testing which is most affordable (price after design & assembling) thus I use those models to test-out are they face the same issue with existing my old R-pi3B and Tinkerboard, the result as I shared with you.

I deployed in several network scenarios for those models

1. Home Network connection - no Proxy, filtering mostly for brute force knock down (incoming SSH & FTP), VLAN enabled, VPN Server enabled to manage my several router across nations.
2. LTE/3G Network connection - filtering is on the telco, which is out-of my control.

I deployed in several repository scenarios for those models

1. Using our local repository of raspbian and debian (Raspberry) and EU repository of armbian.
2. Using default repository of raspbian and debian (Raspberry) and Asia repository of armbian.

The results both of them are SAME for wsdd error looping, and as you said as well, WHY? What Happen .... therefor I testing several times to make sure, even I bought and borrowed SBC from my friends and colleague the results are same ....

Hmmmm ............. I am lost in middle of nowhere

Zitat von crashtest

One of the other moderators ran down the only reference to -> "wsdd loop" that he (and now I) is aware of. This issue was opened for wsdd version 0.6 The issue appears to have been fixed and closed on June 28, 2020.

This is the version of wsdd I have installed:

Code

pi@R-PI4:~ $ apt list wsdd
Listing... Done
wsdd/usul,usul,now 0.6.2-1 all [installed,automatic]

If I were to speculate, actually it's more of a WAG, the Debian Buster software mirrors in your area may be "updating" both installations with an older and outdated wsdd package. If the version you find is different from the above, a potential solution might be to run the images, without updating them, to see what happens, or apply the work around fix from github.

________________________________________________________

When SBC's are working correctly, mitigating or avoiding issues like this is relatively easy with -> OS backup. All it takes is a second SD-card.

Alles anzeigen

Mine,

root@nas:/usr/bin# apt list wsdd
Listing... Done
wsdd/usul,usul,now 0.6.2-1 all [installed,automatic]

root@nas:/usr/bin# systemctl status wsdd
● wsdd.service - Web Services Dynamic Discovery host daemon
   Loaded: loaded (/lib/systemd/system/wsdd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-02-12 18:18:01 WIB; 1min 8s ago
 Main PID: 25096 (python3)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/wsdd.service
           └─25096 python3 /usr/sbin/wsdd.py --shortlog --workgroup=WORKGROUP

Feb 12 18:19:08 nas wsdd.py[25096]:   File "/usr/sbin/wsdd.py", line 184, in handle_request
Feb 12 18:19:08 nas wsdd.py[25096]:     handler.handle_request(msg, address)
Feb 12 18:19:08 nas wsdd.py[25096]:   File "/usr/sbin/wsdd.py", line 690, in handle_request
Feb 12 18:19:08 nas wsdd.py[25096]:     reply = self.handle_message(msg, self.mch, address)
Feb 12 18:19:08 nas wsdd.py[25096]:   File "/usr/sbin/wsdd.py", line 335, in handle_message
Feb 12 18:19:08 nas wsdd.py[25096]:     tree = ElementTree.fromstring(msg)
Feb 12 18:19:08 nas wsdd.py[25096]:   File "/usr/lib/python3.5/xml/etree/ElementTree.py", line 1344, in XML
Feb 12 18:19:08 nas wsdd.py[25096]:     parser.feed(text)
Feb 12 18:19:08 nas wsdd.py[25096]:   File "<string>", line None
Feb 12 18:19:08 nas wsdd.py[25096]: xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 1, column 547
root@nas:/usr/bin#

Zitat von crashtest

This is all I can suggest; -> create an issue.

Or turn WSDD off.

sudo service wsdd stop

The device will disappear from the windows network view but it will still be possible to map a network drive, from the device.

Right now, wsdd is off, I'm not using it anyway, its for home. Thanks bro. Appreciate it.

Zitat von ryecoaaron

The RPi and SBC/Armbian images on sourceforge have been deleted. Please using the Raspbian Buster Lite or the proper Armbian image and follow the guide here to install OMV - https://forum.openmediavault.o…-Armbian-Supported-SBC-s/

I am brand new to the OMV scene, and I'm trying to follow the directions, but when I run the code wget -O - https://github.com/OpenMediaVa…Script/raw/master/install | sudo bash I am getting an error "OMV 6.x on RPi is waiting for a fix. Exiting...". Any ideas on when this might get fixed, or am I missing something?

Zitat von ryecoaaron

As soon as 6.0.10 is released.

Can you give some pointers to what this is all about?

Or just a link to understand why it's been blocked?

thanks

Saw it, thank you geaves

Upgrading openmediavault package 6.0.7-1 -> 6.0.8-1 wants to remove sddm and task-kde-desktop · Issue #1186 · openmediavault/openmediavault (github.com)

Zitat von ryecoaaron

If anyone wonders why you should use the 64bit image on an RPi, look at the benchmarking - https://www.phoronix.com/scan.…berrypi-32bit-64bit&num=1

The wiki stills recommend 32bits right?

Zitat von ryecoaaron

Which wiki? And if it does, it should be changed in my opinion.

https://wiki.omv-extras.org/do…talling_omv6_raspberry_pi

https://www.raspberrypi.org/so…s/#raspberry-pi-os-32-bit

Hi.

Since the OP links to the OMV installation guides for SBCs, I suppose this is the correct thread to post my issue.

I tried installing OMV on my Banana Pi M1, but I keep hitting a wall.

Following this guide from early 2024 by crashtest, I installed debian bullseye and subsequently ran the install script, following the guide closely. Unfortunately, the OMV installation script seems to run into a few directory trees that branch up differently than expected. E.g., this location:

http://armbian.systemonachip.net/apt bullseye Release

Inspecting this URL using a web browser, there is an additional directory "dists" that would contain a "bullseye" directory. But the script does not look inside that directory. Hence, it cannot finish installing OMV and it exits with these lines:

E: The repository 'http://apt.armbian.com bullseye Release' does not have a Release file.
[2024-03-05 08:08:39+0000] [omvinstall] failed to update apt repos.

Or am I mistaken? I am not a linux expert.

I already wrote my issue to the omvguide gmail e-mail address, where I also attached my install.log that shows the errors the install script ran into.

I tried the default version of bullseye (I guess that is the CLI version) and the minimal version, both from the archive web page.