Bug 137672
Summary: | Boot hangs when starting X | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Philippe Rigault <prigault> | ||||||||||
Component: | hal | Assignee: | David Zeuthen <davidz> | ||||||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 3 | CC: | carstenklein, dher, mclasen, mgb | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i686 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | 0.4.6 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2005-01-20 18:53:47 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Philippe Rigault
2004-10-30 14:02:52 UTC
Just confirmed that it happens also with a vanilla 2.6.9 kernel. Using the opensource nv driver, or the binary nvidia driver? 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. Confirmed: nv driver 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. 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 ? 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. 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. 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. 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. 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. Sounds a duplicate of bug#138503 except I have no idea why this may relate to the network card setup ... Daniel 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 This does not seem to happen when booting into initlevel 3. 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... okidoc, reassigning that one to hal, Daniel Please attach the contents of lspci and lshal. David Created attachment 109014 [details]
lshal
Created attachment 109015 [details]
lspci
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? 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... 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
Please see if this is fixed with hal-0.4.5 available from Rawhide and FC3 updates - thanks 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)
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 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. 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. 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 |