LIBC PANIC!! updating Python

[muffetta66]

I got the error in attach updating python to python-2.7.6-12.oc00.i686.
Always worked right since now. After ctrl-c, the message has gone and it says there are no more packages to update, inside C:\usr\bin latest files are:

python.dbg | 3.855│12/12/15│ 2:17
python.exe │ 1.050│12/12/15│ 2:17
python2.7.dbg │ 3.855│12/12/15│ 2:17
python2.7.exe │ 1.050│12/12/15│ 2:17
msgfmt.py │ 6.714│12/12/15│ 2:17
pygettext.py │ 22.764│12/12/15│ 2:17
python │ 5.411│12/12/15│ 2:17
python-config │ 14│12/12/15│ 2:17
python2-config │ 16│12/12/15│ 2:17
python2.exe │ 13│12/12/15│ 2:17
python2.7-config │ 1.860│12/12/15│ 2:17

Has the installer right ended its work?

[dmik]

Thank you for the report. Python does some work during installation, e.g. it precompiles it's system library's scripts. And this seems to be the stage where it crashes for you. It may be related to the fact that you use the i686 architecture. Can you please try to install the i386 binaries?

[dmik]

Or, first, can you please try to reinstall it with yum reinstall python?

Needless to say that I don't have any problems with the installation of the new package. For testing installations, I basically have the stock eCS 2.2 beta II system, the only visible difference from yours is that my architecture is left at the default; i.e. i386.

[dmik]

I also checked i686 binaries here (by unpacking the python DLL and EXE manually and playing with them) — they work.

I suppose you have the new python installed after this failure anyway. Can you check if it works per se, by starting some simple python script with C:\usr\bin\python2.7.exe?

The Interrupted system call thingy actually looks like a rare and old LIBC bug which isn't completely fixed ATM (see ​http://trac.netlabs.org/libc/ticket/256), but it's a completely wild guess so far. It could be the case if python were using multiple threads for something and were trying to kill one of them for some reason but I have no knowledge about how and when python uses threads.

[David McKenna]

I also see an error updating (and re-installing) Python:

Installing : python-2.7.6-12.oc00.pentium4 1

Non-fatal POSTIN scriptlet failure in rpm package python-2.7.6-12.oc00.pentiu

LIBC PANIC!!
error: Couldn't fork %post(python-2.7.6-12.oc00.pentium4): Interrupted system
ll
LIBC fork: Child aborting fork()! rc=0xfffffffc
pid=0x0046 ppid=0x0045 tid=0x0001 slot=0x00c3 pri=0x0200 mc=0x0000 ps=0x0010
C:\USR\BIN\PYTHON2.7.EXE
LIBC066 0:00001e28
cs:eip=005b:1f3e1e28 ss:esp=0053:0012cf2c ebp=0012cf34

ds=0053 es=0053 fs=150b gs=0000 efl=00010212

eax=00000040 ebx=92a7aa00 ecx=15b10000 edx=00000018 edi=00000000 esi=15b10000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Is there a way to force installing the i386 version?

[muffetta66]

The same error installing the i386 packages, but the

yum list python*

output reports all packages as installed and python itself works fine here, also scripts.

Is there a way to get a more verbose output?

[muffetta66]

yum reinstall python output

[muffetta66]

Replying to dmik:

I also checked i686 binaries here (by unpacking the python DLL and EXE manually and playing with them) — they work.

Here too, the packages itself works fine, there is something wrong installing them on all archs

I suppose you have the new python installed after this failure anyway. Can you check if it works per se, by starting some simple python script with C:\usr\bin\python2.7.exe?

Yes, all my python scripts works fine and all packages seems updated

The Interrupted system call thingy actually looks like a rare and old LIBC bug which isn't completely fixed ATM (see ​http://trac.netlabs.org/libc/ticket/256), but it's a completely wild guess so far. It could be the case if python were using multiple threads for something and were trying to kill one of them for some reason but I have no knowledge about how and when python uses threads.

[muffetta66]

