Download old RP3 OMV images

    • Offizieller Beitrag

    C'mon. Spend yourself half an hour and write such a readme and chances are higher to convince @ryecoaaron to upload the old image again. None of the developers wants to waste time on preparing stuff for no reason.

    I spent 3 minutes on a readme - it wasn't a big deal. Doesn't the following cover the bulk of the "issues" ?

    "Doesn't work with an R-PI 3B+", "unmaintained/outdated packages may result in broken plugin's", "do not execute omv-release-upgrade "
    , "USE AT YOUR OWN RISK".



    See the attached readme.txt If there's more, I'll happily translate it into "NOOB'ish".


    Otherwise, I'll assume that experienced users and developers will "get it" from the proposed directory name "Unsupported - Obsolete".
    ___________________________________


    I am drawing from this event to update a tutorial. The main gist of that will be: "if you have something that works well, are supporting a critical function, or are using specialty hardware "Clone/Backup your OS while you can".

    • Offizieller Beitrag

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

    I really wish it worked that way. There are always people who don’t want to change and still ask for updates and/or ask how to fix something. The RPi1-compatible image was that way for a long time. If the user was making an appropriate call, they wouldn’t be using an RPi :D

    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

    I really wish it worked that way. There are always people who don’t want to change and still ask for updates and/or ask how to fix something. The RPi1-compatible image was that way for a long time. If the user was making an appropriate call, they wouldn’t be using an RPi :D

    Well, I wouldn't make a decision based on a handful of unreasonable users. They'll be there regardless of the platform supported. On the other hand, even being the slow performer that it is, the R-PI attracts more new users to OMV than all other SBC's combined. While that may be due to pure marketing hype, it is what it is.


    In any case, given that OMV/SBC support seems to be "experimental", at best, perhaps support for SBC's should be abandoned in future OMV versions. Looking at them for what they are; for fixed functions as a home alarm system, or in low use computing environments, SBC's can be useful. But, really, most of them are nothing more than specialty toy hardware.


    Wrong. OMFG, why is everything related to RPi such a mess? I disable notifications for this thread now and try to forget about these crappy Raspberries and the surroundings...

    Thank you so much. I would suggest that you take this exact approach MUCH MORE OFTEN. :)

    • Offizieller Beitrag

    I wouldn't make a decision based on a handful of unreasonable users. They'll be there regardless of the platform supported. On the other hand, even being the slow performer that it is, the R-PI attracts more new users to OMV than all other SBC's combined. While that may be due to pure marketing hype, it is what it is.

    RPi images aren't being removed so I don't think there is any problem removing older images. I actually think it would cause more problems if there wasn't an image with the latest version available.


    In any case, given that OMV/SBC support seems to be "experimental", at best, perhaps support for SBC's should be abandoned in future OMV versions. Looking at them for what they are; for fixed functions as a home alarm system, or in low use computing environments, SBC's can be useful. But, really, most of them are nothing more than specialty toy hardware.

    I don't think the images are experimental and most of the newer boards with real gigabit (renegade for instance) are extremely fast and stable (from my testing). I think they might be just as stable or better than some of the cheap desktop motherboards people are using as an NAS.

    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

    I don't think the images are experimental and most of the newer boards with real gigabit (renegade for instance) are extremely fast and stable (from my testing). I think they might be just as stable or better than some of the cheap desktop motherboards people are using as an NAS.

    I can believe that but, as is evident by the download numbers on source forge, there just doesn't seem to much user interest in (or a decent marketing campaign for) the higher performing SBC's. It really doesn't matter how good they are, if they're not used. And given the shear number of SBC's out there, there's very little to no chance that any one of them will come to the forefront and actually compete with the technically inferior R-PI.


    And where the R-PI is concerned, there's also the question of unnecessary forum/support drama that never ceases. I mean, it's almost pathological in nature. No one gets a breather, it's been going on for years and there's no end in sight. As it stands, right now, I believe this forum could be a heck of a lot more user friendly without the R-PI and its' pundit.


    So, with the time of all concerned factored in, the question to asked is - is it worth it? For the previously mentioned reasons, dropping the R-PI seems like a reasonable course to take. But you're the developer so the question, "to Pi or not to Pi", is left with you.

    • Offizieller Beitrag

    Wrong. OMFG, why is everything related to RPi such a mess? I disable notifications for this thread now and try to forget about these crappy Raspberries and the surroundings...

    So you didn't actually disable notifications... This is, like, the 3rd time I'm aware of where you've feigned outrage, saying you were dropping out of a thread, and jumped right back in it. Does your word mean anything? (And you talk about me, spreading BS... :) )


    As you may have noticed, I was having a conversation with a developer @ryecoaaron (who doesn't fixate on a single word), about subjects and factors you haven't grasped.
    So, I'll be a bit more specific in the event that the gist of the last post or two was missed; I'd be in favor of dropping support for the R-PI altogether, if it would put an end to the "tkaiser/R-PI side show".


    This forum's experienced users have heard your R-PI rants, to lengths "ad nauseam", and new users who happen into the forum for the first time don't understand your nature. Of the new users who do a bit of reading first, I believe some of them simply go away, without ever posting.


    As for the rest of SBC's as a group, the numbers speak for themselves. And since it seems there may be a bit of "voluntary selective blindness" involved, I'll re-quote:

    I can believe that but, as is evident by the download numbers on source forge, there just doesn't seem to much user interest in (or a decent marketing campaign for) the higher performing SBC's. It really doesn't matter how good they are, if they're not used. And given the shear number of SBC's out there, there's very little to no chance that any one of them will come to the forefront and actually compete with the technically inferior R-PI.

    Since we're parsing single words, perhaps I should have been a bit more specific and said: It really doesn't matter how good they are, if they're not widely used. But, to be objective, let's look at the numbers. In the following, the red box makes up the totals for 18 different SBC models. Maybe there's a message in there somewhere.


    • Offizieller Beitrag

    please keep it intact

    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

    To come back again.


    If above proposed download is not OK, then maybe another permanent one with the remark that OMV 3 for Raspberry PI is EOL, however Debian Jessie still has LTS until June 2020 and is still getting OS updates.

    I understand that Debian Jessie is still supported but ideally, everyone should move to OMV 4.x. I was asking why you want to stay on OMV 3.x. It definitely makes it easier to support if everyone is on the same version of OMV.

    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!

  • It definitely makes it easier to support if everyone is on the same version of OMV


    Adding to that the OMV version for Raspberries always has been special since we need to cope with RPi Trading folks weirdness.


    The RPi people stopped for no real reason providing kernel updates for their users still running Jessie (only their Stretch users got newer kernel updates starting from July 2017 or around that). So @carriba while correctly stating


    however Debian Jessie still has LTS until June 2020 and is still getting OS updates

    is missing that the kernel needs also security fixes. Jessie on Raspberry Pi systems and Jessie in general on arm64 is not covered by security fixes any more (Jessie LTS is only available for x86 and armhf).


    In OMV we tried to fix RPi people's behaviour with apt pinning so while OMV 3 might be the only RPi based Jessie distro still getting kernel upgrades from official raspberrypi.org repos this causes other problems especially once the OMV3 installation will be upgraded to OMV4.


    Summarizing: it's wrong to provide the old OMV3 image so that's a 404 now: kaiser-edv.de/tmp/jk4NM5/OMV_3…berryPi_2_3_4.9.80.img.xz (people who know what they do and how the Internet works are able to access it anyway. Hint: I use archive.org for most of my stuff)


    Edit: haha, better idea:

    Code
    ln -s OMV_4_Raspberry_Pi_2_3_3Plus.img.xz OMV_3_0_99_RaspberryPi_2_3_4.9.80.img.xz
  • Hi all,


    The link provide above for OMV3 is actually OMV4??


    When i run the image it come up with version 4.1.8?


    Anyone have an old OMV3 image i can use? in the same boat as original thread post.


    Thanks!

Jetzt mitmachen!

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