Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236600 - Kernel affected by grub command seq
Summary: Kernel affected by grub command seq
Alias: None
Product: Fedora
Classification: Fedora
Component: grub
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-16 18:09 UTC by Darwin H. Webb
Modified: 2008-05-07 01:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-07 01:29:46 UTC

Attachments (Terms of Use)

Description Darwin H. Webb 2007-04-16 18:09:35 UTC
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

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:
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.


Additional info:

Comment 1 Darwin H. Webb 2007-04-16 18:26:46 UTC
FYI: Pent IV 2.4 ht, Intel865BGF , video in use is MSI fx5200.
Uses ATA100 drives.


Comment 2 Dave Jones 2007-04-19 20:21:06 UTC
This sounds like a grub problem (or possibly a grub config problem).
Can you paste your /boot/grub/menu.lst ?

Comment 3 Darwin H. Webb 2007-04-26 19:35:52 UTC
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
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

Comment 4 Bug Zapper 2008-04-04 00:06:48 UTC
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:

We will be following the process here: to ensure this
doesn't happen again.

Comment 5 Bug Zapper 2008-05-07 01:29:44 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.