On Sat, Jun 19, 2010 at 11:13:45AM +0200, Paul Menzel wrote: > Am Freitag, den 18.06.2010, 13:18 +0100 schrieb Colin Watson: > > On Wed, Jun 16, 2010 at 09:16:16PM +0200, Paul Menzel wrote: > > > 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. > > > > If you look using a rescue CD, does the file /boot/grub/stage2 exist on > > your installed system? > > No, it does not exist. > > $ 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.
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? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
