Moin, On Sun, 31 Jan 2016, 02:07:32 +0100, Christian Boltz wrote:
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 ;-)
Yeah, that's why I never thought to open a bug report for this.
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.
The "depmod ...; rpm --rebuilddb; ..." sequence actually is a result from finding some arbitrary command that does something sensible and creates enough noise in the system so that "zypper ..." succeeds afterwards. FWIW, "rpm --rebuilddb" does not need to be executed to achieve the same effect.
_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?
/ xfs, /boot ext2, /var xfs
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 ;-)
Did most of it already, but again, rpm --rebuilddb is not _required_.
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.)
See above.
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.
Parts are automounted via NFSv4, but they are out of package scope, so no package installs stuff on the NFS mounted directories.
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 ;-)
The most different thing, I believe, is the mdraid10 setup with LVM on top. I'm not sure how many people are using such a setup, but I may be wrong. However, the rest is probably quite common, so I actually hoped to see someone else seeing the same issues, when Thomas sent his e-mail ;)
Regards,
Christian Boltz
Cheers. l8er manfred