Description of problem: For most of kernel 20 1nd 21 rc's I needed to supply kernel parms to get it booted. rhgb quite would not work. Sometimes "Nothing" or nohotplug would work or I needed to supply several in differorder to get booted, taking 3 or 4 times. Sometimes I needed to power down and turn off all power switches including the mobo. One strange occuring theme was the first boot after an kernel update usually booted ok (w/o rhgb quite). Now a newly discover theme for kernel's 3065 and 3071 is the seq the is used on grub. If I let the time lasp, it does NOT work. If I Edit the kernel line, then enter, then Boot, it does Not work as per above. But if I press enter on the chainloader rwahide, press enter on the default (newest kernel) it boots up (and with rhgb quite). I was able to repeat this theme several times. There is XP (chainload+1) and is the default, FC6 on this grub, rawhade (chainload+) Arrow down to rawhide. press enter. on Rawhide grub, press enter on newest kernel, boots up. Version-Release number of selected component (if applicable): 3065 and 3071 How reproducible: so far every time. Steps to Reproduce: 1. 2. 3. Actual results: boots up Expected results: To get the same errors as before editing the kernel line (i.e. Edit, enter, Boot) It sure seems like this has to be a different code path problem on boot up. Darwin Additional info:
FYI: Pent IV 2.4 ht, Intel865BGF , video in use is MSI fx5200. Uses ATA100 drives. Darwin
This sounds like a grub problem (or possibly a grub config problem). Can you paste your /boot/grub/menu.lst ?
This is fc7 grub which comes to here from fc6 chainloader+1 entry labeled rawhide. I press esc, arrow to rawhide, press enter, press enter (on current fc7 kernel) to boot. #### #grub]# cat menu.lst # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,5) # kernel /vmlinuz-version ro root=/dev/VolGroup07/LogVol07root # initrd /initrd-version.img #boot=/dev/sda6 default=0 timeout=5 splashimage=(hd0,5)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.20-1.3104.fc7) root (hd0,5) kernel /vmlinuz-2.6.20-1.3104.fc7 ro root=/dev/VolGroup07/LogVol07root rhgb quiet initrd /initrd-2.6.20-1.3104.fc7.img title Fedora (2.6.20-1.3094.fc7) root (hd0,5) kernel /vmlinuz-2.6.20-1.3094.fc7 ro root=/dev/VolGroup07/LogVol07root rhgb quiet initrd /initrd-2.6.20-1.3094.fc7.img
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp