Bug 137672 - Boot hangs when starting X
Summary: Boot hangs when starting X
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: 3
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-30 14:02 UTC by Philippe Rigault
Modified: 2013-03-06 03:41 UTC (History)
4 users (show)

Fixed In Version: 0.4.6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-01-20 18:53:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
lshal (51.93 KB, text/plain)
2004-12-22 14:05 UTC, David Hernandez
no flags Details
lspci (1.63 KB, text/plain)
2004-12-22 14:06 UTC, David Hernandez
no flags Details
output of hald --verbose (75.10 KB, text/plain)
2005-01-06 17:31 UTC, David Hernandez
no flags Details
output of hald --verbose (62.74 KB, text/plain)
2005-01-14 14:31 UTC, David Hernandez
no flags Details

Description Philippe Rigault 2004-10-30 14:02:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)

Description of problem:
System freezes on boot when X is started.

Potential showstopper for FC3 IMHO.

FC3-rc2
kernel 2.6.9-1.643smp
kernel 2.6.9-1.643

I am not quite sure about the component because this happens both with graphical and text boot, feel free to reassign component.

Happens on a Dell Inspiron 5160 with NVIDIA GeForce FX Go 5200





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


How reproducible:
Always

Steps to Reproduce:
1. Boot the system -> freeze on boot during X launch, forcing a hard poweroff
2. Reboot (unclean) -> System boots normally
3. Next reboot (normal) -> same as #1, and so on.
    

Expected Results:  When X can't start, the system should gracefully boot into text mode, and absolutely not freeze.

Additional info:


This happens whether ot not the following boot options are enabled:
  rhgb (which is why I think this might have nothing to do with rhgb)
  quiet
  selinux=0

This happens on both kernels (up and smp)

In other words, it is definitely NOT the same as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124384, which was triggered only with the rhgb option.

Comment 1 Philippe Rigault 2004-10-30 23:34:20 UTC
Just confirmed that it happens also with a vanilla 2.6.9 kernel. 

Comment 2 Bill Nottingham 2004-11-01 21:07:14 UTC
Using the opensource nv driver, or the binary nvidia driver?

Comment 3 Philippe Rigault 2004-11-01 21:47:14 UTC
I did not install any nvidia binary driver. 
So it must be the opensource nv driver. I say must be, because I do 
not have access to the box right now. I can confirm this in a couple 
of hours. 

Comment 4 Philippe Rigault 2004-11-01 22:43:29 UTC
Confirmed: nv driver 

Comment 5 Philippe Rigault 2004-11-01 22:58:10 UTC
This might have nothing to do with X 
 
I changed the default runlevel to 3 in /etc/inittab and here is what 
happens: 
 
1. Boot the system -> freeze on text login prompt 
 
Fedora Core release 2.92 (FC3 Test 3) 
Kernel 2.6.9-1.643smp on an i686 
 
canard login: _ <- Cursor blinks, but system does not respond 
 
2. Reboot (unclean) -> System boots normally 
3. Next reboot (normal) -> same as #1, and so on. 
 
I did three cycles like this to confirm this behaviour. 
This makes the severity of this bug even worse. 
 

Comment 6 Philippe Rigault 2004-11-02 01:38:05 UTC
OK, I think I am making progress, although in an unanticipated 
direction ;-) 
I Wanted to see if I could ssh into the box while "frozen" from the 
console, so I decided to configure the network. Aha! 
 
eth0 set to start on boot -> system comes up OK all the time 
 
eth0 set to NOT start on boot -> system exhibits behaviour described 
above. 
 
In other words, this simple change in /etc/sysconfig/network-scripts 
ONBOOT=YES -> ONBOOT=NO 
creates the following behaviour: 
1. Boot the system -> freeze on boot, forcing a hard poweroff 
2. Reboot (unclean) -> System boots normally 
3. Next reboot (normal) -> same as #1, and so on. 
 
Maybe this is pam-related. Ideas ? 
 

Comment 7 Philippe Rigault 2004-11-03 16:22:26 UTC
This does not happen on the two other configurations on which I 
installed FC3 test3: 
 - FC3-rc5 (2.6.9-1.649) on SunW1100z (x86_64). 
 - FC3-rc2 (2.6.9-1.643) on Dell Inspiron 7000 (i386) 
 
I can only reproduce it on the Dell 5160. 
 

