Grub Entry in MBR affected by Online update?

I have had a most peculiar occurrence with grub. I have installed - Windows Vista on internal HDD and an external HDD on USB with openSUSE 11.4 and 12.1. The booting order is external HDD and then internal HDD such that if the external HDD is not switched on the system straight away boots to Windows. The external HDD mbr has the grub entry. After I added 12.1 the mbr was (got) changed and the menu list on the 12.1 partition started coming up (as was expected). In this I had (have) a menu entry to direct the system to the menu list in the 11.4 partition to access that version.

Everything was working fine and I regularly updated both versions. However, last week after I updated 11.4, a peculiar thing happened. On booting I got the menu from 11.4 and not 12.1!! The mbr had obviously changed! How could that happen?? The 12.1 installation is still there and I have been able to add a menu item to the 11.4 menu to point to the 12.1 partition and can now run it.

But the puzzle remains what could have happened to rewrite the first part of grub in the mbr?

PrakashC

If there was a kernel update, GRUB would have been updated and that may have triggered an update to the mbr if it was not pointing to the new GRUB menu.

I think not a kernel update but a grub update was the culprit. I had similar issues on two machines … why on these two and not on others? I don’t know. The MBR (which had Ubuntu’s Grub2 previously) was simply overwritten by Legacy Grub. Fine. I just reinstalled Grub2 afterwards. I didn’t report the problem, thinking that weird bugs only happen to weird people … and my systems are not good examples (lots of Grubs everywhere). But I can confirm that something unusual (and completely wrong btw) happened here. The two affected machines were running openSUSE 12.1, one 64 and one 32bit. One of the machine also had openSUSE Grub2 installed in another VBR. The bootloader there was also overwritten by Legacy Grub (which is not much surprising but shouldn’t happen though).

On 2012-03-07 08:06, PrakashC wrote:

> But the puzzle remains what could have happened to rewrite the first
> part of grub in the mbr?

Are you sure it changed? Perhaps it is the bios ordering that changed. The
MBR can not not start Grub on a different disk, it can only work on the
same disk.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2012-03-07 13:56, please try again wrote:
>
> I think not a kernel update but a grub update was the culprit. I had
> similar issues on two machines … why on these two and not on others? I
> don’t know. The MBR (which had Ubuntu’s Grub2 previously) was simply
> overwritten by Legacy Grub. Fine. I just reinstalled Grub2 afterwards. I
> didn’t report the problem, thinking that weird bugs only happen to weird
> people … and my systems are not good examples (lots of Grubs
> everywhere). But I can confirm that something unusual (and completely
> wrong btw) happened here. The two affected machines were running
> openSUSE 12.1, one 64 and one 32bit. One of the machine also had
> openSUSE Grub2 installed in another VBR. The bootloader there was also
> overwritten by Legacy Grub (which is not much surprising but shouldn’t
> happen though).

If the update can be determined it should be reported, even if the report
is vague.

In my test system, I had grub installed on “Sat Feb 25 2012” with a package
created Thu Feb 16 2012. It is a very simple installation so I did not
notice anything.

In any case, the re-installation should be done according to the file
“/etc/grub.conf”, which in my case it has not been modified, it is dated
last November.

I don’t know if some log would show the re-installation.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

I know you would say that, but please understand that I have too many monitors and systems around me. Such things always happen when you are in the middle of something else. It was clearly not expected and I had no time to even try to understand what was behind. I simply reinstalled Grub2. I thought about writing a post - one or two weeks ago, I guess - but realized I would probably be talking to myself. So I decided to wait until someone reports a similar issue and confirm it then.

On 2012-03-07 15:06, please try again wrote:
>
> robin_listas;2446508 Wrote:
>>
>> If the update can be determined it should be reported, even if the
>> report is vague.
>>
>
> I know you would say that, but please understand that I have too many
> monitors and systems around me. Such things always happen when you are
> in the middle of something else. It was clearly not expected and I had
> no time to even try to understand what was behind. I simply reinstalled
> Grub2. I thought about writing a post - one or two weeks ago, I guess -
> but realized I would probably be talking to myself. So I decided to wait
> until someone reports a similar issue and confirm it then.

It doesn’t need to be you :slight_smile:

And I assume that the packagers, once told, can find out what they did
wrong. We, users, have only one chance, we can not investigate, we can not
install the update again.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

I could have investigated and downgraded Grub, but this is the kind of thing that you know in advance you can’t afford. I really had no time. I can not boot openSUSE on this machine right now and check the logs, but I can run findgrub … because it is uni(x)versal. :slight_smile: - and show you what happened - for the records.

Here’s that monster:

