Created attachment 848940 [details] yum history info Description of problem: during the update I saw message that 'semodule' segfaulted. Version-Release number of selected component (if applicable): policycoreutils-2.2.5-1.fc20.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 848948 [details] gdb trace
I think I did something wrong in gdb with executable file (sorry) ""/usr/sbin/semanage": not in executable format: File format not recognized", but looks like gdb picks up the right file later (smarter than me!) "Reading symbols from /usr/sbin/semodule...Reading symbols from /usr/lib/debug/usr/sbin/semodule.debug...done."
Any chance you are out of memory?
If you execute # yum reinstall selinux-policy-targeted does it blow up?
"Any chance you are out of memory?" I have 3G of RAM + 4G of swap (and it is mostly ~1.5G used (swap ~100% free)) No, reinstalling 'selinux-policy-targeted' doesn't blow up, reinstalls fine. I know it can be a hw. problem I tested memory with memtest86, no issues (~6x (all tests)) Anything useful I can get from those "crash files" (from abrt, I don't like uploading everything, trace is 'generated' from coredump, I can install more debug symbols if needed?)
Ok. So now it works. How about # semodule -B Basically we would need to have a coredump from the crash.
No, 'semodule -B' also works, I'm attaching 'bt full', not sure if it can help. Sorry I cannot upload a coredump (if you cannot do much without it, you can close this bug)
Created attachment 849800 [details] bt full (w/ extra symbols)
So what command is blowing up now?
This was actually a hw. issue, somehow RAM failed, but it doesn't fail memtest86 on this machine, I tested it in another and one stick fails :S Sorry for the noise, and thank you! I'll close it now.