Hello, Am Samstag, 30. Januar 2016, 20:59:26 CET schrieb Manfred Hollstein:
On Sat, 30 Jan 2016, 17:18:55 +0100, Andrei Borzenkov wrote:
30.01.2016 16:53, Manfred Hollstein пишет:
Of course, you know better (as usual), but *why* does running the "depmod ..." command and _nothing else_ solve the issue then? Any constructive ideas?
Your command line included about dozen of different commands. So saying "depmod and nothing else" is simply wrong unless you can demonstrate that running depmod only does it.
Misunderstanding here! As I tried to indicate, I don't have a clear explanation, I just found out that in such situations, running _some_ commands like "depmod ... sync; sync" *always* solves the problem here.
What you see is more than strange - I'm not surprised that Jan's answer sounds like you told him that you see ghosts ;-) Actually, I'm also wondering why some unrelated commands solve the problem for you. Well, mostly unrelated - rpm --rebuilddb should in theory only put the RPM database in a cleaner shape, but it could also repair something. _If_ something is broken with the cache handling, another surprising part is that only you see it, and only when using zypper and not during normal usage of your systems. Do you have only local disks, or also NFS etc. mounts? When you hit the problem next time, can you please try some other methods? I'd suggest: - wait 5 minutes and try again - drop the cache: echo 1 > /proc/sys/vm/drop_caches (2 and 3 are also possible, see http://linux-mm.org/Drop_Caches) - run 'sync' and then drop the cache - try a different set of commands that cause traffic on the filesystem - especially avoid the rpm --rebuilddb - or _only_ use rpm --rebuilddb - if that helps, it would point to a problem in your RPM database I know this are quite some things to test - try one of them whenever you see the problem on one of your machines ;-)
In fact, every once in a while "zypper up" or "zypper dup" shows such behaviour, and I always _thought_ that it would be caused by some inconsistencies between rpm and zypper cache or whatsoever. Running _some_ commands which obviously have an influence on some caches always remove these conflicts, and these commands *never* installed/uninstalled any packages, it was just a matter of massaging the system internal buffers.
Which filesystem are you using? (The partition containing /var/ is most interesting since the RPM database and the zypper cache are on it.) I remember that I sometimes have strange effects with NFS - it can take some seconds until the client can see a file that was just created on the server. However I've never seen something like that on a local filesystem.
That's why I said there must be some interference between some layers... Because it's not predictable I never created a bugzilla for this, though... (But, as I wrote before, it's happening on all of my systems, so it's not some HW related problem)
What do your systems have in common? Ideally name something that most openSUSE users won't have or use ;-) Regards, Christian Boltz -- Unterdessen hat sich die Filmindustrie was ganz, ganz tolles ausgedacht: Ultraviolet (Man hätte einen beknackteren Namen finden können, aber das wäre Arbeit gewesen) ist DRM-as-a-service, 100% Buzzword Compliant und in der Cloud. [http://blog.koehntopp.de/archives/3068-Diesmal-also-eBooks-und-Filme.html] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org