Description of problem: Version-Release number of selected component (if applicable): kernel-2.6.32.10-90.fc12.i686 How reproducible: Always Steps to Reproduce: 1. Update using the 2. Reboot 3. Actual results: The boot stops immediately after the "setting hostname xxxxxxxxx.xxxxxxx.xxxxxxx OK" The system seems locked up but ctl-alt-del works to reboot it. Expected results: Works like normal Additional info: The system boots normally with the previous kernel,i.e 2.6.32.9-70.fc12,i686
We, Russian fedora team (https: / / fedoraproject.org / wiki / Ru_RU / Russian_Fedora), please include an existing patch in the assembly rpm in Fedora, and not wait for upstream zip.
Sorry, previous message was error, please remove it.
Probably duplicate of 579618.
I mean that this is probably a duplicate of 578217, sorry.
Please try the 2.6.32.11 kernel when it becomes available in updates-testing
This becomes annoying now. Is it possible to retract 2.6.32.10-90.fc12.i686.PAE completely from distribution, if it is _that_ critical? I am happy to edit my grub.conf, but I am afraid that would interfere with future automatic updates. Any advice on that? Maybe just "yum uninstall 2.6.32.10"? Could moderators also have a look and mark duplicates of this report as duplicates? Here comes my complete error report, if of any help: DELL Latitude D520 does not boot with kernel-PAE-2.6.32.10-90 after auto-upgrade. The plymouth screen just freezes after some time, and I push ESC in order to access the messages: At some point, after the (usual) line dracut: Starting plymouth daemon there is a litany (thus difficult to copy) of messages, starting with (no guarantee for correct spelling): BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<f8fb5a47>] ssb_is_sprom_available+0xe/0x79 [ssb] Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0/pcmcia_socket/pcmcia_socket0/available_resources_io Modules linked in: b44(+) ssb mmc_core mii dell_laptop dcdbas iTCO_wdt iTCO_vendor_support iwl3945(+) iwlcore mac80211 snd_timer i2c_i801 snd cfg80211 joydev rfkill soundcore snd_page_alloc ext2 dm_multipath firewire_ohci yenta_socket rsrc_nonstatic firewire_core crc_itu_t i915 drm_kms_helper drm i2c_algo_bit i2c_core video output (approx. 40 more lines) I guess that the information "Process modprobe" and "Call Trace" starting with ssb_pci_get_invariante+0x1e/0x4ef and ending with sysenter_do_call+0x12/0x28 may be of additional interest. Strangely, the line "Settings hostname .. [OK]" still appears at the end; then the PC is stuck. A reboot with "Ctrl-Alt-Del" still works though. Booting on previous kernel 2.6.32.9-70.fc12.i686.PAE still works.
*** Bug 579994 has been marked as a duplicate of this bug. ***
Fails to boot on Dell Dimension 2400 also, crash in b44, hang after "Setting hostname" as above. Smolt profile: http://www.smolts.org/client/show/pub_ab0527d2-5707-489e-9071-d597f6925539
(In reply to comment #6) > This becomes annoying now. Is it possible to retract 2.6.32.10-90.fc12.i686.PAE > completely from distribution, if it is _that_ critical? I am happy to edit my > grub.conf, but I am afraid that would interfere with future automatic updates. > Any advice on that? Maybe just "yum uninstall 2.6.32.10"? I just tested 2.6.32.10-92.fc12.i686 (not PAE). It has the same problem (crash in b44), but FYI, I had modifed grub to boot 9-70 by default, and the update made the new kernel the default. So no, editing grub.conf does not interfere with updates.
(In reply to comment #9) > (In reply to comment #6) > > I am happy to edit my > > grub.conf, but I am afraid that would interfere with future automatic updates. > > Any advice on that? Maybe just "yum uninstall 2.6.32.10"? > > I just tested 2.6.32.10-92.fc12.i686 (not PAE). It has the same problem (crash > in b44), but FYI, I had modifed grub to boot 9-70 by default, and the update > made the new kernel the default. So no, editing grub.conf does not interfere > with updates. Thank you for caring :-) Presently fedora/yum/rpm keeps the last three kernels on disk (thus in grub.conf). The last but third (n-3) is erased when a new one (n) is installed (thus removed in grub.conf). Thus we will only know for sure that it does not interfere, when you will have installed two more kernels and do not end up with the wrong kernel removed from grub.conf. ;-)
More seriously: I am starting to be worried about this now. Since more than a week there is a broken kernel being distributed (probably only concerning a subset of DELL laptops), and no reaction or estimate of repair time from the experts. This is an open door for comparative criticism on my favourite Linux distribution. :-(
(In reply to comment #11) > More seriously: I am starting to be worried about this now. Since more than a > week there is a broken kernel being distributed (probably only concerning a > subset of DELL laptops), and no reaction or estimate of repair time from the > experts. > > This is an open door for comparative criticism on my favourite Linux > distribution. :-( The fix for this was submitted to updates-testing on April 6 :) https://admin.fedoraproject.org/updates/kernel-2.6.32.11-99.fc12
The 11-99 kernel fixes this for me.
The presently latest distributed kernel 2.6.32.11-99 fixes this for me (DELL Latitude D520) as well. BTW, this bug (579618) seems to be a duplicate of but 578217 as well. Thank you!
The kernel 2.6.32.11-99 is also fine for me (DELL Inspiron 1720)
*** This bug has been marked as a duplicate of bug 578217 ***