Comment 8 Carsten Klein 2004-11-05 11:48:50 UTC
I just installed FC3T3 after destroying my previous FC3T2 system by
updating via up2date (but this is another story...).

I did a "install all packages" installation type.

After having setup the system with all my applications I shut down and
rebooted the system. 

Besides other problems which I will not discuss here, the graphical
boot hangs after starting up the haldaemon process.

I figured that it might be that process so I just disabled it, but to
no avail. Disabling the graphical boot on startup did the trick. It
seems that "rhgb --sysinit" at the end of rc.sysinit does thrash the
system, or at least the instance of the Xorg server that is currently
running.

I had the following configurations tried:

Xorg with the generic nv driver
and with the original and latest nvidia drivers.

My system is a Athlon XP 1800+ and no other non-standard hardware
besides an additional internal audio-card.

The same happens on my notebook after updating the existing FC3T2
installation with the updated packages from up2date.

The notebook is a Sony VAIO with a NVIDIA gfx card (same
configurations tried) and an Athlon XP 2000+.

Hope this helps to find the bug.

An intermediate solution however is to disable graphical boot
in /etc/sysconfig/init, setting GRAPHICAL=no.


Comment 9 Philippe Rigault 2004-11-09 04:38:08 UTC
Reproduced on FC3 final.  
 
Carsten, you seem to describe an entirely different thing. I 
originally thought this was related to X and rhgb, but I now think 
they have nothing to do with the bug. 
 
Here is what I reproduced today: 
 
1. Fresh install on Dell Inspiron 5160, configured network interface 
eth0 (static IP, hostname, gatweay), but set it to *NOT* start 
automatically at boot. Install proceeds fine, Reboot at the end. 
 
2. Firstboot: configure timezone, etc. goes fine. Click Finish -> 
Hangup. Have to hard poweroff. 
 
3. Boots again (of course, warning message about previous unclean 
shutdown), this time it boots fine all the way. Run 'reboot' -> 
Hangup again. 
 
4. Configure network to start at boot -> boots fine each time. 
 
I am really puzzled about this being caused by a network device *NOT* 
enabled. 

Comment 10 Carsten Klein 2004-11-09 05:43:23 UTC
Thanks again for the network tip, Phillippe, I remember having two
network cards in my system, one internal and a second one that is
external. The external is properly configured and enabled at bootup,
the second is not configured and also enabled at bootup - I believe it
tries to get its configuration via DHCP.

Yet, the internal is not connected to any network and so it eventually
times-out during boot and is disabled. Perhaps that is causing the
problems here. Since I do not have a second networking cable I cannot
test this at the moment.



Comment 11 PJ B 2004-11-14 08:09:24 UTC
I am having the same problem. My system will hang just before the gdm
login screen.

I have a Dell 700m Inspiron with Intel 852 Video card.  I have two
ethernet cards.  eth0 is a built in ethernet, eth1 is a Intel 2200BG
wireless card. I'm running Fedora Core 3, I upgraded from Core 2.

If I boot with eth0 enabled and a cable plugged in, the computer will
boot fine. But if I don't have eth0 enabled, or just not plugged into
a network my computer will hang just before the login screen, every
other time.
  Meaning that it will boot fine once, but the second boot will lock
up, then boot fine the next time. Over and over like this.
  It does not matter about my wireless if it logs into a network or not.

Also another oddity that happens, kudzu will detect a "new" video card
always on the boot that will halt, but never on the boot that will
work.  My /etc/sysconfig/hwconf file has the video card listed, and
enabled, but right after a bad boot the file has changed to say
disabled by my video card.


Comment 12 Daniel Veillard 2004-11-30 15:28:36 UTC
Sounds a duplicate of bug#138503 except I have no idea why this
may relate to the network card setup ...

Daniel

Comment 13 Philippe Rigault 2004-11-30 22:03:21 UTC
Looks like bug#138503 is an xorg-x11 problem. 
As I said in comment #5, this is happening even at initlevel 3, so 
xorg-x11 is not the culprit here IMO. 
 
PJ, can you try at initlevel 3 to see if this happens to you too ? 
 
I'll investigate /etc/sysconfig/hwconf too, interesting. 
 
Cheers, 
 
Philippe 

Comment 14 PJ B 2004-12-08 01:28:58 UTC
This does not seem to happen when booting into initlevel 3.

Comment 15 David Hernandez 2004-12-17 13:49:04 UTC
It seems to be the haldaemon causing this once every two reboot failure.

