I updated to kernel-2.6.25-0.200.rc8.git3.fc9.i686 from .185 and the new kernel fails to boot. It gets stuck during the graphical phase and hangs altogether - I have to alt-sysrq-b to restart. It seems there is no useful stuff in /var/log/messages.
In /var/log/messages I get:
Apr 7 19:31:59 rawhide yum: Installed: kernel-2.6.25-0.200.rc8.git3.fc9.i686
Then rebooted... then next few lines I think show a kde crash during shutdown.
Apr 7 19:33:05 rawhide kernel: klauncher[2464]: segfault at 8048814 ip 009b9da8sp bfa890f0 error 7 in libX11.so.6.2.0[9a4000+fd000] Apr 7 19:33:07 rawhide init: tty5 main process (2284) killed by TERM signal Apr 7 19:33:07 rawhide init: tty2 main process (2285) killed by TERM signal Apr 7 19:33:07 rawhide init: tty3 main process (2286) killed by TERM signal Apr 7 19:33:07 rawhide init: tty1 main process (2287) killed by TERM signal Apr 7 19:33:07 rawhide init: tty6 main process (2288) killed by TERM signal Apr 7 19:33:07 rawhide init: tty4 main process (2282) killed by TERM signal Apr 7 19:33:07 rawhide acpid: exiting Apr 7 19:33:08 rawhide kernel: audit(1207593188.177:24): audit_pid=0 old=1878 by auid=4294967295 res=1 Apr 7 19:33:08 rawhide auditd[1878]: The audit daemon is exiting. Apr 7 19:33:08 rawhide avahi-daemon[2055]: Got SIGTERM, quitting. Apr 7 19:33:08 rawhide avahi-daemon[2055]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.65. Apr 7 19:33:09 rawhide console-kit-daemon[2075]: GLib-CRITICAL: g_async_queue_unref: assertion `queue->waiting_threads == 0' failed Apr 7 19:33:09 rawhide named[1903]: received control channel command 'stop' Apr 7 19:33:09 rawhide named[1903]: shutting down: flushing changes Apr 7 19:33:09 rawhide named[1903]: stopping command channel on 127.0.0.1#953 Apr 7 19:33:09 rawhide named[1903]: no longer listening on ::1#53 Apr 7 19:33:09 rawhide named[1903]: no longer listening on 127.0.0.1#53 Apr 7 19:33:09 rawhide named[1903]: exiting Apr 7 19:33:12 rawhide rpc.statd[1781]: Caught signal 15, un-registering and exiting. Apr 7 19:33:12 rawhide pcscd: pcscdaemon.c:572:signal_trap() Preparing for suicide Apr 7 19:33:12 rawhide console-kit-daemon[2075]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Apr 7 19:33:13 rawhide pcscd: readerfactory.c:1379:RFCleanupReaders() entering cleaning function Apr 7 19:33:13 rawhide pcscd: pcscdaemon.c:532:at_exit() cleaning /var/run Apr 7 19:33:13 rawhide rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w" Apr 7 19:33:13 rawhide kernel: Kernel logging (proc) stopped. Apr 7 19:33:13 rawhide rsyslogd: [origin software="rsyslogd" swVersion="3.14.1" x-pid="1863" x-info="http://www.rsyslog.com"] exiting on signal 15.
The boot of the new kernel should have put some messages here but it failed to do so as far as I can see.
Apr 7 19:35:36 rawhide kernel: imklog 3.14.1, log source = /proc/kmsg started. Apr 7 19:35:36 rawhide kernel: Inspecting /boot/System.map-2.6.25-0.185.rc7.git6.fc9.i686 Apr 7 19:35:36 rawhide kernel: Loaded 28623 symbols from /boot/System.map-2.6.25-0.185.rc7.git6.fc9.i686. Apr 7 19:35:36 rawhide kernel: Symbols match kernel version 2.6.25. Apr 7 19:35:36 rawhide kernel: No module symbols loaded - kernel modules not enabled. Apr 7 19:35:36 rawhide kernel: Initializing cgroup subsys cpuset Apr 7 19:35:36 rawhide kernel: Initializing cgroup subsys cpu Apr 7 19:35:36 rawhide kernel: Linux version 2.6.25-0.185.rc7.git6.fc9.i686 (mockbuild@) (gcc version 4.3.0 20080326 (Red Hat 4.3.0-5) (GCC) ) #1 SMP Tue Apr 1 13:48:40 EDT 2008 Apr 7 19:35:36 rawhide kernel: BIOS-provided physical RAM map: and so on to normal boot with kernel .185
Anyone else getting a problem with .200 ?
On Mon, Apr 7, 2008 at 2:50 PM, Mike mike.cloaked@gmail.com wrote:
I updated to kernel-2.6.25-0.200.rc8.git3.fc9.i686 from .185 and the new kernel fails to boot. It gets stuck during the graphical phase and hangs altogether - I have to alt-sysrq-b to restart. It seems there is no useful stuff in /var/log/messages.
Is it possible to hook up a serial console to get output from there? I'm running this kernel right now on x86_64 and not having any issues.
Jon Stanley <jonstanley <at> gmail.com> writes:
Is it possible to hook up a serial console to get output from there? I'm running this kernel right now on x86_64 and not having any issues.
I am afraid I have no facility for a serial console unfortunately.
I guess I will wait for the next kernel and test that.
Mike wrote:
Anyone else getting a problem with .200 ?
Working on my i686 machine, so your problem is specific to your hardware or config. Did you try the .201 today yet?
Mike <mike.cloaked <at> gmail.com> writes:
Andrew Farris <lordmorgul <at> gmail.com> writes:
Working on my i686 machine, so your problem is specific to your hardware or config. Did you try the .201 today yet?
OK I tried .201 and also pulled .204 from koji - all these won't boot but I have discovered where all these kernels hang.
By clicking to show details during the graphical boot these kernels all hang starting wpa_supplicant - I have a usb wireless adapter using the rt73usb module. Up to kernel .185 the system boots fine with this adapter plugged in. All kernels after that hang at wpa_supplicant set to start as a daemon service.
By booting without the usb wireless adapter plugged in the boot continues normally (but with no wireless networking)
On Mon, 2008-04-07 at 20:54 +0000, Mike wrote:
OK I tried .201 and also pulled .204 from koji - all these won't boot but I have discovered where all these kernels hang.
By clicking to show details during the graphical boot these kernels all hang starting wpa_supplicant - I have a usb wireless adapter using the rt73usb module. Up to kernel .185 the system boots fine with this adapter plugged in. All kernels after that hang at wpa_supplicant set to start as a daemon service.
By booting without the usb wireless adapter plugged in the boot continues normally (but with no wireless networking)
Uh, the kernel has already booted by that point, you're looking at the Fedora init process, after kernel is up. The kernels boot, your init process is what fails.
Unless you're using wpa_supplicant manually, the service doesn't need to run. Disable it, as NetworkManager will use it on demand.
Jesse Keating <jkeating <at> redhat.com> writes:
Unless you're using wpa_supplicant manually, the service doesn't need to run. Disable it, as NetworkManager will use it on demand.
I do need to run wpa_supplicant during boot - as I have systems where the user does not want to know about using NetworkManager and just wants to fire up the system and have the network running without intervention - and I want to be able to access the system even before the user logs in - I believe that NM only starts once a user logs in to the desktop.
Hence I start wpa_supplicant as a daemon during boot on all my laptops and then call for an ip address via dhclient run from rc.local - that way the system has a wireless connection even if it has booted but the local user is not yet on a desktop. This is useful so that only specific networks defined in the wpa_supplicant.conf will be connected, keeping the system under control and secure.
Anyway I presume that this facility will become usable again soon.
On Mon, Apr 7, 2008 at 1:08 PM, Mike mike.cloaked@gmail.com wrote:
I do need to run wpa_supplicant during boot - as I have systems where the user does not want to know about using NetworkManager and just wants to fire up the system and have the network running without intervention - and I want to be able to access the system even before the user logs in - I believe that NM only starts once a user logs in to the desktop.
Can't you fiddle with running nm-applet as user gdm from the gdm login screen... just as gnome-power-manager is being run currently by default?
I suspect that this is the long term direction...generally...but you might be able to get a glimpse of the future by enabling it for the gdm user on the systems running f9beta.
-jef"The future Conan?"spaleta
Jeff Spaleta <jspaleta <at> gmail.com> writes:
Can't you fiddle with running nm-applet as user gdm from the gdm login screen... just as gnome-power-manager is being run currently by default?
Just by the way - I use kdm/kde !
Mike <mike.cloaked <at> gmail.com> writes:
By booting without the usb wireless adapter plugged in the boot continues normally (but with no wireless networking)
Once the system is booted with .204 as soon as I plugged in the wireless adapter the system hung - the only entry in /var/log/messages was: Apr 7 21:55:37 rawhide kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2
The hardware is http://www.smolts.org/client/show/pub_c02c95fc-b8de-4916-85fe-cf1c96f33f7e
Mike wrote:
Mike <mike.cloaked <at> gmail.com> writes:
By booting without the usb wireless adapter plugged in the boot continues normally (but with no wireless networking)
Once the system is booted with .204 as soon as I plugged in the wireless adapter the system hung - the only entry in /var/log/messages was: Apr 7 21:55:37 rawhide kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2
The hardware is http://www.smolts.org/client/show/pub_c02c95fc-b8de-4916-85fe-cf1c96f33f7e
This may be related to https://bugzilla.redhat.com/show_bug.cgi?id=440648 System hanging when NetworkManager starts, with a wireless adapter card installed. I haven't yet pulled the card out to see if NM can start without it in there. Try disabling NM and see if you can boot with the card installed, wpa_supplicant should not start either so disable that too.
Andrew Farris <lordmorgul <at> gmail.com> writes:
This may be related to https://bugzilla.redhat.com/show_bug.cgi?id=440648 System hanging when NetworkManager starts, with a wireless adapter card installed. I haven't yet pulled the card out to see if NM can start without it in there. Try disabling NM and see if you can boot with the card installed, wpa_supplicant should not start either so disable that too.
This does look a bit similar to your bug - it looks to me like the problem starts as soon as the card is plugged in and so looks related to the moment that the kernel module is loaded. In my case NM is off via chkconfig anyway, and wpa_supplicant does not start if the card is missing - and remains off. But as soon as the adapter goes into the usb slot the system hard hangs instantly... so it does not appear to be related to NM or wpa_supplicant but to the kernel module (rt73usb in my case)
Mike wrote:
But as soon as the adapter goes into the usb slot the system hard hangs instantly... so it does not appear to be related to NM or wpa_supplicant but to the kernel module (rt73usb in my case)
Ok you should probably get that reported into bz separately against kernel.