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: segfault at 4b ip 0032f6eb sp bfb14814 error 4 in libc-2.8.90
One other thing I noticed - udevd is no longer running. Might be related, might not.
Created attachment 312824 [details]
The same thing is happening with plain text mode, though the error message is
<6>anaconda: segfault at 8 ip 00007f2ee229a4a7 sp 00007fffeb1c17f0 errpr 4
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:
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.
(1) Yes, we need to be removing the lock files before creating the new
(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,
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:
This has been fixed in anaconda long since afaict:
Author: Chris Lumens <email@example.com>
Date: Thu Jul 31 11:43:11 2008 -0400
Remove all the RPM lock files before creating a new transaction (#456949).