On Intel P4 host gx280 with 2GB RAM tonight this happened about 2/3 through dnf update on both F25 and F26 installations, F26 the latter. Last package's scriptlet completed for udisks2. Last line before segfault is upgrading gstreamer1-plugins-bad-free. Prior to 'dnf update' on both I had run 'dnf update dnf* rpm* glib* drac* libso* hawk* syste* fedo*. In F25 with <70 packages left to update I rebooted and restarted dnf update only to have it eventually claim completion without ever actually installing the kernel to /boot, though the rpm DB claimed it was installed. I reinstalled the kernel and it runs Plasma, but I wonder what else didn't get completely installed. Distro-sync wouldn't run due to some missing dependant rpm I don't remember. Looking at the journal on F26 suggests that dnf may have been interrupted by some cron job, and there's this:
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
On 07/21/2017 12:12 AM, Felix Miata wrote:
On Intel P4 host gx280 with 2GB RAM tonight this happened about 2/3 through dnf update on both F25 and F26 installations, F26 the latter. Last package's scriptlet completed for udisks2. Last line before segfault is upgrading gstreamer1-plugins-bad-free. Prior to 'dnf update' on both I had run 'dnf update dnf* rpm* glib* drac* libso* hawk* syste* fedo*. In F25 with <70 packages left to update I rebooted and restarted dnf update only to have it eventually claim completion without ever actually installing the kernel to /boot, though the rpm DB claimed it was installed. I reinstalled the kernel and it runs Plasma, but I wonder what else didn't get completely installed. Distro-sync wouldn't run due to some missing dependant rpm I don't remember. Looking at the journal on F26 suggests that dnf may have been interrupted by some cron job, and there's this:
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
This could the libdb/glibc problem. Try running "rm /var/lib/rpm/__*" and then "rpm --rebuilddb" and see if that fixes it.
Samuel Sieb composed on 2017-07-21 08:54 (UTC-0700):
Felix Miata wrote:
On Intel P4 host gx280 with 2GB RAM tonight this happened about 2/3 through dnf update on both F25 and F26 installations, F26 the latter. Last package's scriptlet completed for udisks2. Last line before segfault is upgrading gstreamer1-plugins-bad-free. Prior to 'dnf update' on both I had run 'dnf update dnf* rpm* glib* drac* libso* hawk* syste* fedo*. In F25 with <70 packages left to update I rebooted and restarted dnf update only to have it eventually claim completion without ever actually installing the kernel to /boot, though the rpm DB claimed it was installed. I reinstalled the kernel and it runs Plasma, but I wonder what else didn't get completely installed. Distro-sync wouldn't run due to some missing dependant rpm I don't remember. Looking at the journal on F26 suggests that dnf may have been interrupted by some cron job, and there's this:
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
This could the libdb/glibc problem. Try running "rm /var/lib/rpm/__*" and then "rpm --rebuilddb" and see if that fixes it.
On F26 as soon as I sent my OP I rebooted, did dnf clean all, rpm --rebuilddb, dnf update, dnf distro-sync, then shut down and went to bed. Distro-sync did nothing but remove 225 packages.
I did similar with F25, but don't remember particulars other than it reacted differently to a similar sequence of events, most of which are in my OP.
On 07/21/2017 10:16 AM, Felix Miata wrote:
On F26 as soon as I sent my OP I rebooted, did dnf clean all, rpm --rebuilddb, dnf update, dnf distro-sync, then shut down and went to bed. Distro-sync did nothing but remove 225 packages.
I did similar with F25, but don't remember particulars other than it reacted differently to a similar sequence of events, most of which are in my OP.
Maybe you could make it clearer what you are asking then. The subject is about dnf segfaulting, but it sounds now like you are asking something else and I don't understand what it is that you are trying to find out.
Samuel Sieb composed on 2017-07-21 13:43 (UTC-0700):
Felix Miata wrote:
On F26 as soon as I sent my OP I rebooted, did dnf clean all, rpm --rebuilddb, dnf update, dnf distro-sync, then shut down and went to bed. Distro-sync did nothing but remove 225 packages.
I did similar with F25, but don't remember particulars other than it reacted differently to a similar sequence of events, most of which are in my OP.
Maybe you could make it clearer what you are asking then. The subject is about dnf segfaulting, but it sounds now like you are asking something else and I don't understand what it is that you are trying to find out.
That anyone answered my OP at all pretty much answered my question implied, "is this a problem familiar to anyone here"? :-)
My BRC searches have a habit of either timing out or producing mostly summaries with what to me is incomprehensible babble, and that only after great difficulty finding one or more Fedora versions to actually select from its endless version select list. Once classification Fedora is selected, that select list ought to drop precipitously below 100 to choose from.
Where does one find errata that closed bugs for yet-to-be releases refer to? e.g. libdb: Assumes that internal condition variable layout never changes https://bugzilla.redhat.com/show_bug.cgi?id=1394862
The string errata is not present on https://fedoraproject.org/wiki/Fedora_Project_Wiki or https://getfedora.org/ or http://fedoraplanet.org/
On 07/21/2017 05:44 PM, Felix Miata wrote:
My BRC searches have a habit of either timing out or producing mostly summaries with what to me is incomprehensible babble, and that only after great difficulty finding one or more Fedora versions to actually select from its endless version select list. Once classification Fedora is selected, that select list ought to drop precipitously below 100 to choose from.
I think you're making this more complicated than you need to. I'm assuming you're using the advanced search. Select "Fedora" in the Classification list, select "Fedora" in the Product list, then if you want to search in specific packages, pick the Components you want. Then you can put your search terms in the search box and go.
Where does one find errata that closed bugs for yet-to-be releases refer to? e.g. libdb: Assumes that internal condition variable layout never changes https://bugzilla.redhat.com/show_bug.cgi?id=1394862
I have no idea what you're asking here. Can you explain in more detail?
Samuel Sieb composed on 2017-07-21 21:40 (UTC-0700):
Felix Miata wrote:
My BRC searches have a habit of either timing out or producing mostly summaries with what to me is incomprehensible babble, and that only after great difficulty finding one or more Fedora versions to actually select from its endless version select list. Once classification Fedora is selected, that select list ought to drop precipitously below 100 to choose from.
I think you're making this more complicated than you need to. I'm assuming you're using the advanced search. Select "Fedora" in the
Did that.
Classification list, select "Fedora" in the Product list, then if you
Forgot that, but, doing it didn't change the problem....
want to search in specific packages, pick the Components you want. Then you can put your search terms in the search box and go.
What I wish is to limit the search to bugs filed against F25 or F26, so I goto the "Version:" select list only to find it contains approximately 2,053 selections from which to choose (I saved https://bugzilla.redhat.com/query.cgi to disk and found the options to begin on line 1268 and end on line 5273). That many selections are totally unwieldy in a box that shows only 6 selections at a time, particularly since that list contains a mixture of alpha-numeric and numbers-only selections of unknown sort state (A=a, B=b, etc., or not) and I don't know whether I'm looking for 26, F26 or f26.
I've been doing Bugzilla searches since registering on bugzilla.mozilla.org in 2001. bugzilla.redhat.com is consistently the most difficult BZ installation I routinely need to use, mainly because of huge "select" lists, "Version:", "Product" and "Component" in particular.
Where does one find errata that closed bugs for yet-to-be releases refer to? e.g. libdb: Assumes that internal condition variable layout never changes https://bugzilla.redhat.com/show_bug.cgi?id=1394862
I have no idea what you're asking here. Can you explain in more detail?
Bug 1394862's status is CLOSED ERRATA. According to http://www.dictionary.com/browse/errata?s=t errata means:
"1.plural of erratum. 2.a list of errors and their corrections inserted, usually on a separate page or slip of paper, in a book or other publication; corrigenda."
Knowing that definition, I expect a web search to find me a list describing something about the state of whatever package, applicable to the not yet released Fedora 26, contains a fix for that bug, but searching found me no such list. :-(
https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status states a bug with status ERRATA has a fix that "is available", but I suspect that for this bug and many others, such status has been applied prematurely/prospectively, confirming propriety of some kind of available status list.
On 07/21/2017 10:31 PM, Felix Miata wrote:
What I wish is to limit the search to bugs filed against F25 or F26, so I goto the "Version:" select list only to find it contains approximately 2,053 selections from which to choose (I saved https://bugzilla.redhat.com/query.cgi to disk and found the options to begin on line 1268 and end on line 5273). That many selections are totally unwieldy in a box that shows only 6 selections at a time, particularly since that list contains a mixture of alpha-numeric and numbers-only selections of unknown sort state (A=a, B=b, etc., or not) and I don't know whether I'm looking for 26, F26 or f26.
After you've picked Fedora as the product, click the refresh versions/releases/milestones button. Then you'll find only the Fedora release numbers in the version list.
Samuel Sieb composed on 2017-07-22 09:58 (UTC-0700):
Felix Miata wrote:
What I wish is to limit the search to bugs filed against F25 or F26, so I goto the "Version:" select list only to find it contains approximately 2,053 selections from which to choose (I saved https://bugzilla.redhat.com/query.cgi to disk and found the options to begin on line 1268 and end on line 5273). That many selections are totally unwieldy in a box that shows only 6 selections at a time, particularly since that list contains a mixture of alpha-numeric and numbers-only selections of unknown sort state (A=a, B=b, etc., or not) and I don't know whether I'm looking for 26, F26 or f26.
After you've picked Fedora as the product, click the refresh versions/releases/milestones button. Then you'll find only the Fedora release numbers in the version list.
O_O
A: Who would know such a button exists? :-p
Work-flow as I've described: 1-select product 2-select component 3-scroll window down so that version/milestone/target lists are fully visible 4-what refresh button? 5-continue selecting restraints 6-enter search terms in summary and/or comments and/or other 7-Go
Don't you think such a (*unique to BRC* AFAIK) button belongs in the same page view as the objects to which it applies?
B: It seems like having made product and component selections the version list would be refreshed automatically. :-(
On Fri, Jul 21, 2017 at 11:31 PM, Felix Miata mrmazda@earthlink.net wrote:
Bug 1394862's status is CLOSED ERRATA. According to http://www.dictionary.com/browse/errata?s=t errata means:
"1.plural of erratum. 2.a list of errors and their corrections inserted, usually on a separate page or slip of paper, in a book or other publication; corrigenda."
Same boat. I've been unable to square the language "CLOSED ERRATA" and actual practice in bug reports. I have no idea what is meant by this, but I have the same reaction which is "errata OK where are they?" Except there is none unless you count the individual comments collectively as "errata". *shrug* Anyway it's a weird convention in my opinion.
On Sat, 2017-07-22 at 01:31 -0400, Felix Miata wrote:
Bug 1394862's status is CLOSED ERRATA. According to http://www.dictionary.com/browse/errata?s=t errata means:
"1.plural of erratum. 2.a list of errors and their corrections inserted, usually on a separate page or slip of paper, in a book or other publication; corrigenda."
Knowing that definition, I expect a web search to find me a list describing something about the state of whatever package, applicable to the not yet released Fedora 26, contains a fix for that bug, but searching found me no such list. :-(
https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status states a bug with status ERRATA has a fix that "is available", but I suspect that for this bug and many others, such status has been applied prematurely/prospectively, confirming propriety of some kind of available status list.
Neither of those is the correct reference; in fact the bugzilla.redhat.com page *specifically states* that it is not the correct reference for Fedora bugs. The correct reference for Fedora bugs is https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow :
"Once a bug has been fixed and included in a new package in rawhide or the updates repo it should be closed. For a stable or Branched release, the resolution ERRATA should be used. For Rawhide, the resolution RAWHIDE should be used."
ERRATA just means there was an update (that is, a Bodhi update) that fixed the bug.
On Fri, 2017-07-21 at 08:54 -0700, Samuel Sieb wrote:
On 07/21/2017 12:12 AM, Felix Miata wrote:
On Intel P4 host gx280 with 2GB RAM tonight this happened about 2/3 through dnf update on both F25 and F26 installations, F26 the latter. Last package's scriptlet completed for udisks2. Last line before segfault is upgrading gstreamer1-plugins-bad-free. Prior to 'dnf update' on both I had run 'dnf update dnf* rpm* glib* drac* libso* hawk* syste* fedo*. In F25 with <70 packages left to update I rebooted and restarted dnf update only to have it eventually claim completion without ever actually installing the kernel to /boot, though the rpm DB claimed it was installed. I reinstalled the kernel and it runs Plasma, but I wonder what else didn't get completely installed. Distro-sync wouldn't run due to some missing dependant rpm I don't remember. Looking at the journal on F26 suggests that dnf may have been interrupted by some cron job, and there's this:
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
This could the libdb/glibc problem. Try running "rm /var/lib/rpm/__*" and then "rpm --rebuilddb" and see if that fixes it.
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root):
restorecon -RFv /var/lib/rpm
On 07/21/2017 12:28 PM, Adam Williamson wrote:
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root):
restorecon -RFv /var/lib/rpm
Interesting, I haven't seen that mentioned anywhere else in any of the discussions of the issue.
On Fri, 2017-07-21 at 13:41 -0700, Samuel Sieb wrote:
On 07/21/2017 12:28 PM, Adam Williamson wrote:
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root):
restorecon -RFv /var/lib/rpm
Interesting, I haven't seen that mentioned anywhere else in any of the discussions of the issue.
I was only informed of it a few days ago; I've been editing things since then, but yes, it wasn't known when we wrote the original round of blog posts etc.
On 07/22/17 05:47, Adam Williamson wrote:
On Fri, 2017-07-21 at 13:41 -0700, Samuel Sieb wrote:
On 07/21/2017 12:28 PM, Adam Williamson wrote:
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root):
restorecon -RFv /var/lib/rpm
Interesting, I haven't seen that mentioned anywhere else in any of the discussions of the issue.
I was only informed of it a few days ago; I've been editing things since then, but yes, it wasn't known when we wrote the original round of blog posts etc.
Should that be considered a bug in rpmdb?
On Sat, 2017-07-22 at 06:04 +0800, Ed Greshko wrote:
On 07/22/17 05:47, Adam Williamson wrote:
On Fri, 2017-07-21 at 13:41 -0700, Samuel Sieb wrote:
On 07/21/2017 12:28 PM, Adam Williamson wrote:
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root):
restorecon -RFv /var/lib/rpm
Interesting, I haven't seen that mentioned anywhere else in any of the discussions of the issue.
I was only informed of it a few days ago; I've been editing things since then, but yes, it wasn't known when we wrote the original round of blog posts etc.
Should that be considered a bug in rpmdb?
It's currently counted as a bug in rpm.
https://bugzilla.redhat.com/show_bug.cgi?id=1461313
Adam Williamson composed on 2017-07-21 12:28 (UTC-0700):
On Fri, 2017-07-21 at 08:54 -0700, Samuel Sieb wrote:
Felix Miata wrote:
...
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
This could the libdb/glibc problem. Try running "rm /var/lib/rpm/__*" and then "rpm --rebuilddb" and see if that fixes it.
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root):
restorecon -RFv /var/lib/rpm
Even when selinux=0?
On Fri, 2017-07-21 at 20:16 -0400, Felix Miata wrote:
Adam Williamson composed on 2017-07-21 12:28 (UTC-0700):
On Fri, 2017-07-21 at 08:54 -0700, Samuel Sieb wrote:
Felix Miata wrote:
...
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
This could the libdb/glibc problem. Try running "rm /var/lib/rpm/__*" and then "rpm --rebuilddb" and see if that fixes it.
Note that apparently manually rebuilding the DB can result in it having the wrong SELinux label, so you should also run this afterwards (as root): restorecon -RFv /var/lib/rpm
Even when selinux=0?
Well, it wouldn't hurt anything (though it might not work), but it wouldn't be necessary, if you always boot with SELinux disabled. (Which of course we do not advise.)
Felix Miata composed on 2017-07-21 03:12 (UTC-0400):
On Intel P4 host gx280 with 2GB RAM tonight this happened about 2/3 through dnf update on both F25 and F26 installations, F26 the latter. Last package's scriptlet completed for udisks2. Last line before segfault is upgrading gstreamer1-plugins-bad-free. Prior to 'dnf update' on both I had run 'dnf update dnf* rpm* glib* drac* libso* hawk* syste* fedo*. In F25 with <70 packages left to update I rebooted and restarted dnf update only to have it eventually claim completion without ever actually installing the kernel to /boot, though the rpm DB claimed it was installed. I reinstalled the kernel and it runs Plasma, but I wonder what else didn't get completely installed. Distro-sync wouldn't run due to some missing dependant rpm I don't remember. Looking at the journal on F26 suggests that dnf may have been interrupted by some cron job, and there's this:
Jul 21 02:18:18 gx280 kernel: dnf[5909]: segfault at ae738a35 ip b573218e sp bfe6d090 error 4 in libdb-5.3.so (deleted)[b55f2000+1d1000]
Is there a known procedure for avoiding this on installations last updated several months ago?
-
Adam Williamson -
Chris Murphy -
Ed Greshko -
Felix Miata -
Samuel Sieb