I solved this by preventing the haldaemon to start.
/sbin/chkconfig haldaemon off

But the USB storage won't be automatically detected...

Comment 16 Daniel Veillard 2004-12-21 15:50:11 UTC
okidoc, reassigning that one to hal,

Daniel

Comment 17 David Zeuthen 2004-12-21 16:20:29 UTC
Please attach the contents of lspci and lshal.

David

Comment 18 David Hernandez 2004-12-22 14:05:19 UTC
Created attachment 109014 [details]
lshal

Comment 19 David Hernandez 2004-12-22 14:07:03 UTC
Created attachment 109015 [details]
lspci

Comment 20 David Zeuthen 2005-01-03 19:40:35 UTC
Since comment 18 contained the output of lshal it appears that the
haldaemon service could be started yes? Does this mean that this only
happens when haldaemon is starting at boot time? Or is it possible to
start up haldaemon when the system has booted?

Comment 21 David Hernandez 2005-01-04 14:50:32 UTC
It happens both when haldaemon starts at boot time and when started
after the system has booted:

 performing a normal boot

$ /etc/rc.d/init.d/haldaemon start    ->-> system hangs
 performing a hard reboot

$ /etc/rc.d/init.d/haldaemon start    ->-> OK
 performing a normal reboot

$ /etc/rc.d/init.d/haldaemon start    ->-> system hangs
 performing a hard reboot

$ /etc/rc.d/init.d/haldaemon start    ->-> OK
$ /etc/rc.d/init.d/haldaemon restart  ->-> OK

and so on...

Comment 22 David Hernandez 2005-01-06 17:31:59 UTC
Created attachment 109433 [details]
output of hald --verbose

I don't know if it will help, but here is a file in attachment resulting from
the command:
/usr/sbin/hald --daemon=off --verbose=yes 2> haldLog

What I exactly done:

-hald was desactivated at starup

boot
$ /usr/sbin/hald --daemon=off --verbose=yes  
	 ->-> hald succesfully start
reboot
$ /usr/sbin/hald --daemon=off --verbose=yes 2> haldLog
	 ->-> system hangs needing an hard reboot

Comment 23 David Zeuthen 2005-01-13 20:00:47 UTC
Please see if this is fixed with hal-0.4.5 available from Rawhide and
FC3 updates - thanks

Comment 24 David Hernandez 2005-01-14 14:31:24 UTC
Created attachment 109778 [details]
output of hald --verbose

It is not fixed, the problem is the same with hal-0.4.5

As above, see in attachment the output of
/usr/sbin/hald --daemon=off --verbose=yes 2> haldLog
(which caused the system to hang)

Comment 25 Philippe Rigault 2005-01-14 19:40:04 UTC
I confirm that the problem looks indeed as hal being the culprit, and 
that is not fixed with hal-0.4.5.  
(note: no other FC3 update applied, e.g kernel = 2.6.9-1.667)  
 
1. Proper boot  
2. Login as root  
3. start hald:  /usr/sbin/hald --daemon=no --verbose=yes 
-> hangup needing hard reboot 
4. Hard reboot 
5. Login as root 
6. start hald -> OK 
7. goto 1. 
 
When the system hangs, this is the last line on the  
console:  
14:37:34.646 [I] linux/ossspec.c:785: handling /sys/class/net/eth0 
net  
  
   

Comment 26 David Zeuthen 2005-01-17 20:30:34 UTC
I'm pretty sure that I've got a fix for this one; please try these
packages 

 http://people.redhat.com/davidz/hal-cvs20050117/

This contains a workaround for the broken b44 driver that doesn't like
to have the mii registers looked at. You will need a 2.6.10 kernel
from either Rawhide or FC3 updates. Thanks.

Comment 27 David Zeuthen 2005-01-20 18:53:47 UTC
So, I've got someone on the hal mailing list to test this

 http://lists.freedesktop.org/archives/hal/2005-January/001686.html

I believe this is exactly the same issue so I'm closing this bug,
since this is fixed in hal-0.4.6 which will be in Rawhide and FC3
updates soon.

Comment 28 Tom Wood 2005-02-01 12:58:34 UTC
hal-0.4.7-1.FC3 generates a segfault for me when I run

/usr/sbin/hald --daemon=no --verbose=yes

hald.c:394: hal 0.4.7
hald.c:398: will not daemonize
Segmentation fault


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