Ok, another 4 hours wasted on the most crappy SBC platform OMV is capable to run on 
These fixes should've done the job. At least motd (login greeting) is correct now and also generic installed packages are only pulled in from Debian but not raspberrypi.org any more.
@ryecoaaron or anyone else: please test again: OMV_4_Raspberry_Pi_2_3_3Plus.img.xz
there's a duplicate entry resulting in 'apt update' warning:
I was going to mention this but forgot.
And then this error occurs for whatever reasons:
This is a python bug. Upgrade Debian 9 and 4.x
@ryecoaaron or anyone else: please test again:
I will test it tonight.
Been using on a Pi 3 for a day now with the Plex plugin without any problems
Hi everyone. I am new at omv and I have just buy a Raspberry Pi 3b+. Yesterday I installed OMV V4 and setup my pi as samba and plex servers. I have copied some files throw the network and seen some videos on plex clients (PS4 and Samsung smart tv). I'm also thinking about setup the pi as a webserver for development tests (nginx + mysql, I guess).
So if someone give me some instructions I can test further.
Thanks and sorry for my english, I'm spanish.
@tkaiser - thanks for the work on these
I have tested on my trusty RPi - you'll be pleased to know that I now only use the RPi for testing stuff and not a NAS. 
I have a rock64 as my main server. Using the latest ayufan OMV4 build. This is working well.
Output below from my RPi
Initial observations are it is good. Only things that i noted in the logs are:
1. watchdog module not present so it fails - I have disabled watchdog using - systemctl disable watchdog
2. something is not working with ttyS2. I think this issue was also in the jessie/OMV3 image/build - log entries below.
Jun 2 16:22:57 RPI systemd[1]: dev-ttyS2.device: Job dev-ttyS2.device/start timed out.
Jun 2 16:22:57 RPI systemd[1]: Timed out waiting for device dev-ttyS2.device.
Jun 2 16:22:57 RPI systemd[1]: Dependency failed for Serial Getty on ttyS2.
Jun 2 16:22:57 RPI systemd[1]: serial-getty@ttyS2.service: Job serial-getty@ttyS2.service/start failed with result 'dependency'.
Jun 2 16:22:57 RPI systemd[1]: dev-ttyS2.device: Job dev-ttyS2.device/start failed with result 'timeout'.
@danigarra - raspberry pi is not the best choice for a NAS / SAMBA / PLEX server...
But it does work - just performance is not great...
we can move everything to Sourceforge.
Downloading images now.
Downloading images now
@ryecoaaron Thank you. At least the Banana Pi image at https://sourceforge.net/projec…ngle%20Board%20Computers/ seems to be corrupted. As a reference the MD5 hashes from my server:
e387b82ef6f88ac45f54f8ccde9b98e4 OMV_4_Banana_Pi.img.xz
0ea8cc6c0e1040ebbd9d0a871d9a2019 OMV_4_Banana_Pi_M2_Plus.img.xz
789b3c50ccfab607c942de69b2d4fcb3 OMV_4_Banana_Pi_Pro.img.xz
8772de3602a742687b0cd35f2b826a9b OMV_4_Cubietruck.img.xz
2e711e6946cfb70d22239dfe95797a7b OMV_4_Espressobin.img.xz
831007e758953c903cd2346cb59e3e06 OMV_4_NanoPi_M1_Plus_2.img.xz
192803563d01fe0bde74e0ed8d6b1572 OMV_4_NanoPi_NEO_2.img.xz
1df0a3775a593652cdc73720543754f8 OMV_4_Odroid_C2.img.xz
66569cfe1c0f4627c4f611aa68c08737 OMV_4_Odroid_XU4_HC1_HC2.img.xz
0a0f0062523f7a383386a1256a97dd3f OMV_4_Orange_Pi_PC_2.img.xz
0a1fbe286f06b7051c86338f902e5e83 OMV_4_Orange_Pi_PC_Plus.img.xz
cc9a0741ab16a1fc2c7f94ebbc9e7537 OMV_4_Orange_Pi_Plus_2E.img.xz
8314af7395c4ad637f462b652bac1caa OMV_4_Orange_Pi_Plus.img.xz
a34d1575dba4cecd7b86f7aba784c6d1 OMV_4_Orange_Pi_Zero_Plus.img.xz
d55bbbbbc33e7bb32f66d5edd24dd04c OMV_4_Pine64.img.xz
c9d833c608e42dbda98538c02f9da9a5 OMV_4_Raspberry_Pi_2_3_3Plus.img.xz
c6f924a3a7a44b2ab54fd33b76ea3d52 OMV_4_Tinkerboard.img.xzAt least the Banana Pi image at sourceforge.net/projects/openm…les/4.x%20armhf%20images/ seems to be corrupted. As a reference the MD5 hashes from my server:
I had some problems uploading at the beginning (using sftp). I deleted the bad image and the new image is uploading now.
the new image is uploading now
Great. Now what to do with the older directories? People still download the 3.x images...
Now what to do with the older directories?
I think they should stick around for another month or so.
I think they should stick around for another month or so.
Fine with this. But it would be great if you could rename the directory to 'OMV 4 for Single Board Computers' since currently it's IMO a bit confusing and misleading (majority of boards runs arm64 
)
But it would be great if you could rename the directory to 'OMV 4 for Single Board Computers' since currently it's IMO a bit confusing and misleading
Works for me. Changed.
Hi,
did some testing with the OMV 4.1.7 image for the Odroid HC1 ("OMV_4_Odroid_XU4_HC1_HC2.img.xz"). I had to roll back to 3.0.99 because of some problems. I'm not an Linux/Debian expert, so maybe ive just made a mistake.
Here are my findings after the initial boot with a newly flashed sd-card:
1.) The ethernet adapter has a very strange name "enx001122334455" where "001122334455" is the MAC-address of the adapter. In the old build (3.0.99) it was just the usual "eth0".
2.) I wasnt able to add the interface in the network settings of the gui (see screenshot).
3.) The check for available updates did not work (see screenshot).
After that I switched back to my old installation. I have saved the syslog and the system-information->report file. If one of the moderators is interested, I can send them.
Thanks for your effort!
p.parker
I have the same situation with the eth0 having a long name on my RPi install. I don't have any errors though and I had no issues adding the adapter in the network settings.
I think the long name for eth0 is by design?
I think the long name for eth0 is by design?
Of course: https://www.freedesktop.org/wi…bleNetworkInterfaceNames/
While in Debian 9 (OMV4's basis) it's still possible to use the names from last century neither will this work with next Debian release nor will I share how since predictable interface names should be fine. Other distros switched to predictable names already years ago.
...I think the long name for eth0 is by design?
Hi,
regarding to my good friend google your right. its a "feature" named "consistent network device naming". Here's a thread with some Info.
In this thread is a fix for odroid (possibly for other single board computers).
root@odroid:~# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth0", NAME="eth0"
maybe this will help...
p.parker
In this thread is a fix for odroid (possibly for other single board computers)
This is not a 'fix' since those predictable en... names are neither a problem nor a bug but a solution for a long standing problem with the stupid/primitive/anachronistic interface names like eth0 (exchange position of PCIe cards and the naming of your network interfaces changes!)
This is not a 'fix' since those predictable en... names are neither a problem nor a bug but a solution for a long standing problem with the stupid/primitive/anachronistic interface names like eth0 (exchange position of PCIe cards and the naming of your network interfaces changes!)
uhhh. ok. then I will apologize for my " stupid/primitive/anachronistic" link. I really should be more carefull and I didnt know that "namig network interfaces" could possibly be a science (or maybe a religion...).
Anyway. Maybe I make another try with this knowledge and the error messages that I posted above will magically disappear.
p.parker
Don’t have an account yet? Register yourself now and be a part of our community!
