Download old RP3 OMV images

  • Hi all.


    Someone has a link to download the OMV3 for RaspberryPi 3?


    I updated my RP3 to OMV4 but Sonarr is no longer compatible (and I'm having trouble to install Docker) so I want to roll back to the 3.0.99 version I had (but I dont have the image anymore).


    Thank you.

    • Offizieller Beitrag

    The first thing to note is, get a second SD-card so you can clone your install. If something like this happens again, you can fall back.


    As it seems, the OMV R-PI download location doesn't appear to have the older 3.X images. Perhaps this will be corrected soon.
    In any case, I have a copy for the R-PI, OMV ver 3.0.63. that I'm posting for you. (It's uploading right now and given that uploads are way slower than downloads, even on a cable modem, it may be a couple hours before it's there.)


    The MD5 check sum, as it exists on my hard drive, is: b05e398210c4b577b128a4d5145bf4f6 (I remember checking it after downloading it, but I don't have the original MD5 hash.) You'd have to go through the update process to get the install to 3.0.99.


    Remember, if you get a second SD-card and clone your working install, you'll be able to back out of updates, not to mention recovering from SD-card issues and other potential failures.


    I'll post the link when the image is available.

    • Offizieller Beitrag

    Here's a link to the image -> (ONE TIME USE LINK DELETED)



    If you don't know how to clone an SD-card, you can find a cloning process -> here.

  • I have a copy for the R-PI, OMV ver 3.0.63. that I'm posting for you

    Better remove the link since my last OMV 3 image for RPi is also the first that will boot on a RPi 3B+ (that's due to the fact those Raspberry Pi are no normal ARM SBC but proprietary VideoCore SBC with some lousy integrated ARM cores. So the primary operating system of these things called ThreadX that lives on the FAT partition needed an update to be able to support the new hardware. And that's why only my last image will boot on those things)

    • Offizieller Beitrag

    Better remove the link since my last OMV 3 image for RPi is also the first that will boot on a RPi 3B+ (that's due to the fact those Raspberry Pi are no normal ARM SBC but proprietary VideoCore SBC with some lousy integrated ARM cores. So the primary operating system of these things called ThreadX that lives on the FAT partition needed an update to be able to support the new hardware. And that's why only my last image will boot on those things)

    Done.


    It was just a quick fix for @luizbacci so he could back out of OMV4, for the R-PI3.


    When I looked on Source Forge, in the Raspberry PI Images Folder I found a single OMV4 image. I looked around but didn't find any of the earlier images for the R-PI, and I know they were available at one time. Out of curiosity, are you planning to replace the legacy images that seem to have been moved?

  • Out of curiosity, are you planning to replace the legacy images that seem to have been moved?

    Huh?


    We removed the OMV 3 image since even when the OMV 4 image was available a few hundred downloads per week occured with the old image most probably for the only reason people read in some tutorial on the net they should download OMV 3.


    An 'omv-release-upgrade' which will also update from Debian 8 to 9 is a lot of storage stress and the average RPi user isn't aware that this can result in their SD card being broken afterwards since RPi Foundation takes great care of not telling them how important genuine and tested SD cards are.


    Especially users of counterfeit cards can end up with broken installations afterwards so we thought it would be the best idea to prevent this from happening by only providing OMV 4 for now.


    I'll leave the last OMV3 image on my server and also archived it right now. So RPi users equipped with some Google-Fu will find this thread and the image.

    • Offizieller Beitrag


    We removed the OMV 3 image since even when the OMV 4 image was available a few hundred downloads per week occured with the old image most probably for the only reason people read in some tutorial on the net they should download OMV 3.


    In the above, who is "We"? And since this decision deals with OMV's public archive, with a scope that's clearly at the project level, does "we" include @votdev ?


    ____________________________________________________


    Using the above logic, that there's "some tutorial on the net" or that users may use "faulty boot media", there shouldn't be any legacy images at all. This would include legacy ISO's and images for 32bit i386 platforms, the truly obscure Arm devices, and the Beta versions that go back to OMV 0.2.
    If "tutorials" and the possibility of "faulty boot media" are the criteria for maintaining the archive, there's still a lot of deleting to do.


    In the overview, "How-To's" and other anecdotal documentation on the net (which serve as a written "word of mouth") bring a lot of users to OMV. Further, building a platform with a legacy image where a previously supported feature still exists and is needed/wanted, is a legitimate reason to use it.


    Is this an open source project, where user choice is the clear focus, OR will the OMV project go the route of Microsoft where all are being herded onto the latest version (like Windows 10) ?


    If it's about support, as in not wanting to provide it for earlier versions of OMV on an R-PI:
    A production suggestion would be to create a sub-directory under Raspberry Pi Images, titled Obsolete - Unsupported , with an appropriate "read me" file, and move the final versions of OMV 2 and OMV 3 into it. By navigating into the folder, users would know EXACTLY what the support situation would be, at the start.


    Regarding downloads, the R-PI 3.0 image may be popular for several reasons beyond "tutorials". One obvious reason is the number of plugins natively supported - one of the original reasons for this thread. In any case, nothing stated in your post is a good reason to simply cut users off from R-PI 3.X and earlier images in the public archive.


    BTW: If it wasn't for those "How-To's", "Tutorials", and other anecdotal Linux documentation on the net, the Linux user base would probably be less than half of what it is.

    • Offizieller Beitrag

    @ryecoaaron and me. He has access to SF unlike me. I've never seen anyone else than us wasting time with this RPi mess anyway...
    (and now I waste my time reading through Microsoft blabla)

    If you're wasting your time at, "whatever", that's your own decision. There's no point in informing the forum of it, or the world writ-large, repeatedly.

    • Offizieller Beitrag

    In the above, who is "We"? And since this decision deals with OMV's public archive, with a scope that's clearly at the project level, does "we" include @votdev ?

    The arm images were started by me and never really an official part of OMV. Volker just gave me access to host them on sourceforge. While I do keep old packages around in the repos, I have always removed old images and agreed with tkaiser about removing the omv 3 image. It really helps remove the load of maintaining old packages - especially the downloader plugins that are breaking now (and the seemingly main motivation for using OMV 3). While it would be slow, someone could probably install armbian and use the utility to install OMV just like the image if they had to have OMV 3 (no idea why).

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    The arm images were started by me and never really an official part of OMV. Volker just gave me access to host them on sourceforge. While I do keep old packages around in the repos, I have always removed old images and agreed with tkaiser about removing the omv 3 image. It really helps remove the load of maintaining old packages - especially the downloader plugins that are breaking now (and the seemingly main motivation for using OMV 3). While it would be slow, someone could probably install armbian and use the utility to install OMV just like the image if they had to have OMV 3 (no idea why).

    Then it would make sense to pull ALL of the older Arm 3.X images, not just those for the R-PI, correct? If plugins are the problem, they would all suffer from the same issues.


    But, from what I see, there are several ARM OMV3.X images available for the Odriod, Orange PI, Nano PI, Lime2, Cubi, Clear Fog, Helios, etc., etc. I can see the support issue(s) now, when it's explained logically, but there is the matter of consistency. If it's about package support and breaking 3.0 plugin's, all of these images would have the same problem(s)? Right?

  • While it would be slow, someone could probably install armbian and use the utility to install OMV just like the image if they had to have OMV 3 (no idea why).

    There's no Armbian for Raspberries though armbian-config's optimized install routine should work on Raspbian (at least it did when I tried out OMV 4 the first time last year... on a RPi).


    So there's only Raspbian as an option and users don't find the older Jessie based Raspbian variants which would be a requirement for OMV 3. And even if they have some Google-Fu and find the Raspbian Jessie image somewhere this won't boot on RPi 3 B+ since the ThreadX installation on the FAT partition (euphemistically called 'firmware') is too outdated.


    In other words: I like @'flmaxey''s idea of uploading OMV_3_0_99_RaspberryPi_2_3_4.9.80.img.xz again and putting it in an 'unsupported' subdir in the RPi directory even if it's pointless. Debian Jessie is EOL since a few weeks and some architectures aren't even provided with security updates any more (arm64 being affected). But this would of course require that we (you ;) ) find a generic solution for the apt pinning mess with the RPi images. I fear my OMV3 image once upgraded to OMV4 behaves strange unless the pinning gets fixed.

    • Offizieller Beitrag

    Then it would make sense to pull ALL of the older Arm 3.X images, not just those for the R-PI, correct? If plugins are the problem, they would all suffer from the same issues.


    But, from what I see, there are several ARM OMV3.X images available for the Odriod, Orange PI, Nano PI, Lime2, Cubi, Clear Fog, Helios, etc., etc. I can see the support issue(s) now, when it's explained logically, but there is the matter of consistency. If it's about package support and breaking 3.0 plugin's, all of these images would have the same problem(s)? Right?

    The goal was to remove any 3.x image IF a 4.x image was available. I probably didn't do a good job in the other armhf folder but there are plenty of boards that will never have a 4.x image like the odroid-c1. That said, I probably should remove those too. I really haven't put too much thought into it other than I didn't want a ton of images sitting around especially a heavily used image like the RPi and XU4.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • If it's about package support and breaking 3.0 plugin's, all of these images would have the same problem(s)? Right?

    Nope, all those images are 'pure Debian' and not that RPi mess (the lousiest SBC causing the most work).


    But thanks for the reminder. I asked @ryecoaaron already to delete all those OMV3 ARM images (except the one for ODROID-C1 since due to crappy kernel situation this board can't run Debian Stretch). He didn't want to for whatever reasons (I really don't care since those other ARM images don't cause headaches)

    • Offizieller Beitrag

    I fear my OMV3 image once upgraded to OMV4 behaves strange unless the pinning gets fixed.

    That will definitely be an issue. I still think using OMV 3.x ESPECIALLY for the downloader plugins is a bad idea.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    He didn't want to for whatever reasons

    I forgot to delete them. I will do that in a bit.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag


    In other words: I like @'flmaxey''s idea of uploading OMV_3_0_99_RaspberryPi_2_3_4.9.80.img.xz again and putting it in an 'unsupported' subdir in the RPi directory even if it's pointless.

    Again, with the appropriate "read me" file - I.E. "doesn't work with an R-PI 3B+", "unmaintained/outdated packages may result in broken plugin's", "do not execute omv-release-upgrade ":


    The user could make the call appropriate for their purpose, "even if it's pointless".

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!