+++ This bug was initially created as a clone of Bug #219715 +++ [...snip...] -- Additional comment from craigwhite on 2007-11-12 18:32 EST -- Nothing has changed on Fedora 8 - in fact, it's gotten worse. I could use Fedora 7 x86_64 without any special boot parameters but of course, grub never worked but lilo has indeed worked. All of my mentions here refer only to x86_64 as I gave up trying to run i386 on these systems a while back. Upgraded to Fedora 8 and simply cannot even boot from Rescue disc - it hangs with an error... PCI: MSI quirk detected. MSI deactivated pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI Exception (processor_core-0819): AE_NOT_FOUND, Processor Device is not present [20070126] *** last line repeats 2 more times *** Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux apgart interface v0.102 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled and there it stops...never proceeds. The only way I've been able to get Fedora 8 Linux Rescue CD or CD Image from boot.iso to boot is to pass 'acpi=off' I will attach dmidecode and lspci -- Additional comment from craigwhite on 2007-11-12 18:33 EST -- Created an attachment (id=256041) output of dmidecode on Dell Optiplex 320 -- Additional comment from craigwhite on 2007-11-12 18:34 EST -- Created an attachment (id=256051) output of lspci -vv from Dell Optiplex 320 -- Additional comment from craigwhite on 2007-11-12 18:40 EST -- I'm gonna vent a bit here... This isn't getting fixed. See bugzilla 219043 https://bugzilla.redhat.com/show_bug.cgi?id=219043 This all began on Fedora 5 (Fedora 6 for me) and continued on Fedora 7 and now has gotten worse in Fedora 8 Grub has NEVER worked on these Dell Optiplexes...as far as I can tell, for anyone ever. I am using Lilo-22.8 I could get i386 working only if I passed ridiculous kernel parameters such as pci=nomsi all-generic-ide but until Fedora 8 (2.6.23.1-49.fc8) I didn't have to sacrifice the unborn on x86_64. Now it requires both Lilo and apci=off PLEASE - PLEASE - PLEASE do something
just adding myself to cc
acpi=off is almost never needed. See: https://fedoraproject.org/wiki/KernelCommonProblems
Replying to <a href="https://bugzilla.redhat.com/show_bug.cgi?id=379201#c2">Comment #2</a> comments pertain to Fedora 8-x86_64 rescue disk boot * pci=noacpi gets further, but hangs after 'running /sbin/loader' (i.e. mounts /proc, /dev, /dev/pts, /sys remounts root filesystem, mounts /tmp, running install...) * nolapic hangs somewhere else in boot process - harder to identify but if pressed, I will describe * noapic hangs exactly at same place as if I didn't append noapic to kernel parameters * noapictimer hangs exactly the same place as pci=noacpi * earlyprintk=vga hangs exactly the same place as original bug report * edd=skipmbr hangs exactly the same place as original bug report * edd=off hangs exactly the same place as original bug report * clocksource=acpi_pm nohz=off highres=off boots (slow like acpi=off) * nohz=off highres=off hangs same as pci=noacpi * clocksource=acpi_pm nohz=off hangs per my original bug report * clocksource=acpi_pm highres=off boots (slow like acpi=off) I'm trying to work with you guys - specific needs?
(In reply to comment #3) > Replying to <a > href="https://bugzilla.redhat.com/show_bug.cgi?id=379201#c2">Comment #2</a> > > comments pertain to Fedora 8-x86_64 rescue disk boot > > * pci=noacpi > gets further, but hangs after 'running /sbin/loader' (i.e. mounts /proc, /dev, > /dev/pts, /sys remounts root filesystem, mounts /tmp, running install...) > possibly: pci=noacpi clocksource=acpi_pm > * clocksource=acpi_pm highres=off > boots (slow like acpi=off) How slow?
* pci=noacpi clocksource=acpi_pm seems to be the best combination of all How slow? hard to say exactly because I am used to kickstart installs and nor really in tune with what should be the speed and so it may actually take a long time to read the rescue loader code off CD (perhaps 90 seconds until first question about keyboard/language). Thanks
As to the 'mighty big hammer' of acpi=off... Appending 'pci=noacpi clocksource=acpi_pm' to kernel parameters of grub doesn't fix grub boot issues and I understand that this is kernel bugzilla and not overly interested in grub issues. Appending 'pci=noacpi clocksource=acpi_pm' to kernel parameters on lilo.conf does indeed boot and seems to run fairly well on initial testing (speed, startup daemon spew). Perhaps speed issue only relates to CD which I may fail to anticipate the speed of reading from resuce CD. Craig
(In reply to comment #6) > Appending 'pci=noacpi clocksource=acpi_pm' to kernel parameters of grub doesn't > fix grub boot issues and I understand that this is kernel bugzilla and not > overly interested in grub issues. > not really, but have you reinstalled the latest grub? The package may get updated on the filesystem, but does not automatically get installed to the boot sector.
not exactly sure what you are telling me (#7) grub is 0.97-19.x86_64 I do execute grub-install /dev/sda and it reports back that if my /dev/sda is [hd0], I'm good to go it never does boot stage 1.5 (I think is where it stops). do I need to do something other than 'grub-install /dev/sda' ? Obviously, I am running 'lilo -v' after all attempts at getting grub to work fail.
Created attachment 258581 [details] New output of dmidecode after BIOS update from Dell output of diff -u from new run of dmidecode after BIOS update and previously uploaded dmidecode $ diff -u ~/dmidecode.txt ~/Desktop/dmidecode.txt --- /home/storage/users/craig/dmidecode.txt 2007-11-14 12:10:58.000000000 -0700 +++ /home/storage/users/craig/Desktop/dmidecode.txt 2007-11-14 12:12:39.000000000 -0700 @@ -1,6 +1,6 @@ # dmidecode 2.7 SMBIOS 2.3 present. -68 structures occupying 2298 bytes. +68 structures occupying 2297 bytes. Table at 0x000F0450. Handle 0xDA00, DMI type 218, 35 bytes. @@ -20,8 +20,8 @@ Handle 0x0000, DMI type 0, 24 bytes. BIOS Information Vendor: Dell Inc. - Version: 1.1.10 - Release Date: 09/13/2007 + Version: 1.1.5 + Release Date: 03/27/2007 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 512 kB @@ -586,7 +586,7 @@ Handle 0xDE00, DMI type 222, 13 bytes. OEM-specific Type Header and Data: - DE 0D 00 DE C1 01 00 00 07 11 13 09 03 + DE 0D 00 DE C1 01 FF FF 00 00 00 00 00 Handle 0x7F00, DMI type 127, 4 bytes. End Of Table
I'll work out grub issues elsewhere, I am interested to see if we can make some progress on this chipset combination - absolutely latest BIOS from Dell installed - thanks
Is there any hope for 2.6.23 kernel to be able to boot on these systems without the need for kernel parameters 'pci=noacpi clocksource=acpi_pm' ? Is there any more information I can provide while I still have one of these desktop systems on my desk?
Dell released BIOS 1.1.11 last week. With that installed, the only kernel parameter I needed to get Fedora 8 (2.6.23.9-85.fc8) to boot was clocksource=acpi_pm. With that I now actually see 2 CPU's via hyperthreading. Before I had to use pci=noacpi also and that made the kernel only see one CPU. This is on an already installed system using lilo to boot.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
In testing Fedora 10, I tried to run a live CD to install on a Dell Optiplex 320 with an intel chipset. The live cd would not boot past 'Loading initrd0.img....ready.' It gets here and hangs each time. I tested the same CD on several other dell PC's including an optiplex 330, Vostro 1500 notebook and a Lattitude D830 notebook. The cd will load successfully and I can install the OS successfully on each of these machines, except the 320. The 320 has the most up to date BIOS available and all the hardware passes testing. What else can I provide that would be helpful?