Kudzu segmentation fault. Core5 Test3 upto date as of March 4, 2006

Jonathan Berry berryja at gmail.com
Mon Mar 6 04:21:06 UTC 2006

On 3/5/06, Leslie Satenstein <lsatenstein at yahoo.com> wrote:
> Jonathan,
> Here is the information you asked for. Please watch your words...
> And yet you refuse to give us any more information regarding your
> system.
> Refuse is a strong word. I hope you meant to say "are you able to give us
> more information. Here is what I need,"

Apologies for coming off harsh.  You have reported this issue numerous
times while giving very little information.  You had been asked by
Rahul at least once for more information, which you did not provide. 
Perhaps refuse is a little strong, but it did get your attention,
didn't it? : )  Again, I am sorry if I sounded rude.

> For my abilities in dealing with testing, I provided what I could.
> My system is a standard desktop AMD Semptron with 756 meg memory / 200 gig
> harddrive
> The bios is an standard AMBIOS.
> The video card, sound, eth0, and modem are what comes with the motherboard.

These descriptions are a little vague.  I understand that some people
are not intimately familiar with their system components, though : ). 
Some useful commands to help you with this are "uname -a" which will
tell you your architecture (32-bit, 64-bit, etc.) and "/sbin/lspci"
with varying options ("-v", "-n", "-vv", etc.) which will tell you
details about your hardware.  Just FYI, this information is not needed
in this case.

> From rpm -qa "kern*" here is some info
> kernel-xen-hypervisor-2.6.15-1.1977_FC5 (as part of pup
> upgrade)
> kernel-xen-hypervisor-2.6.15-1.1955_FC5 (as dvd install or
> after several pup installs).
> for kudzu
> rpm -qa "kudzu" yielded kudzu-1.2.33-1

Much better information, thanks.  As Rahul has said (at least a couple
of times) the issue is with Xen and is known.  The best thing would be
for you to find the Bugzilla entry for this and add yourself to the CC
list.  That way you can find out when they have made progress on the
issue.  Otherwise, just repeating that it is still broken isn't very

> I provided the date stamp and time stamp of the kudzu file as a way to
> identify the kudzu
>  version.

I'm not sure that is particularly useful.  Discerning version from a
timestamp sounds like a hard job.  The rpm -q data you provided above
is good.

> My testing has been done with core5 system, maintained by pup,
> and no other maintain program (not even yum).

As far as I know, pup uses yum and is simply a graphical interface to
it.  Just like anaconda (the installer) now uses yum.  Everything
Fedora is moving that way.  Similarly, yum is just a nice interface to
rpm that does dependency solving.  That's a little understated; yum
does quite a bit of work and makes installing programs barable.

> That maintenance decision I took was to keep the test environement pure.
> From my install options selections from the test3 dvd, it chose
> that hypervisor kernel. I am unable to tell you why.
> As I went through the package selections on install, and selected
> development
> libraries, and some compilers, the insaller selected what
> kernel was required. Hypervisor was the kernel chosen. I did not override
> that choice.

As Rahul said, it chose the Hypervisor kernel because you selected
Virtualization when you installed.

> If you require more specific information, send me a direct email, and I will
> forward to you, any files that you need for your research.

No, I don't think any more info is needed, thanks.

> Yes, I know the time is close to cutoff. It is Sunday, and I could be out in
> the sun, enjoying the day.

Sounds like a nice plan.  Hope you enjoyed it : ).


More information about the fedora-test-list mailing list