Bug 143913 - anaconda segfault during Preparing to install
Summary: anaconda segfault during Preparing to install
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-01 09:39 UTC by Richard Hill
Modified: 2015-01-04 22:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-30 09:31:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Richard Hill 2005-01-01 09:39:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6)
Gecko/20040510

Description of problem:
Update or Install.

Progress bar gets to around 75%, then anaconda segfaults.

Version-Release number of selected component (if applicable):
FC3

How reproducible:
Always

Steps to Reproduce:
1. Install or Update an existing FC2 (X86_64) installation
2.
3.
    

Additional info:

<ALT><F1>
Starting graphical installation...
install exited abnormally

<ALT><F3>
moving(1) to step install_packages
setting file_context_path to
/etc/selinux/targeted/contexts/files/file_contexts

<ALT><F4>
<7> Losing some ticks
<4> warning: too many lost ticks
<4> Your time source seems to be instable or some driver is hogging
interrupts
<4> rip inode_timers_differ +0x0/0x3c
<6>anaconda[352] segfault xxxx rip xxxx rsp xxxxx error 4

update.log
Upgrade Dependency: Needs (('samba-client', '3.0.3', '5'),
('samba-common', '0:3.0.3'), 8, None, 0), automatically added.
Upgrade Dependency: Needs (('samba', '3.0.3', '5'), ('samba-common',
'0:3.0.3'), 8, None, 0), automatically added.
Upgrade Dependency: Needs (('gcc-g77', '3.3.3', '7'), ('libf2c',
'3.3.3-7'), 8, None, 0), automatically added.
Upgrade Dependency: Needs (('db4-utils', '4.2.52', '3.1'), ('db4',
'4.2.52-3.1'), 8, None, 0), automatically added.
Upgrade Dependency: Needs (('db4-tcl', '4.2.52', '3.1'), ('db4',
'4.2.52-3.1'), 8, None, 0), automatically added.
Upgrade Dependency: Needs (('ORBit2-devel', '2.10.0', '2'), ('ORBit2',
'2.10.0'), 8, None, 0), automatically added.
Upgrade Dependency: Needs (('evolution', '1.4.6', '2'),
('libgal-2.0.so.6', None), 0, None, 0), automatically added.
Upgrade Dependency: Needs (('balsa', '2.0.17', '1'),
('libgal-2.0.so.6', None), 0, None, 0), automatically added.
Upgrade Dependency: Needs (('evolution', '1.4.6', '2'),
('libgal-a11y-2.0.so.6', None), 0, None, 0), automatically added.

# uname -a
Linux xxxx.localdomain 2.6.10-rc3-xxxxx #1 Sun Dec 5 10:21:41 CET 2004
x86_64 x86_64 x86_64 GNU/Linux

X86_32 FC2 -> FC3 update on the same system worked.

Comment 1 Paul Nasrat 2005-01-04 16:56:24 UTC
The messages on tty4 imply not good things happening.  Can you get some more
detail with Magic SysRq task dump on tty2 say:

Alt-SysRq + t

Does it occur if you try the installer with:

linux acpi=off



Comment 2 Richard Hill 2005-01-04 18:21:50 UTC
acpi=off made no difference (plus same messages about lost ticks).

[Alt][Sysreq][t]

"SysRq: Show State"

Nothing else printed.

FC2 (64) & FC3 (32 bit) installed ok on this system. CPU is an FX55 on an MSI 
K8t Neo2



Comment 3 Paul Nasrat 2005-01-04 18:33:36 UTC
Loglevel probably too low can you do 

[Alt][Sysreq][9] before doing the [Alt][SysRq][t]

Comment 4 Richard Hill 2005-01-05 13:29:44 UTC
[Alt][Sysreq][9] before doing the [Alt][SysRq][t]

Produced screen after screen of data, however it didn't appear to get 
written to any logfile.

I noted some items near the end ...

Call Trace: <xxx>{worker_thread+0} <xxxx> {worker_thread+219}

worker_function+0
kevent_create_thread+0  child_rip+0  selinux_inode_permissions+0

Is this useless?  Is there a way to save the printed data ?




Comment 5 Paul Nasrat 2005-01-10 15:17:17 UTC
Does a text based install work?  Do you get more context from kernel messages?

Comment 6 Richard Hill 2005-01-10 18:59:08 UTC
Same result. Gets to an indicated 80%, then dies.  Same output from [Alt]
[SysRq][t] (as far as I could see)
 

Comment 7 Richard Hill 2005-01-10 18:59:23 UTC
Same result. Gets to an indicated 80%, then dies.  Same output from [Alt]
[SysRq][t] (as far as I could see)
 

Comment 8 Paul Nasrat 2005-01-10 19:09:57 UTC
How about with:

acpi=off noapic

Comment 9 Richard Hill 2005-01-11 06:53:58 UTC
Same result. Graphic or Text

Comment 10 Richard Hill 2005-01-20 10:47:44 UTC
The status is still NEEDINFO. Is there anything else I can provide?

Comment 11 Paul Nasrat 2005-02-01 19:44:58 UTC
I can't see anything obvious - Dave any ideas?

Comment 12 Dave Jones 2005-07-15 19:09:14 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 13 Dan Carpenter 2005-07-21 08:32:55 UTC
> Losing some ticks
> warning: too many lost ticks
> Your time source seems to be instable or some driver is hogging interrupts

Those messages are harmless.

> rip inode_timers_differ +0x0/0x3c

I don't know what that means and I can't find a single reference to
inode_timers_differ on google.  Weird.  This might indicate a kernel bug or a
hardware problem.

<6>anaconda[352] segfault xxxx rip xxxx rsp xxxxx error 4
This means that anaconda segfaulted and its PID was 352.  This doesn't indicate
a kernel bug.

The stack trace text is actually written to a log file.  It's in /tmp/ on tty2.
  I don't know if you're still able to access tty2 if anaconda segfaults... grep
for it.  scp it to a different computer and post it here.

Also could you run a pass of memtest on the system (www.memtest.org)?  Unpacking
RPMs is memory intensive.  It's nice to eliminate that as a problem.



Comment 14 Dan Carpenter 2005-07-21 08:45:46 UTC
Ah...  You have a typo.  It should be:
> rip inode_times_differ

It's connected with the previous message about hogging interrupts and it's
harmless.  There isn't anything to indicate whether this is a kernel problem, an
anaconda problem or a hardware problem.

Please do the memtest test and let us know.




Comment 15 Dave Jones 2005-08-04 05:55:45 UTC
if you switch to tty2, you should be able to run 'dmesg', and get a dump of the
kernel message ring buffer. This may have something more useful than the above
messages.




Note You need to log in before you can comment on or make changes to this bug.