I suppose i can revert to i686 repos, do i?

[dmik]

Yes, sure, you can revert it back to i686. I and Yuri need to debug it locally somehow. I will tell you if we need anything from you. Thanks for reporting.

[dmik]

And the usual check. Please make sure you only have exactly ONE copy of libc066.dll, gcc1.dll etc on all of your hard disks.

[muffetta66]

Ok.Thousands of thanks for all your efforts, a great job!

[dmik]

You are welcome! BTW, what version of rpm do you have? yum list rpm will tell you.

[muffetta66]

Still using i386, but i solved rebuilding the database and reinstalling all packages i need without compromising the system.
The steps i made:

yum clean metadata
yum clean packages

Then I deleted all in C:\var\lib\rpm since i got some "unreadable" var/lib/rpm/Name msgs while updating/re-installing python.

yum install yum
yum install rpm

And so on.
The only problems related to this hard-workaround is that now there are the new arch packages installed and the database is clean (i suppose also a mixed state of i386 and i686 packages) so, for consistency, i think I should overwrite all, each time the errors you get are really criticals. I'll revert it back to i686 this evening using the same way.
Meanwhile i can confirm yum/rpm works fine like for you, Dmik, no install errors this time (and python itself works fine), i hope the same for i686!
Inside my logs (indeed i forgot to save outputs), i found the files in attach, i hope they can help.

[muffetta66]

All ok, i reverted to i686 packages using the same steps, no errors, all works fine, i reinstalled all packages i need. So I suppose it was simply a corrupted database. Changed Ticket properties. Since we manage a website devoted to OS/2, can we suggest our users this tricks to solves some related critical yum/rpm issues? Do you think could be useful instead to reinstall the os from scratch?
@David McKenna: follow this procedure also works for pentium4 archs?

[David McKenna]

I tried the 'yum clean metadata' and 'yum clean packages' and now everything seems to (re-)install fine with no errors. Thanks for the tip.

[muffetta66]

For me cleaning metadata and packages was not enough, maybe a higer level database corruption, however solved.
Well, this close the thread and the ticket since this Interrupted system call was a know bug, as described above and we can still live with it. thank you all.

[David McKenna]

I got this message again when I ran YUM UPDATE today, so I tried the 'clean' commands again, but it didn't work this time, so I deleted the files in C:\var\lib\rpm and tried to YUM INSTALL YUM. This turned into a disaster as YUM would crash and nothing would install. I ended up deleting my \usr and \etc trees and reinstalled from the bootstrap WPI. Everything seemed to work, but after a reboot when I try to install anything I get a message: 'There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.' I got the 'YUM-Utils' package, but yum-complete-transaction won't run. And on top of that, when I installed YUM-Utils, I got the 'LIB PANIC' error again, so I am back to square 1.

[muffetta66]

Maybe the error could not be the same, please post your logs. Did you also check for libc & friends doupes? Something inside C:\ECS\LIB or C:\OS2\DLL? Only one copy for all and once installed yum, if you still have doupes, try loading C:\USR\LIB first of all in your LIBPATH to ensure you're using latest, then search for doupes deeply, delete/unlock/uninstall others than in C:\USR\LIB and then restore your previous LIBPATH. This could be a way to check, I hope this help.
However, Lewis is working on a new bootstrap package, it could be related to your issue, please, also follow ​http://trac.netlabs.org/rpm/ticket/156 and ​http://trac.netlabs.org/rpm/ticket/158 tickets.

[David McKenna]

No dupes and C:\usr\lib is first on the LIBPATH. I once again deleted the \usr and \etc trees, but this time also deleted all \rpm and \yum folders in the \var tree, then re-installed the P4 WPI bootstrap package. Now it seems to be working properly again.

[Silvan Scherrer]

I bet you all had once the rpm 4.13 version from exp repo installed. We removed it again due to this error. But as a rule of thumb, never install something from exp repo if you are not a developer or someone who knows how to deal with rpm real good.

as all works again I close this ticket.