[opensuse] What is this problem and how to solve it?
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2. I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle. When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png. Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png. I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped. Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem? BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass
On 01/30/2019 11:15 PM, Basil Chupin wrote:
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2.
I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle.
When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png.
Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png.
I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped.
Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem?
BC
This is more a calculated guess than a silver bullet, but it looks like the 4.20.5 kernel (brand new) is not playing well with the 20181218 kernel-firmware patch. I do know I got new firmware with 4.20.5 on Arch, so I suspect the same would be needed with openSuSE. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/1/19 4:30 pm, David C. Rankin wrote:
On 01/30/2019 11:15 PM, Basil Chupin wrote:
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2.
I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle.
When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png.
Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png.
I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped.
Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem?
BC
This is more a calculated guess than a silver bullet, but it looks like the 4.20.5 kernel (brand new) is not playing well with the 20181218 kernel-firmware patch. I do know I got new firmware with 4.20.5 on Arch, so I suspect the same would be needed with openSuSE.
Thanks for the response, David. As I mentioned, I had no problems updating my Leap 15.0 system (and now have kernel-firmware 20181218-36.1 installed). One of the differences between my system and my wife's is that mine is an AMD system while hers is an Intel system. (Well, there are also other hardware differences :-).) BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/01/2019 06.30, David C. Rankin wrote:
On 01/30/2019 11:15 PM, Basil Chupin wrote:
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2.
I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle.
When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png.
Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png.
Do "dmesg" just after the error. There should be an entry in the last line about the segmentation fault. Or just peruse the log now and search back for it (word "segmentation" or perhaps "coredump").
I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped.
Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem?
I would try "rpmdb --rebuilddb".
This is more a calculated guess than a silver bullet, but it looks like the 4.20.5 kernel (brand new) is not playing well with the 20181218 kernel-firmware patch. I do know I got new firmware with 4.20.5 on Arch, so I suspect the same would be needed with openSuSE.
From a recent thread in factory mail list, I understand it is better to try the tumbleweed kernel. I can search the explanation if you want. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 31/1/19 9:04 pm, Carlos E. R. wrote:
On 01/30/2019 11:15 PM, Basil Chupin wrote:
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2.
I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle.
When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png.
Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png. Do "dmesg" just after the error. There should be an entry in the last
On 31/01/2019 06.30, David C. Rankin wrote: line about the segmentation fault.
Or just peruse the log now and search back for it (word "segmentation" or perhaps "coredump").
I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped.
Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem? I would try "rpmdb --rebuilddb".
This is more a calculated guess than a silver bullet, but it looks like the 4.20.5 kernel (brand new) is not playing well with the 20181218 kernel-firmware patch. I do know I got new firmware with 4.20.5 on Arch, so I suspect the same would be needed with openSuSE. From a recent thread in factory mail list, I understand it is better to try the tumbleweed kernel. I can search the explanation if you want.
(Just had a break for dinner...) Thanks, Carlos, I'll do what you suggest above tomorrow and see what the log states re the seg. fault. Re the TW kernel, I would be grateful if you could find that post in factory. BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/02/2019 08.58, Basil Chupin wrote:
On 31/1/19 9:04 pm, Carlos E. R. wrote:
On 01/30/2019 11:15 PM, Basil Chupin wrote:
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2.
I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle.
When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png.
Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png. Do "dmesg" just after the error. There should be an entry in the last
On 31/01/2019 06.30, David C. Rankin wrote: line about the segmentation fault.
Or just peruse the log now and search back for it (word "segmentation" or perhaps "coredump").
I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped.
Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem? I would try "rpmdb --rebuilddb".
This is more a calculated guess than a silver bullet, but it looks like the 4.20.5 kernel (brand new) is not playing well with the 20181218 kernel-firmware patch. I do know I got new firmware with 4.20.5 on Arch, so I suspect the same would be needed with openSuSE. From a recent thread in factory mail list, I understand it is better to try the tumbleweed kernel. I can search the explanation if you want.
(Just had a break for dinner...)
Thanks, Carlos, I'll do what you suggest above tomorrow and see what the log states re the seg. fault.
I'm interested if you can find out if the command "rpmdb --rebuilddb" works. I think it doesn't, but now I have my doubts. So please try that one first, and if it says "unknown option" try "rpmdb --rebuilddb" instead ;-)
Re the TW kernel, I would be grateful if you could find that post in factory.
+++................. Date: Thu, 17 Jan 2019 10:10:17 +0100 From: Takashi Iwai <...@suse.de> To: opensuse-factory@opensuse.org Subject: Re: TW kernel and Leap image (Re: [opensuse-factory] Leap 15.0 - Lots of troubles with old kernel in DVD image) On Wed, 16 Jan 2019 21:00:15 +0100, Takashi Iwai wrote:
On Wed, 16 Jan 2019 19:58:42 +0100, Takashi Iwai wrote:
2. Extend the current DVD ISO to allow to choose between current official kernel and this new 4.20 kernel. (I am no developer, I don't know how to do that).
This should be rather easy, and even doable with the current installer. In the online repo setup, you can add your own repo, and just put OBS Kernel:stable repo there. That's all.
BTW, the kernel in OBS Kernel:stable repo has one big disadvantage. It's not signed with the official openSUSE key, thus it won't boot with secure boot. OTOH, if we take the real TW kernel package, it should work with secure boot, too.
... and last but not least, another bigger disadvantage is the lack of KMPs. The extra kernel module packages provided for Leap 15.0 kernel won't be available for this one. If there are alternative ones for TW, we can take them, though. Also, the Nvidia KMP build is often broken with each kernel version update. It'd be another reason to stick with TW kernel, not the bleeding edge one in OBS Kernel:stable. Takashi .................++- There you have. I pasted it because it is in my archive of important messages re kernel. To post a link I would have to find it first ;-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/2/19 10:11 pm, Carlos E. R. wrote:
On 01/02/2019 08.58, Basil Chupin wrote:
On 31/1/19 9:04 pm, Carlos E. R. wrote:
On 01/30/2019 11:15 PM, Basil Chupin wrote:
I am trying to update my wife's Leap 15.0 system and get this error when using either zypper or Yast2.
I am using the kernel from the ../Kernel:/stable/standard/ repository on my Leap 15.0 as well as hers but I am not having this hassle.
When using zypper to update I get this error msg (pls see attached zypper_error-31.png) and when using Yast I get the error msg in the attached Yast_error-31.png.
Yesterday when I tried to do same, the 'zypper up' got a lot further in the installation - pls see attached zypper_error.png. Do "dmesg" just after the error. There should be an entry in the last
On 31/01/2019 06.30, David C. Rankin wrote: line about the segmentation fault.
Or just peruse the log now and search back for it (word "segmentation" or perhaps "coredump").
I have run 'zypper clean -a' and 'zypper refresh -fdb' but this hasn't helped.
Anyone please suggest what is causing this problem and how to how to get rid of the cause of this problem? I would try "rpmdb --rebuilddb".
This is more a calculated guess than a silver bullet, but it looks like the 4.20.5 kernel (brand new) is not playing well with the 20181218 kernel-firmware patch. I do know I got new firmware with 4.20.5 on Arch, so I suspect the same would be needed with openSuSE. From a recent thread in factory mail list, I understand it is better to try the tumbleweed kernel. I can search the explanation if you want.
(Just had a break for dinner...)
Thanks, Carlos, I'll do what you suggest above tomorrow and see what the log states re the seg. fault. I'm interested if you can find out if the command "rpmdb --rebuilddb" works. I think it doesn't, but now I have my doubts. So please try that one first, and if it says "unknown option" try "rpmdb --rebuilddb" instead ;-)
See my response to Felix -- the problem has been solved and I used 'rpm --rebuild'.
Re the TW kernel, I would be grateful if you could find that post in
factory. +++................. Date: Thu, 17 Jan 2019 10:10:17 +0100 From: Takashi Iwai <...@suse.de> To: opensuse-factory@opensuse.org Subject: Re: TW kernel and Leap image (Re: [opensuse-factory] Leap 15.0 - Lots of troubles with old kernel in DVD image)
On Wed, 16 Jan 2019 21:00:15 +0100,
Takashi Iwai wrote:
On Wed, 16 Jan 2019 19:58:42 +0100, Takashi Iwai wrote:
2. Extend the current DVD ISO to allow to choose between current official kernel and this new 4.20 kernel. (I am no developer, I don't know how to do that). This should be rather easy, and even doable with the current installer. In the online repo setup, you can add your own repo, and just put OBS Kernel:stable repo there. That's all. BTW, the kernel in OBS Kernel:stable repo has one big disadvantage. It's not signed with the official openSUSE key, thus it won't boot with secure boot. OTOH, if we take the real TW kernel package, it should work with secure boot, too. ... and last but not least, another bigger disadvantage is the lack of KMPs. The extra kernel module packages provided for Leap 15.0 kernel won't be available for this one. If there are alternative ones for TW, we can take them, though.
Also, the Nvidia KMP build is often broken with each kernel version update. It'd be another reason to stick with TW kernel, not the bleeding edge one in OBS Kernel:stable.
Takashi .................++-
There you have.
I pasted it because it is in my archive of important messages re kernel. To post a link I would have to find it first ;-)
Thanks for finding the thread. Fortunately I do not use UEFI (why is MS such a PITA? :-) ) but I am now prepared when I do have to <shudder> use UEFI which I fear I will be forced to do very shortly :-(. BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/02/2019 07.36, Basil Chupin wrote:
On 1/2/19 10:11 pm, Carlos E. R. wrote:
On 01/02/2019 08.58, Basil Chupin wrote:
I'm interested if you can find out if the command "rpmdb --rebuilddb" works. I think it doesn't, but now I have my doubts. So please try that one first, and if it says "unknown option" try "rpmdb --rebuilddb" instead ;-)
See my response to Felix -- the problem has been solved and I used 'rpm --rebuild'.
Ok!
Thanks for finding the thread. Fortunately I do not use UEFI (why is MS such a PITA? :-) ) but I am now prepared when I do have to <shudder> use UEFI which I fear I will be forced to do very shortly :-(.
UEFI is fine :-) You can boot any number of operating systems without using grub to choose them, for instance, all installed in a dozen primary partitions. Multibooting becomes easier. You only have to fight this or that operating system (guess which) fighting to be the master, as always. But undoing becomes easier, once you know how. UEFI was actually designed for multibooting, while BIOS was not and needed hacks. Of course, horrible implementations do exist. Don't confuse UEFI with protected boot, ie, needing a signed grub and a signed kernel to be able to boot. It is a feature of UEFI, yes, but can be disabled. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
What response do you get from trying zypper ref; zypper ve ??? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/1/19 5:36 pm, Felix Miata wrote:
What response do you get from trying
zypper ref; zypper ve
???
Hi Felix, Result: All repositories refreshed ... Dependencies of all installed packages are satisfied. BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin composed on 2019-01-31 17:56 (UTC+1100):
Felix Miata wrote:
What response do you get from trying
zypper ref; zypper ve
???
Result:
All repositories refreshed
...
Dependencies of all installed packages are satisfied.
If that's from the problem responsible for this thread, I have to think it was a transient mirror error, since corrected. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin composed on 2019-01-31 17:56 (UTC+1100):
Felix Miata wrote:
What response do you get from trying
zypper ref; zypper ve
???
Result:
All repositories refreshed
...
Dependencies of all installed packages are satisfied.
If that's from the PC responsible for this thread, I have to think it was a transient mirror error, since corrected. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/1/19 6:09 pm, Felix Miata wrote:
Basil Chupin composed on 2019-01-31 17:56 (UTC+1100):
Felix Miata wrote:
What response do you get from trying zypper ref; zypper ve ??? Result: All repositories refreshed ... Dependencies of all installed packages are satisfied. If that's from the PC responsible for this thread, I have to think it was a transient mirror error, since corrected.
Well, it happened yesterday and today, and I just tried doing the update again before posting this reply and I get the same error message from zypper (as per zypper_error-31.png). I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens. BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens.
I just did a 15.1. 3 errors, all my own doing, none involving zypper, yast or .png. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata composed on 2019-01-31 04:51 (UTC-0500):
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens.
I just did a 15.1. 3 errors, all my own doing, none involving zypper, yast or .png.
Oops. Replied too soon, forgot to reboot to new kernel before replying. New kernel gets about halfway through init, then nothing, only CAD works. Journal on subsequent boot to prior kernel claims prior boot reached default target. It looks like when it's supposed to switch video mode it goes into la-la land. Took out Radeon card, plugged VGA cable into onboard Intel, and it boots new kernel normally. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens.
You might want to hold off, or lock your existing initrds. Seems to be: http://bugzilla.opensuse.org/show_bug.cgi?id=1122456 -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/1/19 10:06 pm, Felix Miata wrote:
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens. You might want to hold off, or lock your existing initrds. Seems to be: http://bugzilla.opensuse.org/show_bug.cgi?id=1122456
I've looked at that bug report and it seems to me that it is concerned about the use of radeon versus nvidia graphic cards. Since I have never used radeon but only have nvidia cards I need to look elsewhere for the answer. BC PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database". Going from bad to worse :-). -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/02/2019 08.26, Basil Chupin wrote:
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-).
Did you run "rpm --rebuilddb" or "rpmdb --rebuilddb" yet? Please hurry: if that commands fails you only have 5 days for the alternative to work. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Fri, Feb 1, 2019 at 2:14 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 01/02/2019 08.26, Basil Chupin wrote:
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-).
Did you run "rpm --rebuilddb" or "rpmdb --rebuilddb" yet?
I had the same problem too on TW VM and ended up doing rebuilddb. It was sporadic, but running verification show errors in files other than Packages. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/02/2019 12.58, Andrei Borzenkov wrote:
On Fri, Feb 1, 2019 at 2:14 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 01/02/2019 08.26, Basil Chupin wrote:
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-).
Did you run "rpm --rebuilddb" or "rpmdb --rebuilddb" yet?
I had the same problem too on TW VM and ended up doing rebuilddb. It was sporadic, but running verification show errors in files other than Packages.
Did you find out if the command "rpm --rebuilddb" works, or only "rpmdb --rebuilddb"? I ask because I want to report man page error in bugzilla, but perhaps the page is correct. I hesitate to try "rpm --rebuilddb" on a healthy system. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Fri, Feb 1, 2019 at 3:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Did you find out if the command "rpm --rebuilddb" works, or only "rpmdb --rebuilddb"?
?? I do not remember what command I used.
I ask because I want to report man page error in bugzilla, but perhaps the page is correct.
I hesitate to try "rpm --rebuilddb" on a healthy system.
So install it in VM, it takes 15 minutes at most. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/02/2019 13.09, Andrei Borzenkov wrote:
On Fri, Feb 1, 2019 at 3:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Did you find out if the command "rpm --rebuilddb" works, or only "rpmdb --rebuilddb"?
?? I do not remember what command I used.
I ask because I want to report man page error in bugzilla, but perhaps the page is correct.
I hesitate to try "rpm --rebuilddb" on a healthy system.
So install it in VM, it takes 15 minutes at most.
My machine is RAM starving. 8 GiB of RAM, and 5 of used swap. I can fire up vbox, but it is slow. Rather close to an hour to create a new VM. Basically, I'm only using Thunderbird, Firefox and Libreoffice under XFCE. IMHO, openSUSE bloats. Other people say their systems do not suffer this way. Dunno. Thunderbird starts under a gig, but after some hours it grows to 1.6 gigs. Yes, I will use a virtual machine. Or create a temporary copy of the files and try the command. But I was hopping that someone that needed to run the command would say it ;-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 01/02/2019 13.21, Carlos E. R. wrote:
On 01/02/2019 13.09, Andrei Borzenkov wrote:
Or create a temporary copy of the files and try the command.
Ok, both commands run. Interestingly, the command deleted /var/lib/rpm (and my backups!) and created instead a symlink to ../../usr/lib/sysimage/rpm Found my backup in "/usr/lib/sysimage/rpmold.29244/copia". -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
01.02.2019 15:32, Carlos E. R. пишет:
On 01/02/2019 13.21, Carlos E. R. wrote:
On 01/02/2019 13.09, Andrei Borzenkov wrote:
Or create a temporary copy of the files and try the command.
Ok, both commands run.
--rebuilddb (and --inittdb) was provided by rpm in the past and was moved in separate rpmdb binary 8 years ago. "rpm --rebuilddb" is redirected to this binary via popt alias. bor@bor-Latitude-E5450:~/src/rpm$ grep rebuilddb rpmpopt.in rpm exec --rebuilddb rpmdb --rebuilddb
Interestingly, the command deleted /var/lib/rpm
No, it did not. It does not know anything about /var/lib/rpm at all.
(and my backups!) and created instead a symlink to ../../usr/lib/sysimage/rpm
rpmdb is located /usr/lib/sysimage/rpm in Leap 15 and TW. /var/lib/rpm is just compatibility link.
Found my backup in "/usr/lib/sysimage/rpmold.29244/copia".
So nothing was deleted.
On 01/02/2019 19.37, Andrei Borzenkov wrote:
01.02.2019 15:32, Carlos E. R. пишет:
On 01/02/2019 13.21, Carlos E. R. wrote:
On 01/02/2019 13.09, Andrei Borzenkov wrote:
Or create a temporary copy of the files and try the command.
Ok, both commands run.
--rebuilddb (and --inittdb) was provided by rpm in the past and was moved in separate rpmdb binary 8 years ago. "rpm --rebuilddb" is redirected to this binary via popt alias.
Ah. That explains it.
bor@bor-Latitude-E5450:~/src/rpm$ grep rebuilddb rpmpopt.in rpm exec --rebuilddb rpmdb --rebuilddb
Interestingly, the command deleted /var/lib/rpm
No, it did not. It does not know anything about /var/lib/rpm at all.
It certainly did. I had /var/lib/rpm open in 'mc' and it disappeared. A symlink appeared in its place to ../../usr/lib/sysimage/rpm. I undid it from backup and restored /var/lib/rpm with contents, then deleted /usr/lib/sysimage/rpm.
(and my backups!) and created instead a symlink to ../../usr/lib/sysimage/rpm
rpmdb is located /usr/lib/sysimage/rpm in Leap 15 and TW. /var/lib/rpm is just compatibility link.
The real "/var/lib/rpm" directory did exist in my 15.0 system, upgraded from 42.3. Something should have moved it, but did not. Probably I have to run rebuilddb and let it run to completion. I'm absolutely certain because 'mc' was opened on /var/lib/rpm and after the command (which I aborted with ctrl-c) it complained the current directory did not exist.
Found my backup in "/usr/lib/sysimage/rpmold.29244/copia".
So nothing was deleted.
Yes, /var/lib/rpm was "moved" aka deleted. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Fri, 1 Feb 2019 20:10:36 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
Yes, /var/lib/rpm was "moved" aka deleted.
Well to be fair there is a big difference between moved and deleted! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2019-02-01 at 19:20 -0000, Dave Howorth wrote:
On Fri, 1 Feb 2019 20:10:36 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
Yes, /var/lib/rpm was "moved" aka deleted.
Well to be fair there is a big difference between moved and deleted!
I assume that it is done via temporary copy of new directory, then delete of the original - because it can be different partition. It looks a move, but can be done with a copy. To me, I had 'mc' opened on "/var/lib/rpm", ie, current directory of a terminal session, and it disapeared. It said something like current directory does not exist, can not list current directory, error, which is why I said "deleted". Later I found that it was moved. But I write things as I find them, in sequence, as a log of events, which I admit can be confusing :-) - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFSyqBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV+ikAn0hJrbdEMgDbGnQjv0v1 q1V7UV4AAJ9TXyB0nAg76igcUPhtFtrd1bXhSA== =v5Dz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
01.02.2019 22:10, Carlos E. R. пишет:
bor@bor-Latitude-E5450:~/src/rpm$ grep rebuilddb rpmpopt.in rpm exec --rebuilddb rpmdb --rebuilddb
Interestingly, the command deleted /var/lib/rpm
No, it did not. It does not know anything about /var/lib/rpm at all.
It certainly did. I had /var/lib/rpm open in 'mc' and it disappeared. A symlink appeared in its place to ../../usr/lib/sysimage/rpm. I undid it from backup and restored /var/lib/rpm with contents, then deleted /usr/lib/sysimage/rpm.
If you insist on breaking your installation it is up to you. Except that rpm does *NOT* use /var/lib/rpm by default. If it does use it, it means you have non-default %_dbpath setting somewhere.
(and my backups!) and created instead a symlink to ../../usr/lib/sysimage/rpm
rpmdb is located /usr/lib/sysimage/rpm in Leap 15 and TW. /var/lib/rpm is just compatibility link.
The real "/var/lib/rpm" directory did exist in my 15.0 system, upgraded from 42.3.
Either update went wrong or you misinterpret what you see.
Something should have moved it, but did not. Probably I have to run rebuilddb and let it run to completion.
This "something" is "rpm" package script.
I'm absolutely certain because 'mc' was opened on /var/lib/rpm and after the command (which I aborted with ctrl-c) it complained the current directory did not exist.
I have no idea what mc does, and I'm not going to take it as ultimate wisdom. Unless you have actual directory listing of /var/lib and /usr/lib/sysimage at each point, I will continue to state that you misinterpret what you have seen.
Found my backup in "/usr/lib/sysimage/rpmold.29244/copia".
Which just proves that rpmdb worked on /usr/lib/sysimage exactly as it should. And that your old backups were under /usr/lib/sysimage as well which means /var/lib/rpm was link to /usr/lib/sysimage rpm when you created your backups. Show output of rpm --eval %_dbpath --eval %_dbpath_rebuild
On 02/02/2019 09.30, Andrei Borzenkov wrote:
01.02.2019 22:10, Carlos E. R. пишет:
bor@bor-Latitude-E5450:~/src/rpm$ grep rebuilddb rpmpopt.in rpm exec --rebuilddb rpmdb --rebuilddb
Interestingly, the command deleted /var/lib/rpm
No, it did not. It does not know anything about /var/lib/rpm at all.
It certainly did. I had /var/lib/rpm open in 'mc' and it disappeared. A symlink appeared in its place to ../../usr/lib/sysimage/rpm. I undid it from backup and restored /var/lib/rpm with contents, then deleted /usr/lib/sysimage/rpm.
If you insist on breaking your installation it is up to you. Except that rpm does *NOT* use /var/lib/rpm by default. If it does use it, it means you have non-default %_dbpath setting somewhere.
(and my backups!) and created instead a symlink to ../../usr/lib/sysimage/rpm
rpmdb is located /usr/lib/sysimage/rpm in Leap 15 and TW. /var/lib/rpm is just compatibility link.
The real "/var/lib/rpm" directory did exist in my 15.0 system, upgraded from 42.3.
Either update went wrong or you misinterpret what you see.
I'm positive about what I saw.
Something should have moved it, but did not. Probably I have to run rebuilddb and let it run to completion.
This "something" is "rpm" package script.
I'm absolutely certain because 'mc' was opened on /var/lib/rpm and after the command (which I aborted with ctrl-c) it complained the current directory did not exist.
I have no idea what mc does, and I'm not going to take it as ultimate wisdom. Unless you have actual directory listing of /var/lib and /usr/lib/sysimage at each point, I will continue to state that you misinterpret what you have seen.
It no longer does, because I manually changed it.
Found my backup in "/usr/lib/sysimage/rpmold.29244/copia".
Which just proves that rpmdb worked on /usr/lib/sysimage exactly as it should. And that your old backups were under /usr/lib/sysimage as well which means /var/lib/rpm was link to /usr/lib/sysimage rpm when you created your backups.
I had created backup of /var/lib/rpm into /var/lib/rpm/copia.20190201, and a previous copy existed as /var/lib/rpm/copia. A root file browser window was opened at /var/lib/rpm and another at /var/lib/rpm/copia.20190201, and after "rpmdb --rebuilddb" both complained the *current* directory had disappeared. I found /var/lib/rpm/copia.20190201 "moved" to new /usr/lib/sysimage/rpmold.29244/copia.20190201 /usr/lib/sysimage/ did not contain copia nor copia.20190201 If you don't know what mc is, you should find out. Just a file browser. I'm absolutely positive. It should not, but it was.
Show output of
rpm --eval %_dbpath --eval %_dbpath_rebuild
Pointless now, as I have manually changed things. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Op zaterdag 2 februari 2019 12:03:40 CET schreef Carlos E. R.:
On 02/02/2019 09.30, Andrei Borzenkov wrote:
01.02.2019 22:10, Carlos E. R. пишет:
bor@bor-Latitude-E5450:~/src/rpm$ grep rebuilddb rpmpopt.in rpm exec --rebuilddb rpmdb --rebuilddb
Interestingly, the command deleted /var/lib/rpm
No, it did not. It does not know anything about /var/lib/rpm at all.
It certainly did. I had /var/lib/rpm open in 'mc' and it disappeared. A symlink appeared in its place to ../../usr/lib/sysimage/rpm. I undid it from backup and restored /var/lib/rpm with contents, then deleted /usr/lib/sysimage/rpm.
If you insist on breaking your installation it is up to you. Except that rpm does *NOT* use /var/lib/rpm by default. If it does use it, it means you have non-default %_dbpath setting somewhere.
(and my backups!) and created instead a symlink to ../../usr/lib/sysimage/rpm
rpmdb is located /usr/lib/sysimage/rpm in Leap 15 and TW. /var/lib/rpm is just compatibility link.
The real "/var/lib/rpm" directory did exist in my 15.0 system, upgraded from 42.3.
Either update went wrong or you misinterpret what you see.
I'm positive about what I saw.
Something should have moved it, but did not. Probably I have to run rebuilddb and let it run to completion.
This "something" is "rpm" package script.
I'm absolutely certain because 'mc' was opened on /var/lib/rpm and after the command (which I aborted with ctrl-c) it complained the current directory did not exist.
I have no idea what mc does, and I'm not going to take it as ultimate wisdom. Unless you have actual directory listing of /var/lib and /usr/lib/sysimage at each point, I will continue to state that you misinterpret what you have seen.
It no longer does, because I manually changed it.
Found my backup in "/usr/lib/sysimage/rpmold.29244/copia".
Which just proves that rpmdb worked on /usr/lib/sysimage exactly as it should. And that your old backups were under /usr/lib/sysimage as well which means /var/lib/rpm was link to /usr/lib/sysimage rpm when you created your backups.
I had created backup of /var/lib/rpm into /var/lib/rpm/copia.20190201, and a previous copy existed as /var/lib/rpm/copia.
A root file browser window was opened at /var/lib/rpm and another at /var/lib/rpm/copia.20190201, and after "rpmdb --rebuilddb" both complained the *current* directory had disappeared. I found /var/lib/rpm/copia.20190201 "moved" to new /usr/lib/sysimage/rpmold.29244/copia.20190201
/usr/lib/sysimage/ did not contain copia nor copia.20190201
If you don't know what mc is, you should find out. Just a file browser.
I'm absolutely positive. It should not, but it was.
Show output of
rpm --eval %_dbpath --eval %_dbpath_rebuild
Pointless now, as I have manually changed things. And, manually changing stuff often leads to trouble. It could even be, that having mc ( midnight commander fwiw ) was in fault. I checked all the things Andrei wrote, and he's right. For both Leap and TW.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/02/2019 12.07, Knurpht-openSUSE wrote:
Op zaterdag 2 februari 2019 12:03:40 CET schreef Carlos E. R.:
On 02/02/2019 09.30, Andrei Borzenkov wrote:
01.02.2019 22:10, Carlos E. R. пишет:
Show output of
rpm --eval %_dbpath --eval %_dbpath_rebuild
Pointless now, as I have manually changed things.
And, manually changing stuff often leads to trouble. It could even be, that having mc ( midnight commander fwiw ) was in fault. I checked all the things Andrei wrote, and he's right. For both Leap and TW.
Telcontar:/var/lib # rpmdb --rebuilddb Telcontar:/var/lib # rpm --eval %_dbpath --eval %_dbpath_rebuild /usr/lib/sysimage/rpm /usr/lib/sysimage/rpm Telcontar:/var/lib # Telcontar:/var/lib # l | grep rpm lrwxrwxrwx 1 root root 26 Feb 2 11:10 rpm -> ../../usr/lib/sysimage/rpm/ drwxr-xr-x 2 root root 4096 Feb 1 20:07 rpm.old/ -rw-r--r-- 1 root root 1560556 Feb 2 12:14 rpmlist Telcontar:/var/lib # Telcontar:/var/lib # rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" | sort | cut --fields="2-" | tee rpmlist | less -S ... Fri Jan 18 2019 Tue Jan 15 2019 kdelibs3 3.5.10-lp150.210.4 x86_64 obs://build.opensuse.org/KDE:KDE3 (none) == KDE:KDE3 / openSUSE_Leap_15.0 (none) Fri Jan 18 2019 Thu Jan 17 2019 pulseaudio-gdm-hooks 12.2-lp150.5.2 x86_64 obs://build.opensuse.org/multimedia (none) == multimedia:libs / openSUSE_Leap_15.0> Fri Jan 18 2019 Wed Jun 07 2017 hte 2.1.0-lp150.1.8 x86_64 openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Wed Jan 23 2019 Fri Oct 28 2011 icc-profiles-basiccolor-printing2009-extra 1.2.0-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Wed Jan 23 2019 Sun Mar 25 2012 icc-profiles-all 1.2-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Wed Jan 23 2019 Sun Mar 25 2012 icc-profiles-oyranos-extra 1.2-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Thu Jan 24 2019 Sun Mar 25 2012 icc-profiles-openicc-rgb 1.3-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Thu Jan 24 2019 Thu Jan 24 2019 pin 0.38-lp150.2.9.1 noarch obs://build.opensuse.org/home:cboltz (none) == home:cboltz:branches:openSUSE:Leap:> Telcontar:/var/lib # rpm -qa | wc -l 8388 Telcontar:/var/lib packages are properly listed. Happy? :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Op zaterdag 2 februari 2019 12:18:25 CET schreef Carlos E. R.:
On 02/02/2019 12.07, Knurpht-openSUSE wrote:
Op zaterdag 2 februari 2019 12:03:40 CET schreef Carlos E. R.:
On 02/02/2019 09.30, Andrei Borzenkov wrote:
01.02.2019 22:10, Carlos E. R. пишет:
Show output of
rpm --eval %_dbpath --eval %_dbpath_rebuild
Pointless now, as I have manually changed things.
And, manually changing stuff often leads to trouble. It could even be, that having mc ( midnight commander fwiw ) was in fault. I checked all the things Andrei wrote, and he's right. For both Leap and TW.
Telcontar:/var/lib # rpmdb --rebuilddb Telcontar:/var/lib # rpm --eval %_dbpath --eval %_dbpath_rebuild /usr/lib/sysimage/rpm /usr/lib/sysimage/rpm Telcontar:/var/lib # Telcontar:/var/lib # l | grep rpm lrwxrwxrwx 1 root root 26 Feb 2 11:10 rpm -> ../../usr/lib/sysimage/rpm/ drwxr-xr-x 2 root root 4096 Feb 1 20:07 rpm.old/ -rw-r--r-- 1 root root 1560556 Feb 2 12:14 rpmlist Telcontar:/var/lib So, it's a symlink. And mc may have simply not refreshed the contents of the folder /var/lib/rpm is symlinked to. Why insist that your system does not behave like Andrei says. He's the one with the detailed knowledge. And AFAICS he's 100% right, if I look at my installs. If yours doesn't work like that ( and it is, since your backups are in the proper folder and no package install changes that ), it must be manual changes. And no, this is not my road to happiness :D
Telcontar:/var/lib # rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" | sort | cut --fields="2-" | tee rpmlist | less -S
...
Fri Jan 18 2019 Tue Jan 15 2019 kdelibs3 3.5.10-lp150.210.4 x86_64 obs://build.opensuse.org/KDE:KDE3 (none) == KDE:KDE3 / openSUSE_Leap_15.0 (none) Fri Jan 18 2019 Thu Jan 17 2019 pulseaudio-gdm-hooks 12.2-lp150.5.2 x86_64 obs://build.opensuse.org/multimedia (none) == multimedia:libs / openSUSE_Leap_15.0> Fri Jan 18 2019 Wed Jun 07 2017 hte 2.1.0-lp150.1.8 x86_64 openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Wed Jan 23 2019 Fri Oct 28 2011 icc-profiles-basiccolor-printing2009-extra 1.2.0-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Wed Jan 23 2019 Sun Mar 25 2012 icc-profiles-all 1.2-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Wed Jan 23 2019 Sun Mar 25 2012 icc-profiles-oyranos-extra 1.2-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Thu Jan 24 2019 Sun Mar 25 2012 icc-profiles-openicc-rgb 1.3-lp150.1.6 noarch openSUSEhttps://bugs.opensuse.org == openSUSE Leap 15.0 (none) Thu Jan 24 2019 Thu Jan 24 2019 pin 0.38-lp150.2.9.1 noarch obs://build.opensuse.org/home:cboltz (none) == home:cboltz:branches:openSUSE:Leap:>
Telcontar:/var/lib # rpm -qa | wc -l 8388 Telcontar:/var/lib
packages are properly listed.
Happy? :-)
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/02/2019 12.29, Knurpht-openSUSE wrote:
Op zaterdag 2 februari 2019 12:18:25 CET schreef Carlos E. R.:
On 02/02/2019 12.07, Knurpht-openSUSE wrote:
Op zaterdag 2 februari 2019 12:03:40 CET schreef Carlos E. R.:
On 02/02/2019 09.30, Andrei Borzenkov wrote:
01.02.2019 22:10, Carlos E. R. пишет:
Show output of
rpm --eval %_dbpath --eval %_dbpath_rebuild
Pointless now, as I have manually changed things.
And, manually changing stuff often leads to trouble. It could even be, that having mc ( midnight commander fwiw ) was in fault. I checked all the things Andrei wrote, and he's right. For both Leap and TW.
Telcontar:/var/lib # rpmdb --rebuilddb Telcontar:/var/lib # rpm --eval %_dbpath --eval %_dbpath_rebuild /usr/lib/sysimage/rpm /usr/lib/sysimage/rpm Telcontar:/var/lib # Telcontar:/var/lib # l | grep rpm lrwxrwxrwx 1 root root 26 Feb 2 11:10 rpm -> ../../usr/lib/sysimage/rpm/ drwxr-xr-x 2 root root 4096 Feb 1 20:07 rpm.old/ -rw-r--r-- 1 root root 1560556 Feb 2 12:14 rpmlist Telcontar:/var/lib So, it's a symlink. And mc may have simply not refreshed the contents of the folder /var/lib/rpm is symlinked to.
I did ctrl-R.
Why insist that your system does not behave like Andrei says. He's the one with the detailed knowledge. And AFAICS he's 100% right, if I look at my installs. If yours doesn't work like that ( and it is, since your backups are in the proper folder and no package install changes that ), it must be manual changes. And no, this is not my road to happiness :D
Things are where they should now, after I took manual action :-) The state I described before was temporary, and possibly a result of aborting rpm --rebuilddb. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
02.02.2019 14:49, Carlos E. R. пишет:
The state I described before was temporary, and possibly a result of aborting rpm --rebuilddb.
well, if you aborted rebuilddb after it renamed old directory but before it could rename temporary directory in its place of course you had now dangling link. Not that you ever mentioned it before either ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2019-02-02 at 15:34 +0300, Andrei Borzenkov wrote:
02.02.2019 14:49, Carlos E. R. пишет:
The state I described before was temporary, and possibly a result of aborting rpm --rebuilddb.
well, if you aborted rebuilddb after it renamed old directory but before it could rename temporary directory in its place of course you had now dangling link.
Not that you ever mentioned it before either ...
I did. Date: Fri, 1 Feb 2019 20:10:36 +0100
I'm absolutely certain because 'mc' was opened on /var/lib/rpm and after the command (which I aborted with ctrl-c) it complained the current directory did not exist.
- -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFWRjRQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1TDlAJ9EsFmdwvyUfJ0wRjHvX/MwNXFLRwCc ClLjzj/Gjq4qbPgpa1Q82Esffzc= =S6wJ -----END PGP SIGNATURE-----
Op vrijdag 1 februari 2019 13:06:04 CET schreef Carlos E. R.:
On 01/02/2019 12.58, Andrei Borzenkov wrote:
On Fri, Feb 1, 2019 at 2:14 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 01/02/2019 08.26, Basil Chupin wrote:
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-).
Did you run "rpm --rebuilddb" or "rpmdb --rebuilddb" yet?
I had the same problem too on TW VM and ended up doing rebuilddb. It was sporadic, but running verification show errors in files other than Packages.
Did you find out if the command "rpm --rebuilddb" works, or only "rpmdb --rebuilddb"?
I ask because I want to report man page error in bugzilla, but perhaps the page is correct.
I hesitate to try "rpm --rebuilddb" on a healthy system. From 'man rpmdb' RPMDB(8) System Manager's Manual RPMDB(8)
NAME rpmdb - RPM Database Tool SYNOPSIS rpm {--initdb|--rebuilddb} Fire up a VM, try. Did so, ages ago, and it never failed. But still, we don't know what Basil "fiddled", so the cause might completely different. FWIW he may have destroyed a btrfs subvolume. We don't know. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/02/2019 13.18, Knurpht-openSUSE wrote:
Op vrijdag 1 februari 2019 13:06:04 CET schreef Carlos E. R.:
On 01/02/2019 12.58, Andrei Borzenkov wrote:
On Fri, Feb 1, 2019 at 2:14 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 01/02/2019 08.26, Basil Chupin wrote:
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-).
Did you run "rpm --rebuilddb" or "rpmdb --rebuilddb" yet?
I had the same problem too on TW VM and ended up doing rebuilddb. It was sporadic, but running verification show errors in files other than Packages.
Did you find out if the command "rpm --rebuilddb" works, or only "rpmdb --rebuilddb"?
I ask because I want to report man page error in bugzilla, but perhaps the page is correct.
I hesitate to try "rpm --rebuilddb" on a healthy system. From 'man rpmdb' RPMDB(8) System Manager's Manual RPMDB(8)
NAME rpmdb - RPM Database Tool
SYNOPSIS rpm {--initdb|--rebuilddb}
I know that manpage, and my hypothesis is that there is a mistake, and I want to check.
Fire up a VM, try. Did so, ages ago, and it never failed.
See my response to Andrei ;-)
But still, we don't know what Basil "fiddled", so the cause might completely different. FWIW he may have destroyed a btrfs subvolume. We don't know.
LOL. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/2/19 11:18 pm, Knurpht-openSUSE wrote:
Op vrijdag 1 februari 2019 13:06:04 CET schreef Carlos E. R.:
On 01/02/2019 12.58, Andrei Borzenkov wrote:
On Fri, Feb 1, 2019 at 2:14 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 01/02/2019 08.26, Basil Chupin wrote:
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-). Did you run "rpm --rebuilddb" or "rpmdb --rebuilddb" yet? I had the same problem too on TW VM and ended up doing rebuilddb. It was sporadic, but running verification show errors in files other than Packages. Did you find out if the command "rpm --rebuilddb" works, or only "rpmdb --rebuilddb"?
I ask because I want to report man page error in bugzilla, but perhaps the page is correct.
I hesitate to try "rpm --rebuilddb" on a healthy system. From 'man rpmdb' RPMDB(8) System Manager's Manual RPMDB(8)
NAME rpmdb - RPM Database Tool
SYNOPSIS rpm {--initdb|--rebuilddb}
Fire up a VM, try. Did so, ages ago, and it never failed. But still, we don't know what Basil "fiddled", so the cause might completely different. FWIW he may have destroyed a btrfs subvolume. We don't know.
The 'fiddle' I did was to run 'zypper clean -a' and then run 'zypper refresh/patch/run'. Haven't yet run 'rpm --rebuilddb' -- which is the next step after I have finished reading the rest of the posts in this thread :-). I do not use btrfs. Always use ext4. BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op vrijdag 1 februari 2019 08:26:37 CET schreef Basil Chupin:
On 31/1/19 10:06 pm, Felix Miata wrote:
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens.
You might want to hold off, or lock your existing initrds. Seems to be: http://bugzilla.opensuse.org/show_bug.cgi?id=1122456
I've looked at that bug report and it seems to me that it is concerned about the use of radeon versus nvidia graphic cards. Since I have never used radeon but only have nvidia cards I need to look elsewhere for the answer.
BC
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-). Had a quick look: "Fiddle" is not a techique described in my books. Without knowing what you mean by that terminology it's impossible to say something decent about it.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/2/19 10:27 pm, Knurpht-openSUSE wrote:
Op vrijdag 1 februari 2019 08:26:37 CET schreef Basil Chupin:
On 31/1/19 10:06 pm, Felix Miata wrote:
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens. You might want to hold off, or lock your existing initrds. Seems to be: http://bugzilla.opensuse.org/show_bug.cgi?id=1122456 I've looked at that bug report and it seems to me that it is concerned about the use of radeon versus nvidia graphic cards. Since I have never used radeon but only have nvidia cards I need to look elsewhere for the answer.
BC
PS A few minutes ago I tried to "fiddle" with my wife's Leap 15.0 system and after that rebooted the system; when I logged in, I received a Notification stating , "Failed to cache rpm database".
Going from bad to worse :-). Had a quick look: "Fiddle" is not a techique described in my books. Without knowing what you mean by that terminology it's impossible to say something decent about it.
Nero fiddled while Rome burned. You've been looking in the wrong books :-). Fiddled Verb ... 1.1 Tinker with something in an attempt to make minor adjustments or improvements. /‘he fiddled with the blind, trying to prevent the sun from shining in her eyes’/ / / /.../ / / /https://en.oxforddictionaries.com/definition/fiddle/ / / / / /BC/ / / -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin composed on 2019-02-01 18:26 (UTC+1100):
Felix Miata wrote:
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens. You might want to hold off, or lock your existing initrds. Seems to be: http://bugzilla.opensuse.org/show_bug.cgi?id=1122456
I've looked at that bug report and it seems to me that it is concerned about the use of radeon versus nvidia graphic cards. Since I have never used radeon but only have nvidia cards I need to look elsewhere for the answer.
Then maybe this one?: https://bugzilla.opensuse.org/show_bug.cgi?id=1123967 Inconsistent behavior when refreshing repositories -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2/2/19 4:05 pm, Felix Miata wrote:
Basil Chupin composed on 2019-02-01 18:26 (UTC+1100):
Felix Miata wrote:
Basil Chupin composed on 2019-01-31 18:41 (UTC+1100):
I'll try updating Leap 15.1 and Tumbleweed (on my computer) and see what happens. You might want to hold off, or lock your existing initrds. Seems to be: http://bugzilla.opensuse.org/show_bug.cgi?id=1122456 I've looked at that bug report and it seems to me that it is concerned about the use of radeon versus nvidia graphic cards. Since I have never used radeon but only have nvidia cards I need to look elsewhere for the answer. Then maybe this one?: https://bugzilla.opensuse.org/show_bug.cgi?id=1123967 Inconsistent behavior when refreshing repositories
Ah, this sounds more like it but it is rather odd that it should strike 'now' and only on my wife's Leap 15 :-). Never had this hassle in all the years I've been using oS/zypper. Anyway... Many, many thanks to everyone who helped re this problem and the problem has now been solved. I ran- zypper clean -a ; then rpm --rebuilddb and then ran 'zypper refresh/patch/up' as there were a number of updates to be done and... all updates were installed without a problem this time! :-) BC -- 'When I use a word', Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean.' Lewis Carroll, Through the Looking-Glass -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Basil Chupin -
Carlos E. R. -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
Felix Miata -
Knurpht-openSUSE