No idea what is causing this. What is the output of: time sudo /usr/bin/salt-call -l debug --local saltutil.sync_grains
Apply changes in GUI takes a very long time.
-
-
What is the output of: time sudo /usr/bin/salt-call -l debug --local saltutil.sync_grains
See attached time.txt
Ran the above, run time = 1:25 minutes, same as real in text file.
I hope there are some clues.
-
No idea what is causing this.
I think I've isolated the problem to being a docker container.
Tried the old "Get back to basics", stopped all docker containers and rebooted omv, and Apply changes completes in just several seconds now.
Now it's trial and error method to start each container one at a time to see which container causes the omv Apply changes issue.
But
18 updates appeared in omv, so I thought do the updates, get that out of the way (a kvm plugin update was amongst the list of updates).
Rebooted, just to make sure all was running ok in the server.
Noticed the kvm plugin missing from omv Services list, hmm, try installing the plugin again.
When selecting openmediavault-kvm 6.1.23 in System, Plugins and install, I now get an error ending in "you have held broken packages".
Full error message in attached kvm-plugin-install-error.txt
Where do I go from here?
Might I have endd up with a rogue process from a docker container?
Nearly at the end of the line for omv and me...
-
Where do I go from here?
Might I have endd up with a rogue process from a docker container?
I don't think a container would cause a problem unless it was blocking a port of something in OMV. What containers are you running?
Your output looks like backports are disabled. Shouldn't be hard to fix.
Nearly at the end of the line for omv and me...
We can get your system fixed. No need to give up : )
-
Full error message in attached kvm-plugin-install-error.txt
The Debian backports repos had some packages removed. That is causing this problem. hopefully they are replaced.
-
I don't think a container would cause a problem unless it was blocking a port of something in OMV. What containers are you running?
Your output looks like backports are disabled. Shouldn't be hard to fix.I'm only going on anecdotal evidence, it's all I got at present. The list of containers, of what was running during the "Apply changes" issue is below;
media servers, plex, jellyfin (plex still running now with no problems, jellyfin is not starting for some reason, another thing to fix!)
netdata, server monitoring dashboard (still running now with no problems)
guacamole, made up of guacamole/guacamole, guacamole/guacd & guaca-mysql (still running now with no problems)
dozzle, real time docker container log file viewer (still running now with no problems)
various rclone browser containers being tested (none were running during the issue) (shutdown at present)
speedtest, hourly internet speed test (shutdown at present)
adguardhome, running a macvlan, used as the dns server for lan (running during issue, shutdown at present)
nagios, server log viewer (not running during the issue, shutdown at present)
watchyourlan, compiles a list of devices on lan (may have been running during issue, shutdown at present)
I think the most likely container is adguardhome (and this is my most important one, dns blocking/filtering and device blocking)
omv, System, omv-extras, Settings, Testing repo disabled, Backports enabled
omv, System, Update Management, Settings, Pre-release updates disabled, Community-maintained updates enabled
The Debian backports repos had some packages removed. That is causing this problem. hopefully they are replaced.
Is this a wait and see what happens thing? No kvm plugin until this is resolved?
Want to do the zerotier thing again?
-
Is this a wait and see what happens thing? No kvm plugin until this is resolved?
Want to do the zerotier thing again?Yep, we wait until debian fixes the repo. I can't even get it installed on my system yet.
-
I was ready to lose network again like all previous attempt, but the apply update not only took very little time, but I didn’t lose any network connection and my dirty modules.json is now empty.
So, problem solved? I’m not sure since I didn’t do any changes except doing some updates in the past days.
I think your system only has problems when the network module is dirty and runs the saltstack code for it. So, if you don't change any network settings and nothing else marks the network module as dirty, you probably won't see the problem.
-
No kvm plugin until this is resolved?
I have a working solution until the debian repos are fixed. If you have a working system but can't update, I wouldn't install this. RE: KVM plugin problem after update
-
have a working system
omv6 is working at present, as for updates, none are showing to know if updating works, should there be any updates available?
The Save and Apply changes in the web ui issue is not happening at present.
I have all of the usual containers up and running at present, without issue.
The only thing that is not configured yet is the Adguardhome instance is not being used as the dns server.
All appears working ok.
Today I'll do the testing of the Adguardhome instance being used as the dns server.
-
I think your system only has problems when the network module is dirty and runs the saltstack code for it. So, if you don't change any network settings and nothing else marks the network module as dirty, you probably won't see the problem.
Ok. Let's see how it goes and what happens when I will be able to purge isc-dhscp-client.
I'll let you know
-
Ok. Let's see how it goes and what happens when I will be able to purge isc-dhscp-client.
I'll let you know
ok. today I managed to update openmediavault package in order to purge isc-dhcp-client.
I did an omv-update from CLI and the terminal remained for a *lot* at the point where it was saying "Setting up salt environment..."
In another terminal I did a ps aux |grep salt and I got this process that was started 13 minutes before.
Code/usr/bin/python3 /usr/bin/salt-call --local --retcode-passthrough --no-color state.orchestrate omv.stage.prepareThe process eventually ended without errors.
I even managed to purge isc-dhcp-client.
If I check dirtymodules though I get this:
Coderoot@omv:~# cat /var/lib/openmediavault/dirtymodules.json [ "avahi", "fstab", "monit" ]So I checked in the GUI and there where some pending changes.
I applied them and in a bit the process ended and now my dirtymodules.json is empty.
-
None of that surprises me. How long did it take to apply changes on that last step once isc-dhcp-client was removed? Did you reboot after removing the client?
-
None of that surprises me. How long did it take to apply changes on that last step once isc-dhcp-client was removed? Did you reboot after removing the client?
It took very little (not measured).
I haven't rebooted yet.
-
I'm having this same issue, but it seems to be isolate to mounting and unmounting filesystems.
-
I'm sorry to add something to a thread this old, but applying changes, from the GUI
What kind of system and what kind of storage is the OS on?
from the cli with omv-upgrade command still take a *LOT* of time (like half an hour or so)
omv-upgrade is literally just apt-get commands. If it is slow, you either have a lot of updates or your system is very, very slow. I just updated one of my RPi4 that I forgot about. So, it hadn't been updated for 3 months. It took 5 mins at most to update including a kernel update.
-
I'm sorry to add something to a thread this old, but applying changes, from the GUI or from the cli with omv-upgrade command still take a *LOT* of time (like half an hour or so). I'm open to try something to debug what's going on on my system or to open a new thread if it's better.
Thanks.
On my AMD Athlon(tm) II X2 240e a kernel update might take 10-15 minutes. Keep in mind that depending on your system it might happen that various kernel modules are rebuild via DKMS.
Deploying the service configuration via SaltStack hast been increased by fixing DNS issues. Before that fetching the grains data took ages.
-
What kind of system and what kind of storage is the OS on?
omv-upgrade is literally just apt-get commands. If it is slow, you either have a lot of updates or your system is very, very slow. I just updated one of my RPi4 that I forgot about. So, it hadn't been updated for 3 months. It took 5 mins at most to update including a kernel update.
My system is on a Xeon processor, 32 Gb RAM and a ssd disk.
It's not apt commands or kernel module building that are very slow, but the various salt command at the end of the update process.
To be clearer, it's when I have the "Pending changes" notification in the GUI or, when I use the cli, the various salt passages after the packages are installed.
This morning I had two packages to be installed (openmediavault and openmediavault-nut).
I edited /etc/salt/minion file and I added debug log.
I also added another option that helped when I had the same problem in the past which is
Codeenable_fqdns_grains: FalseThis time the update took a reasonable amount of time (under a minute).
Code# time omv-upgrade real 0m54.915s user 0m21.385s sys 0m5.316sthanks.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!