*** Please type your report below this line ***

Dear Debian folks,


I upgraded from 1.98+20100602-2 to 1.98+20100614-1, chose to install the
maintainers `/etc/default/grub`, made the following changes (uncommented
the second)

    GRUB_TIMEOUT=1
    GRUB_TERMINAL=console

and executed `sudo update-grub` and rebooted.

Now the message »Welcome to GRUB!« is shown and the machine reboots
immediately. I tried to press Shift but could not get into the command
line.

Any hints on how to proceed are very welcome. I have a Debian Installer
CD image and can use it as a rescue console.


Thanks,

Paul

If you look using a rescue CD, does the file /boot/grub/stage2 exist on
your installed system?

Thanks,

Am Freitag, den 18.06.2010, 13:18 +0100 schrieb Colin Watson:

        $ ls /boot/grub/stage2
        ls: cannot access /boot/grub/stage2: No such file or directory

Looking at #586143 [2] I just want to note that GRUB2 was installed on
this system right from the beginning.


Thanks,

Paul


PS: Sorry it took so long. I am using Ext4 and so the old Debian
installation CD could not access the content. The system does not
support to boot from an USB medium and I did not want to burn another CD
medium. Booting a KNOPPIX DVD did not work and I finally used a floppy
disk since over five years again and put Super Grub Disk (SGD) on it
using the Debian installation CD. ;-) SGD even detected the installed
system and booted it! Great!


[1] http://www.supergrubdisk.org/
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586143

Am Samstag, den 19.06.2010, 11:13 +0200 schrieb Paul Menzel:

I upgraded to the latest version 1.98+20100617-1 and `/boot/grub/stage2`
is still missing. During the upgrade I noticed the following error
message.

        Setting up grub-pc (1.98+20100617-1) ...
        /usr/sbin/grub-setup: error: no such disk.
        Generating grub.cfg ...
        Found linux image: /boot/vmlinuz-2.6.32-5-686
        Found initrd image: /boot/initrd.img-2.6.32-5-686
        done

I searched for this and found #575429 [3]. But I do not use a RAID and
running `sudo update-grub` does not output this message.

I am pasting more information into this message as the reported in [3]
did.

        $ more /boot/grub/device.map
        (hd0)   /dev/hda
        (hd1)   /dev/sda
        $ sudo blkid
        /dev/sda5: UUID="fbcdea36-67e3-4c38-88d3-6389853d3038"
        TYPE="swap"
        /dev/sda1: UUID="582643ad-cb1e-4a01-bca4-5c8ad8562447"
        TYPE="ext4"
        $ sudo update-grub
        Generating grub.cfg ...
        Found linux image: /boot/vmlinuz-2.6.32-5-686
        Found initrd image: /boot/initrd.img-2.6.32-5-686
        done
        $ ls /boot/grub/stage2
        ls: cannot access /boot/grub/stage2: No such file or directory


Thanks,

Paul
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575429#15

OK.  There are several causes for this type of problem and I want to try
to rule them out; the presence of /boot/grub/stage2 is just one of them,
so if it doesn't apply to you then forget about it.

When GRUB boots, its boot sector first loads its "core image", which is
usually embedded in the gap between the boot sector and the first
partition on the same disk as the boot sector. This core image then
figures out where to find /boot/grub, and loads grub.cfg from it as well
as more GRUB modules.

The thing that tends to go wrong here is that the core image must be
from the same version of GRUB as any modules it loads.  /boot/grub/*.mod
are updated only by grub-install, so this normally works OK.  However,
for various reasons (deliberate or accidental) some people install GRUB
to multiple disks.  In this case, grub-install might update
/boot/grub/*.mod along with the core image on one disk, but your BIOS
might actually be booting from a different disk.  The effect of this
will be that you'll have an old core image and new modules, which will
probably blow up in any number of possible ways.

(Quite often, this problem lies dormant for a while because GRUB happens
not to change in a way that causes incompatibility between the core
image and modules.  There was such a change on 2010-06-10 upstream,
though, and so suddenly lots of people had serious problems brought to
their attention all in one go.  It's not really the fault of any recent
change, but rather an ongoing problem.)

There are a few things that strike me as suspicious about your setup.
Firstly, you have /boot on /dev/md0, which is presumably a RAID device
assembled from partitions on multiple disks, yet there's only one device
in /boot/grub/device.map according to your original report.  Then, in
your most recent message to this bug, you seem to have edited
/boot/grub/device.map to include both /dev/hda and /dev/sda, which seems
a little surprising.  What disks do you really have in your system?

Your original report says "debconf information excluded", which is a
shame since there's a vital piece of information there.  What does
'debconf-show grub-pc | grep install_devices' say?

Am Sonntag, den 20.06.2010, 22:41 +0100 schrieb Colin Watson:

[…]

I am sorry. I could not boot the system/access the Ext4 partition back
then (remember the PS in my second message). So I used reportbug on a
different system and thought excluding debconf information would exclude
all system specific information and I did not bother to check when I
composed the message. :(

I am including the reportbug information in this message now. I am sorry
for the inconvenience.


Thank you for your help!

Paul

Am Montag, den 21.06.2010, 00:27 +0200 schrieb Paul Menzel:

I ran `sudo grub-install /dev/sda` and the system boots correctly now.
But I do not know why `sudo update-grub` did not work. Probably what you
explained above.

(Two more question below.)

Where does this come from? `blkid` only lists `/dev/sda[15]`. Is it the
CD/DVD drive?

I do not know, how to interpret the debconf information. But GRUB Legacy
was never installed on this system.


Thanks,

Paul