Red Hat Bugzilla – Bug 456949
anaconda segfaults after kickstart install
Last modified: 2008-12-18 14:37:10 EST
After performing a kickstart install with "reboot" in the kickstart, anaconda does not reboot. It appears that anaconda is actually segfaulting at the end of its run, and that's why it never fires the reboot command. I'll try to attach some logs as soon as I can get them. But it's tricky, because once anaconda segfaults, the system shuts down, so I can't get at the logs anymore..
Some more details: anaconda segfaults *after* running %post scripts. It says: 21:32:39 INFO : moving (1) to step copylogs 21:32:39 INFO : Copying anaconda logs 21:32:39 INFO : moving (1) to step methodcomplete 21:32:39 INFO : moving (1) to step postscripts 21:32:39 INFO : Running kickstart %%post script(s) 21:32:39 INFO : All kickstart %%post script(s) have been run 21:32:39 INFO : moving (1) to step dopostaction and then segfaults: <6>anaconda[1661]: segfault at 4b ip 0032f6eb sp bfb14814 error 4 in libc-2.8.90 .so[2cf000+170000] One other thing I noticed - udevd is no longer running. Might be related, might not.
Created attachment 312824 [details] anaconda.log
The same thing is happening with plain text mode, though the error message is slightly different: <6>anaconda[1672]: segfault at 8 ip 00007f2ee229a4a7 sp 00007fffeb1c17f0 errpr 4 in libc-2.8.90.so[7f2ee2230000+16a000] I've a feeling they're related.
Created attachment 312871 [details] anaconda.log from text mode install
I believe this is a problem with memory cleanup in rpm-python. I've narrowed it down to the problematic call in anaconda, which is a call to rpmKernelVersionList. This is an anaconda function but only does stuff with rpm headers. It's possible we are just doing something wrong. I'm sure the rpm maintainers will let us know. The code from anaconda in question is at: http://git.fedoraproject.org/git/?p=anaconda.git;a=blob;f=packages.py#l261
We should probably be doing the lock removal before creating the transaction set. I can see things going horky otherwise. Chris, Will -- do you have a good reproducer? If so, updates.img to test the hypothesis is pretty trivial to throw together.
Yep, it's just a simple matter of doing an install. I can test this out tomorrow and see if your idea is correct.
Two things: (1) Yes, we need to be removing the lock files before creating the new transaction set. (2) The lock file names have changed to 1-4 instead of 0-3, so we just need to glob for all of them and remove based on that.
1) they're not "lock files" but rather "files that contain lock names". no matter whether you open before/after creating a new transaction, you have races either way. 2) yes you need to remove all __db* files. there is no __db.000 in Berkeley DB, never has been, never changed.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This has been fixed in anaconda long since afaict: commit dea08c6442abbcd9349dc4c6c0ff408847c3926d Author: Chris Lumens <clumens@redhat.com> Date: Thu Jul 31 11:43:11 2008 -0400 Remove all the RPM lock files before creating a new transaction (#456949).