Find Grub Version 3.7.2 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Grub2 (1.99) found in sda MBR     => sda6   0x83 (Ubuntu/Mint)
 - searching partition /dev/sda1      (FAT16)         ... --> Windows NT/2K/XP Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - skipping partition  /dev/sda2      (FreeBSD)      
 - skipping partition  /dev/sda3      (FreeBSD)      
 - reading bootsector  /dev/sda4      (Extended)      ... --> Legacy GRUB  found in /dev/sda4   => sda9   0x83 (openSUSE)
 - skipping partition  /dev/sda5      (swap)         
 - reading bootsector  /dev/sda6      (LINUX)         ...
 - reading bootsector  /dev/sda7      (LINUX)         ...
 - reading bootsector  /dev/sda8      (LINUX)         ...
 - reading bootsector  /dev/sda9      (LINUX)         ... --> Legacy GRUB  found in /dev/sda9   => sda9   0x83 (openSUSE)
 - reading bootsector  /dev/sda10     (LINUX)         ... --> Grub2 (1.99) found in /dev/sda10  => sda9   0x83 (openSUSE)
 - reading bootsector  /dev/sda11     (LINUX)         ... --> Grub2 (1.99) found in /dev/sda11  => sda11  0x83 (Ubuntu/Mint)
 - reading bootsector  /dev/sda12     (LINUX)         ...
 - reading bootsector  /dev/sda13     (LINUX)         ... --> Legacy GRUB  found in /dev/sda13  => sda13  0x83 (Mandriva/ArchLinux/Debian)
 - reading bootsector  /dev/sda14     (LINUX)         ...
 - reading bootsector  /dev/sda15     (LINUX)         ...
 - reading bootsector  /dev/sda16     (LINUX)         ... --> Legacy GRUB  found in /dev/sda16  => sda16  0x83 (Mandriva/ArchLinux/Debian)
 - reading bootsector  /dev/sda17     (LINUX)         ...

 - reading MBR on disk /dev/sdb                       ... --> Legacy GRUB  found in sdb MBR     => sda11  0x83 (openSUSE)
 - searching partition /dev/sdb1      (FAT16)         ... --> Windows NT/2K/XP Loader found in /dev/sdb1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sdb1
    rootnoverify (hd1,0)
    map (hd1) (hd0)
    map (hd0) (hd1)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - skipping partition  /dev/sdb2      (FreeBSD)      
 - skipping partition  /dev/sdb3      (FreeBSD)      
 - reading bootsector  /dev/sdb4   *  (Extended)      ... --> Legacy GRUB  found in /dev/sdb4   => sda9   0x83 (openSUSE)
 - skipping partition  /dev/sdb5      (swap)         
 - reading bootsector  /dev/sdb6      (LINUX)         ... --> Legacy GRUB  found in /dev/sdb6   => sdb6   0x83 (Mandriva/ArchLinux/Debian)
 - reading bootsector  /dev/sdb7      (LINUX)         ...
 - reading bootsector  /dev/sdb8      (LINUX)         ...
 - reading bootsector  /dev/sdb9      (LINUX)         ...
 - reading bootsector  /dev/sdb10     (LINUX)         ...
 - reading bootsector  /dev/sdb11     (LINUX)         ...
 - reading bootsector  /dev/sdb12     (LINUX)         ...
 - reading bootsector  /dev/sdb13     (LINUX)         ...

********************************************************************************
WARNING: /boot/grub/device.map not found.
         Displayed BIOS device mapping may be incorrect!
********************************************************************************

What happened is that the bootloader in MBR (Ubuntu’s Grub2) and the one in sda10 (OpenSUSE’s Grub2) were both overwritten by Legacy Grub stage1. I’m not 100% sure that it was after the Grub update … but I cannot think of anything else that could have done that - not a kernel update.

I didn’t reported it because I thought people would either not believe it or not care. And who is willing to fix the perl bootloader anyway … which keeps deleting other kernel boot entries in the menu for over a year or two now? It’s a different bug, but it shows you how the openSUSE Grub team cares about multibooting with other distros. I posted a workaround a while ago in the updategrub thread but also recommended not to use it. One could just rewrite the perl bootloader from scratch - it doesn’t have to be in perl btw.

O.T but ...

After reading that on the Grub2/Yast project page you mentioned in another thread: 


> perl-Bootloader is still in use **currently**. I agrees it's ugly and we'd better not use them anymore in the future. But consider the following things I still use them (otherwise I would have other trouble :().



I wonder who's going to have the trouble at the end.

On 2012-03-07 17:06, please try again wrote:
> What happened is that the bootloader in MBR (Ubuntu’s Grub2) and the
> one in sda10 (OpenSUSE’s Grub2) were both overwritten by Legacy Grub
> stage1. I’m not 100% sure that it was after the Grub update … but I
> cannot think of anything else that could have done that - not a kernel
> update.

I did not believe it at first, but after seeing two or three similar posts…


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

I didn’t believe it myself, even when I saw openSUSE’s Grub menu before my eyes. It seemed so absurd that I didn’t feel like to focus on that problem. Restoring the previous boot configuration took only a couple seconds, while it would have taken much longer to describe what happened in a way for others to believe it. I knew it was a bug but … sometimes you just let the bugs fly around you. I don’t know why it hit two computers out of … don’t know exactly, about 7 or 8. The two affected ones had Intel CPUs, while the other ones all have AMD … but that sounds even more absurd.

I hope you’ll trust me when I say that I didn’t reinstall openSUSE’s Grub on these two computers without knowing what I was doing. You see why I hesitated to report this bug.

On 2012-03-07 23:46, please try again wrote:

> I hope you’ll trust me when I say that I didn’t reinstall openSUSE’s
> Grub on these two computers without knowing what I was doing. You see
> why I hesitated to report this bug.

Yes, I know.

But you are on a much better position to report this than many of us. :slight_smile:
I can’t, it did not happen to me. Although I haven’t rebooted recently…


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

No confusion there! The internal HDD boots to Windows, no grub there. The mbr on external HDD has the grub.

As john-hudson suggests the update at some stage changed the grub file which while saving automatically checked and wrote its location to the mbr. That is likely to recur each time an update affects the grub of an installation. That should call for a look at the instructions for updating a grub file!!

PrakashC