That kernel was just released two days ago. So, probably not many people running it yet. Upgrading my system now and trying the 2020-05-27 raspbian buster lite image now.
Posts by ryecoaaron
-
-
try: omv-aptclean
If you still get an error, there is an issue with the repo.
-
eth0.yaml should be deleted. I'm curious what created it though.
-
This problem was fixed here - https://github.com/openmediava…8f16244e87e18d0a7180e2cc8 and here - https://github.com/OpenMediaVa…ba1199b79c0b1c416200fa7a1
Is there possibly an issue with the base install of OMV5?
It was an issue with some Debian installs (nothing OMV can fix) and some Armbian installs
-
OMV install requires some tweaking due to path problems.
What tweaks?
Don't pick Apache during Debian install.
Correct. You should actually pick as minimal as possible.
-
shellinabox should have been uninstalled by the script. Need more output to know what went wrong.
-
Would be good for people running lots of dockers or even VMs too.
-
I can't suggest an ftp server since I don't use ftp, I will tell you that you should use docker. The openmediavault package itself depends on proftpd. And as you found, if you try to install any other ftp server, it will conflict with proftpd and want to remove openmediavault.
-
You can't pick which which hours it runs. If the Hours field is greater than 0, it will run every hour and keep the last x (number in Hours field) backups.
-
Finally installed Mint LDME (based on Debian buster) in non EFI way, and then OMV on top. In this case some tweaking with apt sources list is needed - replacing debby with buster for omv extras. So far works without issue.
Just for others who try to use this, this is not supported (LMDE is "based" on Debian 10 but is not Debian 10) and omv-extras will keep reverting your change (as mentioned in the email). Did you ever try Debian 10?
-
If it's not a common problem on RPi then i'm fine with current implementation. But why isn't it possible to get the MAC address for the iface in this case?
I tried on an existing RPi2 install and had no problems. I tried on a new RPi4 install and had no problems. I tried wifi and vlan (OP had a VLAN) on the RPi4 but still had no problems. I can't figure out why the salt code can't get the mac address but it has happened on a few systems. I just can't replicate it.
-
If you set OMV_RSNAPSHOT_STARTING_HOUR in /etc/default/openmediavault, the plugin will use that as a starting hour.
-
Maybe. I haven't tried but I also haven't had this issue on my many RPi tests.
-
Not sure what you are asking but if you are manually changing the time the snapshots run, that is only able to be changed in the OMV 5.x version of the plugin.
-
IMO it seems to be inevitable to use predictable network device names on RPi.
I stopped disabling predictive naming in the install script about a week ago - https://github.com/OpenMediaVa…c3e3c9d7ef68b89523eff1987
Looking at the mac address stuff now though. I *really* don't want to have to switch to predictive naming though. I don't mind using whatever comes configured but switching would realistically require a reboot.
-
try omv-aptclean or the apt clean button in omv-extras.
-
Reinstalled debian from scratch twice with same problem
I think this is the repo you are using. The linux-image-amd64 might not be pointing at the 5.5.0-0.bpo.2 package yet. I just installed debian 10 and it worked fine.
-
Post the output of:
sudo salt-call grains.get oscodename
-
Enable ntp. Your system time is most likely wrong.
-
I get an error:
I'm guessing you had an error in the omv-salt command. You should post the output of the following:
sudo omv-salt deploy run apt
sudo salt-call grains.get oscodename
