I think it is a ridiculous request
Seriously? The guy you encourage to continue with his idiotic behavior already explained that my work is not worth being provided to the public: Raspberry pi 4 announced, better than 3?
I'm not sure why you blame the project for actions of people in a forum
Since that's the basic problem. A project that tolerates or even encourages total nonsense doesn't deserve further support. More details after you followed my request.
You even insisted and pushed ryecoarron to upload it
@ryecoaaron can you please immediately delete all the OMV images I provided from Sourceforge? That includes the two here and the 21 there. I don't want my work be associated with such a toxic/idiotic environment/project.
All the work I've done is in public repos  so the developers @crashtest will recruit have an easy start. I'm tired of dealing with this project and want my work removed. Thank you.
Before I joined this project there were 5 different SBC supported (without any optimizations) and you said yourself you prefer the way to choose an Armbian supported board where installing OMV is easy, right?
that means i will have to just wait for omv 5 and i can't expect anything from you that will curently work with the rpi 4??
Seems you listened too long to @crashtest right? Well, yeah all his babbling here is really damaging...
OMV4 works on the RPi 4, the image containing the needed adoptions is on Sourceforge: https://sourceforge.net/projec…/Raspberry%20Pi%20images/ (it's the one called 'OMV_4_Raspberry_Pi_2_3_3Plus_4.img.xz' of course, the other should be deleted and the readme.txt needs to be adopted of course).
As already said there's minor stuff that would need fixes but that's true for this image since I uploaded it a year ago (the 'new' image is exactly the same as the 'old' one, only two minor modifications wrt RPi 4 hardware support have happened). But such fixes won't happen since why should I contribute to a project in such a toxic/idiotic environment here?
what´s exactly the problem with crashtest?
His incompetence is a real problem paired with his feeling he should educate other users (by writing 'guides' being a compilation of his beliefs, establishing bad practices and polluting this forum and Github issues with nonsense). As often incompetent people don't realize how incompetent they are but it's important that they know since how could they improve otherwise?
The amount of insane BS originating from this single user was that immense that I dedicated some time trying to explain stuff to him over the last 2 years. Worked somehow in the beginning (a lot of complaining in the first place, then months later he adopted some knowledge) but this changed over time. He now outright refuses to learn while continuing to pollute this forum.
When a newbie reads through the forum he can come across complete and utter BS like short SMART selftests would test for surface errors, all this FUD about btrfs, a collection of weird stuff that would be needed to 'Connect to OMV SMB shares with Windows 10 and Microsoft Servers' from someone who doesn't even understand what a domain is and what's necessary for a host to join a domain. His 'guide' and 'advices' introduce more problems than they solve, for example there exists neither an excuse nor a reason to recommend 'guest logons' any more, and so on. He barely understands the meaning of the words he's throwing around and lacks especially any networking knowledge (while feeling he would know more than people who do this for a living since he's using Windows on his desktop machine).
Next annoying detail is methodology: OMV is based on Linux, for every problem someone runs into it's really easy to diagnose what's going on by optionally increasing the log level and looking into or providing the logs. This is important for us developers to nail problems down and it definitely doesn't help when people like him encourage users in threads to rebuild their whole system for no reason and to follow completely stupid trial&error tasks in 'wild guesses' mode instead of following an analytic approach working through potential problems from bottom to top.
How does this affect the development work? Well, it sucks. His lack of knowledge and methodology results in BS like this and that. Since he refuses to learn anything and as such also the difference between kernel and userland he doesn't understand the principles and challenges creating something like this but feels encouraged to spread concerns about the use of the RPi image. As such new users now think they would deal with new bugs while in reality nothing has changed with the RPi 4 image other than added hardware support as outlined several times. If users like @ManuelM now struggle with the image on their RPi 4 they struggle for exactly the same reason other RPi users did in the past: the necessary additional bits weren't installed on first boot.
To make things worse @crashtest in the meantime tries hard to agitate users and his mission is get me out of this forum (of course he's not able to distinguish between contributions to a project and writing forum posts). I feel ashamed reading all the FUD and BS that is spread here since so much is the absolute opposite of how things work in reality. But the worst part of the @crashtest problem is not his own incompetence but that he feels encouraged to continue with his idiotic behavior: refusing to learn, spreading BS, sabotaging development work.
I don't want to contribute any more to such a project that's tolerating or even encouraging such behavior, as such no more fixes for the various ARM images (RPi included) and no more knowledge contributions. No more feedback on 'TimeMachine with SMB' and the preparations for OMV5 images for ARM were sent to the bin (easing a lot of stuff e.g. using the same hostname 'omv5.local' on all images allowing people to overcome the stupid 'static IP address' madness).
Speaking about improvements. It doesn't help to improve software if then incompetent people who are stuck in last Century advocate anachronistic mechanisms via 'guides' and flooding the forum and try to convince users that stuff that works flawlessly would be a bad idea.
I lost too much time already and it simply makes no sense to continue 'against' retired guys armed with huge amounts of spare time ready to invest into idiotic games instead of improving their skills. @crashtest's latest mission is to get me out of here and eventually he succeeded. Now everybody can be happy again since nobody will comment any more on the flood of FUD and BS.
The power cable used could be 3 meters long. Also, the user clearly stated that it was working, it failed, and a reinstall didn't work
Total BS as usual.
- The RPi USB-C PSU has a fixed cable and the length is sufficient for no voltage drops to occur even at 3A (of course I tested this the day I got my RPi USB-C PSU several weeks ago)
- This new PSU has been bought later on
- The user was confused about missing HDMI output which is to be expected with the image since I created those images for RK3399 based FriendlyELEC boards when HDMI driver support was not ready. This is what I explained to the user above.
Your incompetence is frightening. It's both lack of knowledge and methodology which disqualifies everything originating from you.
Since I still believe in human beings being able to stop their idiotic behavior and being able to learn I explain the basics to you one last time (like I did it the last years over and over again): What you are referring too is a symptom. One userland tool called ls reports some error message in certain situations. We're talking about symptoms and quoting your very own link 'with this version I can no longer reproduce the "Too many symbolic links" error when I attempt to "ls" the ".zfs/snapshots" directory with an absolute path' -- with your limited understanding this would mean that this user now that he got rid of the confusing ls error message (the symptom) is using now a ZFS implementation where snapshots are not based on symbolic links any more.
Again: ZFS and btrfs do not use any sorts of links for their snapshots. It's one of the natural benefits of both being CoW filesystems.
Your incompetence is frightening. You spread BS all over the place and make this forum a mess. And the worst part: you don't even realize since you feel encouraged to continue with your idiotic behavior
Now head on to agitate further users via personal conversations... @blobblio have fun with this guy. Anyway: your 'issue with ZFS' isn't one as outlined above. Listen to the advice you got from @subzero79 (who as any other one right in his mind avoids threads once 'team incompetence' arrived)
It seems that the OMV image doesn't allow ssh out of the box
The readme.txt at download location still fully applies: https://sourceforge.net/projec…ngle%20Board%20Computers/
under-voltage shouldn't be an issue, though still can be if the image overclocks out of the box
If you use the official RPi USB-C PSU this can't be an issue. At least without any USB drives connected at install time. You can simply access the web interface by using the board's name: http://nanopim4 or http://nanopim4.local (the latter will work with every reasonable OS except Windows prior to Win10)
For me there where two bugs in this image: the virtual host config had a bad syntax and ntfs donßt work
There are certain problematic bits in this image I won't fix since too annoyed by several forum members but what you experience is what an awful lot of RPi users not able to follow the readme.txt at the download location also experience. The image needs working Internet access on first boot otherwise OMV installation will not be finalized. If users follow the readme everything works out of the box.
the original Pi image for 2 & 3 did mount ntfs drives
The new image is the same as before with just two minor bits adjusted (hardware support for RPi 4) as explained already several times. Unfortunately @crashtest loves to sabotage development work and spreads BS like the uploaded image would be 'BETA' (stupid emphasis by him) and problems would be to expected.
I get this two errors in the Raspberry Pi 4 image on sourceforge
There's nothing wrong with the image, you simply didn't follow the readme.txt at the download location. The image needs working Internet access on first boot otherwise OMV installation will not be finalized.
SMART attributes can increment with no user scheduled tests at all
Exactly. But the context was your wrong believe that a short test could help increasing these SMART values which is not the case:
I do a short test on all drives once a week, afterhours. I believe that's enough to increment the counts on the "maybe it's time to worry" SMART attributes
Again: for this only a long test is sufficient since it's about to tell the drive controller to scan/verify the whole drive surface.
Given the symbolic links that are used in snapshots, running a CoW filesystem inside of another CoW filesystem (which is snapshot capable) may be asking for trouble. There's a limit to the levels of symbolic links allowed, where a second set of symbolic links and deeply nested files may push beyond the limit
The usual insane @crashtest BS (as almost always unfortunately). You have not the slightest idea what you're babbling about. Snapshots in ZFS and btrfs are not based on 'symbolic links' but are a result of both filesystems being designed as CoW (copy on write). Most probably you confuse this with the way rsnapshot tries to implement snapshotting: here hardlinks are used regardless of the underlying filesystem (hardlinks, not 'symbolic links').
The first thing to note is that nesting one COW filesystem (BTRFS), inside another (ZFS) might work, but I have doubts
Why should doubts of someone who doesn't even understand the meaning of the words he's throwing around matter?
Performance would likely be poor,
Complete and utter BS as almost always. This 'thread' over there you polluted as @flmaxey with all your 'doubts' showed a simple performance comparison of ext4 vs. btrfs running off ZFS shared over NFS: https://github.com/openmediava…01#issuecomment-468270197
The 'ok-ish setup using SMB with 10GbE' shows 370/495 MB/s write/read for btrfs and only 290/475 MB/s for ext4 (over the network using SMB with storage from a ZFS filer exported via NFS).
and there's a limit to the level's of symlinks allowed, resulting from snapshots
BS. No symlinks involved with either ZFS or btrfs snapshots. When do you start to learn at least the basics instead of flooding this forum with idiotic theories (the result of lacking knowledge and methodology)?
My request is due to the fact that I would not use zfs because of the resources (1 GB of RAM for each TB of Hard Disk)
There is not such thing like '1 GB of RAM for each TB of Hard Disk'. That's an urban myth. You only need huge amounts of RAM with ZFS if you enable deduplication and have tons of files in your zpools.
This is one of our ZFS Linux filers with 16 x 6TB disks and 64GB RAM (dedup used):
RAM used with ZoL 0.7.5 is well below 40GB but 30GB of this are used for the ARC (adaptive replacement cache):Code
This install would happily run the almost 90T RAIDz3 with activated dedup and just 8GB of RAM.
And the amazing part of it is, while this is your thread, your issue won't even be considered and real help is unlikely to be offered
The usual @crashtest BS. You are still not able to realize how OMV defaults work. I addressed all the issues @jgbrock has in one post above and the BS you originate in another comment. But most probably now you're playing your usual idiotic games, started a personal conversation with the affected user trying to agitate him and so on. The usual sh*t show...
No HDMI output
If you do a simple web search for No HDMI output nanopi m4 you end up here: Nanopi M4 OMV HDMI not working -- no HDMI output is to be expected with the image, simply use it headless (and after applying all updates you get HDMI output).
With a good 3 Amp PS and a typical 1 meter USB cable (which has thin gauge wires), under-voltage messages are noted in dmesg
The usual @crashtest BS as almost always. The NanoPi M4 is not a Raspberry Pi and the thread starter already solved potential undervoltage issues by buying the RPi USB-C PSU.
Why didn't you just say "Can you upload this to SF?"
How could I ask you for anything? According to reason N°1 why I won't continue contributing to OMV I'm just some random forum user and not the creator and maintainer of the current RPi image. Also the image is 'BETA', everything is expected to be broken and OMV-Extras is not ready yet! It's not that I just carefully added the few bits to provide hardware support for the RPi 4 and a maintained kernel and everything else remains unchanged.
And since it is gone, I don't know what you want me to do
The disappeared image you looked at was the 1st try. The 2nd try this time adopting the appropriate APT pinning fixes and confirmed to work is still online (for whatever reasons, usually transfer.sh deletes them automagically after 14 days): https://transfer.sh/abKmQ/OMV_…rry_Pi_2_3_3Plus_4.img.xz
You keep saying your image is going away
Those transfer.sh links usually are only valid for 14 days. The first attempt to add RPi 4 hardware support is already gone: https://transfer.sh/wKK4S/OMV_…rry_Pi_2_3_3Plus_4.img.xz
Well, if you think throwing the work into the bin is the better idea compared to uploading it to SF...
Read what I said. I didn't say it had anything to do with OMV 5.x. I said I don't want to do it. I mentioned OMV 5.x because it is more important for me to spend my time on it and I don't even want to do that.
Sorry, English is not my mother tongue. Anyway this New approach for Raspberry Pi OMV images still applies.
By default, metadata will be mirrored across two devices and data will be striped across all of the devices present. This is equivalent to mkfs.btrfs -m raid1 -d raid0.
Nope, that's about btrfs behavior with multiple devices without RAID. I linked to https://github.com/openmediava…01#issuecomment-467000104 above for a reason. Since there everything is explained by a kernel developer in the link provided there: https://www.mail-archive.com/linux-<woltlab-metacode-marker data-name="email" data-uuid="5355616e-af83-44fa-972f-cf350f74d101" data-source="W2VtYWlsXQ==" data-attributes="WyJidHJmc0B2Z2VyLmtlcm5lbC5vcmciXQ==" data-use-text="0" /><woltlab-metacode-marker data-uuid="5355616e-af83-44fa-972f-cf350f74d101" data-source="Wy9lbWFpbF0=" />/msg79574.htmlCode
This is the link @crashtest should have read long ago since it would prevent him continuing with one of his moronic approaches to 'spread the news about btrfs'. He barely understands anything and feels encouraged to continue spreading BS.
I barely want to do anything with OMV 5.x stuff let alone more hacks specifically for the RPi
Final remark: This is not about OMV 5. This is about support for the existing OMV user base on any of the Raspberry Pi variants from 2 to 4.
So, let's outline what's necessary with OMV on the RPi. For any other developer willing to waste his time in this idiotic/toxic environment here this might save you at least some initial time...
Situation as follows:
- RPi Trading Ltd. switched their official support away from Debian Stretch to Debian Buster some weeks ago. This not only affects Raspbian users but also 'consumers' of their kernel like OMV. Our approach is to combine a rather clean upstream Debian armhf userland (created by the Armbian build system with some adoptions) with the kernel from archive.raspberrypi.org. While some people believe userland and kernel would be the same this is an important distinction. What was needed in the past (OMV3 still relying on Debian Jessie while RPi folks moved on to Stretch) is also needed now: APT pinning and of course updating ThreadX and kernel files on the FAT partition for an image that should work on RPi
- The size of the FAT partition is or might become an issue
- The recommended way to install an OMV5 beta on Debian/Raspbian Buster is currently broken (the warning message has been added to armbian-config but it seems the package hasn't been updated in the repo)
The 1st issue means that from now on OMV users on the RPi are cut off from kernel updates anyway so this switch by RPi people from Stretch to Buster does not only affect hardware compatibility with RPi 4 but all our users. Most probably the best way to fix this would be to ship with the APT pinning adoptions via an OMV Extras update. Once APT pinning is adjusted my OMV image can be updated and will then work flawlessly on any RPi 4 as well.