Still the analogy is similar.
My wife has no complaints because I'm not a couch potato. I do get things done, but she's not the dictator of my schedule.
We collaborate on what goes into the garden, with kind conversation, but not the schedule, methods, and labor to enclose it.
As noted before; this is how it is.
I really missed the way you totally miss my point but suddenly change the subject in discussions and then think that this would support your point of view.
Yes, the analogy is similar. Yes, it is how it is. You are a friend of messages with an information entropy H=0 and now we know that your wife is ok with that. Good for you! She is very patient with you.
But that has nothing to do with my criticism, unfortunately.
... But that has nothing to do with my criticism, unfortunately.
I am not sure what the basis of your "criticism" is? Why did you feel a schedule was needed?
My suspicion is that OMV5 was released now because of three factors:
1. Debian 9 will be EOL soon. It would be nice to have a version of OMV that relies on Debian 10 before that happens.
2. The /sharedfolders feature was recently disabled by default. I understand that significantly improved the performance of OMV when applying new settings. And this was a remaining obstacle.
3. OMV5 was ready.
So it was a combination of a removed obstacle and an approaching cliff edge that made the release happen now.
But this is just a guess from me.
I wouldn't mind to keep using OMV4 indefinitely.
But OMV4 will become EOL and force me to upgrade. If not for any other reason, because Debian 9 becomes EOL, probably later this year.
And I understand the need for improving and updating OMV in order to keep it a modern NAS platform.
2. The /sharedfolders feature was recently disabled by default. I understand that significantly improved the performance of OMV when applying new settings. And this was a remaining obstacle.
What you mean? Probably dumb question. I still seee the /sharedfolder dir in OMV5. You mean the use of the word sharefolders when pointing to a path?
See the release notes. This is also discussed in other threads. The folder is there, but by default it is not used.
Adoby I really do not know what you are talking about. I never said anything about a schedule and I never thought about anything like that.
I explained very specifically what I personally did not like in the devs communication on stable status. This is an opinion and I do not claim that everyone agrees with me. If you disagree, fine. But I am not in the mood for the next discussion about someones interpreting things in my posts that are simply not there.
probably the issue here is that OMV has a horrible versioning logic which is basically something like <debian.version - 5>.<debian.minor.version>.<omv.buildnumber> causing a lot of confusion.
actually you could consider the the releases up to 5.3 as beta versions and the releases in the 5.3 branch as release candidates where anytime when votdev decides that the amount of identified bugs is lower than his mental threshold he'd mark the latest release as stable. (btw. he didn't actually do that, because 5.3.9 is still marked as unstable in the changelog https://github.com/openmediava…diavault/debian/changelog)
Dear Team!
I install the omw 5 and when I start to set the ethernet I receive the below error message please help me. Thx
"Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; omv-salt deploy run systemd-networkd 2>&1' with exit code '1': /usr/lib/python3/dist-packages/salt/utils/path.py:265: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working if not isinstance(exes, collections.Iterable): raspberrypi: ---------- ID: configure_etc_network_interfaces Function: file.managed Name: /etc/network/interfaces Result: True Comment: File /etc/network/interfaces updated Started: 09:09:44.544397 Duration: 148.537 ms Changes: ---------- diff: --- +++ @@ -1,7 +1,8 @@ +# This file is auto-generated by openmediavault (https://www.openmediavault.org) +# WARNING: Do not edit this file, your changes will get lost. + # interfaces(5) file used by ifup(8) and ifdown(8) - -# Please note that this file is written to be used with dhcpcd -# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf' +# Better use netplan.io or systemd-networkd to configure additional interface stanzas. # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d ---------- ID: remove_systemd_networkd_config_files Function: module.run Result: True Comment: file.find: [] Started: 09:09:44.695695 Duration: 3.944 ms Changes: ---------- file.find: ---------- ID: remove_netplan_config_files Function: module.run Result: True Comment: file.find: ['/etc/netplan/10-openmediavault-default.yaml', '/etc/netplan/20-openmediavault-eth0.yaml'] Started: 09:09:44.700189 Duration: 4.496 ms Changes: ---------- file.find: - /etc/netplan/10-openmediavault-default.yaml - /etc/netplan/20-openmediavault-eth0.yaml ---------- ID: configure_netplan_default Function: file.managed Name: /etc/netplan/10-openmediavault-default.yaml Result: True Comment: File /etc/netplan/10-openmediavault-default.yaml updated Started: 09:09:44.705249 Duration: 42.891 ms Changes: ---------- diff: New file mode: 0644 ---------- ID: configure_netplan_ethernet_eth0 Function: file.managed Name: /etc/netplan/20-openmediavault-eth0.yaml Result: True Comment: File /etc/netplan/20-openmediavault-eth0.yaml updated Started: 09:09:44.748759 Duration: 142.424 ms Changes: ---------- diff: New file mode: 0644 ---------- ID: apply_netplan_config Function: cmd.run Name: netplan apply Result: False Comment: Command "netplan apply" run Started: 09:09:44.895424 Duration: 608.198 ms Changes: ---------- pid: 2294 retcode: 1 stderr: Traceback (most recent call last): File "/usr/sbin/netplan", line 23, in <module> netplan.main() File "/usr/share/netplan/netplan/cli/core.py", line 50, in main self.run_command() File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command self.func() File "/usr/share/netplan/netplan/cli/commands/apply.py", line 43, in run self.run_command() File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command self.func() File "/usr/share/netplan/netplan/cli/commands/apply.py", line 93, in command_apply stderr=subprocess.DEVNULL) File "/usr/lib/python3.7/subprocess.py", line 347, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/lo']' returned non-zero exit status 1. stdout: Summary for raspberrypi ------------ Succeeded: 5 (changed=6) Failed: 1 ------------ Total states run: 6 Total run time: 950.490 ms"
Jeronimo Take a look here RE: RPiv4 Network and Plugin Problem
probably the issue here is that OMV has a horrible versioning logic which is basically something like <debian.version - 5>.<debian.minor.version>.<omv.buildnumber> causing a lot of confusion.
OMV uses semantic versioning, this means the minor version is increased when API changes occur. OMV5 has now 4 API changes, thus it is 5.4.x
actually you could consider the the releases up to 5.3 as beta versions and the releases in the 5.3 branch as release candidates where anytime when votdev decides that the amount of identified bugs is lower than his mental threshold he'd mark the latest release as stable. (btw. he didn't actually do that, because 5.3.9 is still marked as unstable in the changelog https://github.com/openmediava…diavault/debian/changelog)
You're right, this is a mistake, the changelog should have been adapted and should use stable since the official release.
hello
thank you I try it but the same result 
Br Jero
i reinstall the omw 5 and do the scrip and now it is ok.. thx your help 
Here's the announcement.
Is this version the one finally defaulting to btrfs?
I really can't tell...
Thanks
Actually not we but just you.
There are good arguments for btrfs, and good arguments against it. One of the latter is that it requires you to think differently about your disk space, as seen here:
https://www.linuxquestions.org…-docker-btrfs-4175622037/
I'm all for new features. But things are a little different when you have a whole concept that you've worked with over decades turned on it's head, and forcing that concept on every user's machines.
There are good arguments for btrfs, and good arguments against it. One of the latter is that it requires you to think differently about your disk space, as seen here:
https://www.linuxquestions.org…-docker-btrfs-4175622037/
I'm all for new features. But things are a little different when you have a whole concept that you've worked with over decades turned on it's head, and forcing that concept on every user's machines.
Yeah I agree. Furthermore there are still some major issues. So I do understand that some people are critical of it. But under the condition that the major issues have been fixed by the release of omv 6, I do have a positive feeling about that.
By then bcachefs might be the new fabulous thing to try. Btrfs and ZFS old hat. 
By then bcachefs might be the new fabulous thing to try. Btrfs and ZFS old hat.
Imho Filesystems are like Whisky - they need to mature a decade or two before you can really enjoy them.
Then OMV6 should only be released when Debian11 is out?
Maybe it will be there soonTM
I really hope for that!
Please votdev, use this V6 step to finally align with the Debian release scheme! I like OMV very much but this version chaos between OMV and its underlying base totally sucks. I know that for some reason you don't like somewhat fixed release cycles but aligning with Debian totally makes sense. Please let me explain my idea:
Going align with debian takes pressure from you and the users.
I bet most of OMV users would be fine with waiting for new features (and stop asking for release dates) if its clear that OMV beta is based on debian testing and won't be released until its base gets stable.
But when Debian+OMV are finally released we have the perspective on having an up-to-date base combined with an up-to-date front end for roughly two years. When it comes to peoples' data, long-term-stability is more important for most of them than having the newest features available instantly.
If you decide to release OMV6 based on Debian 10 (before Debian 11 getting stable) users have to stay with Debian 10 oldstable again until OMV7 is done. Debian 11 is expected to be stable in mid of 2021. In my impression such a more or less 2-year release schedule would fit the needs of most of us. So please consider my arguments when you have to decide for a direction.
Aside from that thanks for this nice release. Runs good so far. 
...use this V6 step to finally align with the Debian release scheme! I like OMV very much but this version chaos between OMV and its underlying base totally sucks.
I'm not a Dev but,, I believe I understand the reason(s) why OMV does not come out of Beta until well after a Debian release is out of Beta. (At least I think I do...)
Developers start with and build on a foundation - in this case the Debian distribution. The distribution must be stable. Otherwise, building the OMV app is a lot like trying to build a house on a shifting foundation. It stands to reason that after the foundation is finished (Debian), the house (the app) can be finished. One follows the other. It doesn't work very well the other way around.
to finally align with the Debian release scheme!
i think OMV has been always aligned with the Debian release scheme. each OMV version came out with a new debian release.
But when Debian+OMV are finally released we have the perspective on having an up-to-date base
Debian has never been up-to-date and never will be. The up-to-date linux distro is Arch
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
