I thought OMV 4.x was out for a longer time
Available? Yes. Officially declared stable? No.
that some other OMV4.x arm images would be available
I think tkaiser was waiting for OMV 4.x to be declared officially stable. The update does work well.
Building OMV automatically for a bunch of different ARM dev boards
-
-
Hi,
I just purchased a banana pi M1+ and have tried to use of the appropriate image file (OMV_3_0_87_Bananapi_4.12.9.img.xz). I used etcher to write the sd card, but the disk does not seem to work.I notice that there do not seem to be any files on the sd card when I view it in windows explorer.
Can you please check that the image file should work? I am pretty new to this.
Thanks,
Robert
-
I downloaded the same image and it creates two partitions - 1 is ext4 64MB, 2 is btrfs 863 MB, the remainder is unallocated. Neither of these are visible on Windows (it can see two "drives" but not the contents), but I can see both partitions no problem on Debian. I don't have a Bananapi to flash, but this might be helpful.
-
@whi401: did you safely unplug it? I always do that, especially in Windows. I do not have a BananaPi, I am using any Linux distro to check that the contents is valid. Try not to let Windows take a look at it, it may corrupt it. Safe unplug after it finishes writing, check that BananaPi is set to boot from microSD card and profit.
-
Thanks for the suggestions. I have used etcher before and have successfully started the bananapi using images I have created.
I started using bananian and seemed to get omv setup, but the docker-gui would not load and the performance was not great. I am interested trying this optimised iso and thought some user feed back was needed.I am currently running armbian 5.38 and have just started to look into setting up omv. I would like to take advantage of this optimised iso because it looks like a lot of work has been put into it.
When I boot from the sd card that I make the bananapi seems to do nothing at all. The monitor remains blank (unlike when bananian or armbian boot). There are activity lights on the network connector and the hard disk spins, but no signs of life even after 20 minutes or so.
Maybe the image is for other hardware?
Thanks for your help so far.
Regards, Robert
-
Can you please check that the image file should work?
Why should we provide images that do not work? Each and every of the images has been tested by me and works flawlessly. OMV is a headless system so I neither know nor care whether you get output on a HDMI display. The board needs to be connected to the network with Internet access and a DHCP server. It will update some packages and then reboot. Then access it using a web browser.
-
Thanks for your help.
I usually connect a keyboard and leave the monitor connected to the hdmi socket when setting up the system. I find that it is useful to monitor the system information as the computer boots up. I am sure the software developers of other distributions include this display to assist users in monitoring system performance.I have found that omv reports the ip address where the web gui can be found, which is quite useful. The armbian server version also provides interesting information, such as cpu temperature and voltage, although it is intended to operate headless. The bananian version I used also caused the on-board led to blink like a heart-beat when it was operating.
Unfortunately when I saw no helpful information I concluded that things were not going to plan.
-
I am sure the software developers of other distributions include this display to assist users in monitoring system performance.
That is valid assumption in the i386/amd64 world but not so much in the arm world. Serial port and jtag output are commonly used. But since armbian does all the hard work, you shouldn't need output at all. If you want the ip address, your router or dhcp server should be able to tell you. From there, everything else important can be done from the web interface or ssh.
The armbian server version also provides interesting information, such as cpu temperature and voltage, although it is intended to operate headless
This is reported when you login via ssh as well.
The bananian version I used also caused the on-board led to blink like a heart-beat when it was operating.
The omv images on most arm boards do this as well.
-
Hello,
Is the Espressobin v7 supported or will it be supported?
Thanks -
I found the latest and greatest images of OMV 4 for our beloved arm thingies @https://sourceforge.net/projec…ngle%20Board%20Computers/ which were build around one year ago.
Is there by any chance the possibility to get the images freshly build (For example the 4.1.22 branch like for the big boys amd64)? It's sucks quite a lot of time and even more traffic to install and upgrade based on these images nowadays. This is especially true for areas with slow and metered internet up link. It even happens that the installation silently fails. To download the image is easier because it is possible to resume a failed download of the image... the needed updates for the installation should be quite small with a up to date install media - the possibility to succeed with the install could be much higher then
Other great improvement would also to make it possible to install the image without a connection to the world wide web. But upgraded install medias would do the thing already - for now
Thank's!
PS.: And for sure nobody has requested OMV 5 beta images for arm boards. Nobody!
-
Well, that's maybe because nobody using it thought to ask? I'm working on getting an HC1 build set up right now. I'll limp along with what's offered for now, but there's got to be a better answer for all here.
-
there's got to be a better answer for all here
Use the images on sourceforge.net/projects/openm…ngle%20Board%20Computers/ and update them to latest version. I'll never provide OS images that work without internet connection for the simple reason that updates are important. It's about security fixes and other functional fixes. People right now constantly report 'problems' in the forum that are long since fixed because they do not update their OMV installs. This makes absolutely no sense and keeping your IT boxes up to date is also the most important factor of IT security.
If you fear huge downloads, then grab an Armbian Stretch image for the device in question, install and then run armbian-config --> Software --> Softy --> Install OMV. But I doubt the amount of download data will differ that much compared to using the OMV images from SF and then simply letting them upgrade.
As for the reason why there aren't newer OMV images for ARM boards: since it's a huge amount of work. With latest changes in Armbian over the last year the installation tweaks need to be adopted first (the current routine will partially produce garbage) and then everything that's put on SF needs to be tested first. The x86 ISO needs to be tested on just one single machine, due to the situation on ARM being different each and every OMV image for ARM needs to be tested on the target platform first. And I don't own vast majority of these boards any more and collaboration with separate testers is really time consuming if stuff needs to be fixed.
So no, new images will not happen anytime soon or at all.
Edit: most probably there won't be any OMV5 images for ARM boards available later since the way to go is to install Armbian and then continue with armbian-config as explained above. All the tweaks for a performant and reliable OMV install are only contained in armbian-config for the moment: https://github.com/armbian/con…debian-software#L534-L736
-
Edit: most probably there won't be any OMV5 images for ARM boards available later since the way to go is to install Armbian and then continue with armbian-config as explained above. All the tweaks for a performant and reliable OMV install are only contained in armbian-config for the moment: github.com/armbian/config/blob…debian-software#L534-L736
Since I already have a couple R-PI 2's in a box, and would rather not buy another SBC just for testing:
Would the armbian-config --> Software --> Softy --> install OMV process be the same for the R-PI 2, as it would be for any other SBC?
Or would you anticipate that installation "tweaks" would be required among the various models? -
Well, that's maybe because nobody using it thought to ask? I'm working on getting an HC1 build set up right now. I'll limp along with what's offered for now, but there's got to be a better answer for all here.
I have HC1. But maybe it's another reason to choose x86 instead of ARM if the future is so uncertain.
-
Would the armbian-config --> Software --> Softy --> install OMV process be the same for the R-PI 2, as it would be for any other SBC?
Sure. When I developed the OMV install routine in armbian-config I tested on both Armbian and Raspbian Jessie variants to ensure that dependencies are met on both variants. And the installation tweaks are necessary but not that much on any of the RPi models since they're condemned to be slow due to their 'everything behind one single USB2 port' limitation and as such tweaks won't help here that much or at all. The config tool is supposed to run on any supported Debian or Ubuntu variant, see the readme: https://github.com/armbian/config
But maybe it's another reason to choose x86 instead of ARM if the future is so uncertain
Nothing is uncertain, it's just saving the efforts to create dedicated OMV images again since they require huge amounts of time (I hate releasing stuff without proper testing). Since OMV is based on Debian and Debian will be available on any of the interesting ARM devices OMV will be there or one call of armbian-config away. The only question is what is about OMV and USB storage (or ‘Removable devices’ as @votdev calls them) in the future.
I guess Frank ( madscientist42) was asking for an OMV5 beta install for his HC1. That's what I hinted to above: use the Armbian build system, create a Debian Buster image and then install OMV5 in an additional step.
My personal take on this (uncertainty of USB storage in OMV6) is trying to get an energy efficient and affordable ARM thingy with 'real' or at least PCIe attached SATA based on Amlogic S922X: https://forum.khadas.com/t/vim…3-nas-server-variant/4287
-
Nothing is uncertain, it's just saving the efforts to create dedicated OMV images again since they require huge amounts of time (I hate releasing stuff without proper testing). Since OMV is based on Debian and Debian will be available on any of the interesting ARM devices OMV will be there or one call of armbian-config away. The only question is what is about OMV and USB storage (or ‘Removable devices’ as @votdev calls them) in the future.
I guess Frank ( madscientist42) was asking for an OMV5 beta install for his HC1. That's what I hinted to above: use the Armbian build system, create a Debian Buster image and then install OMV5 in an additional step.
My personal take on this (uncertainty of USB storage in OMV6) is trying to get an energy efficient and affordable ARM thingy with 'real' or at least PCIe attached SATA based on Amlogic S922X: forum.khadas.com/t/vims-propos…3-nas-server-variant/4287
Sounds ok...
So installing omv yourself on armbian does not differ from your dedicated image in any percentage?
I hope that it will not affect performance or stability.So next versions 4 and 5 for ARM will continue to appear, but not in the form of dedicated image?
It's enough for me, as long as there are still available versions for ARMv7 because I have HC1. -
So installing omv yourself on armbian does not differ from your dedicated image in any percentage?
There are no differences other than filesystem details (with the dedicated OMV images the rootfs will only be resized to 7.3GB and on majority of boards be based on btrfs instead of ext4).
And it's not exactly 'on armbian' but using the armbian-config installation routine. You get the same by doing this on any Debian Stretch/Buster around:
Codeecho "deb [arch=arm64] http://apt.armbian.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/armbian.list apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 9F0E78D5 apt update apt install armbian-config armbian-config(then Software --> Softy --> 'Install OMV').
-
And the installation tweaks are necessary but not that much on any of the RPi models since they're condemned to be slow due to their 'everything behind one single USB2 port' limitation and as such tweaks won't help here that much or at all. The config tool is supposed to run on any supported Debian or Ubuntu variant
As it seems, it's still too early to know what the outcome will be. However, if installing OMV5 on ARM platforms moves to an installer (versus images), the first thing that came to mind is documenting an SBC setup for beginners, in a walk-through format.
My concern would be if there are significant setup differences between the various SBC models. Since I only have the R-PI 2's to work with (Raspbian/Jessie), the end result might not be accurate enough to be worthwhile (for Armbian SBC builds).In the mean time, I'll run through an Raspian-Jessie/OMV build for a first look.
-
In the mean time, I'll run through an Raspian-Jessie/OMV build for a first look.
Makes absolutely no sense of course.
-
Makes absolutely no sense of course.
A comment like that is so in character -
- nothing has changed there.I tested on both Armbian and Raspbian Jessie variants to ensure that dependencies are met on both variants.
OK, maybe I missed something, but it appears that there's no R-PI support on Armbian. (At least, I didn't find anything on the Armbian download site.) If that's the case, what's the basis for the R-PI image in OMV4?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!