Grub2 keeps re-writing (destroying) my partition boot record PBR

Asked by Oliver

I had to move my Ubuntu 10.04 LTS partition (because I had to increase the size of a Windows partition below it). I made a copy of the entire partition, with dd, introduced my new partition layout, where my Ubuntu just sits somewhere else, but it is precisely the same size as before, so I copied the backup back into the partition device.

The partition uses Ext 4, so I use Grub 2. Grub 2 is contained in the partition itself, not in the MBR. I use another boot manager (IBM) to chainload the Ubuntu partition. That worked well so far.

Now after backing up and restoring the partition, I could still boot the partition with no errors, everything was fine. But the next day I could not boot it anymore (could not boot Ubuntu, Windows is fine, so the bootmanager is okay).

Booting from CD and doing a grub-install solved the problem. At least that was I though it did. I could boot Ubuntu just once, after that it failed again. So I reinstalled Grub one more time, and made copies of the partition's boot record with dd if=/dev/sda9 of=backupfile bs=1M count=1

Amazingly, immediately after booting (!) the PBR was modified again. Something writes into the PBR at boot time. I suspect Grub2 to do this.

And even more to my amazement, doing a grub-install, backing up the PBR, and immediately making another grub-install yields a different result in the PBR! Changes start at partition offset 0x50, so this really happens in the PBR and not in the data part of the partition.

A workaround for the problem is to issue a fresh grub-install after each and every bootup, that is hardly a solution.

What rewrites my PBR, why, and how can I stop it? Thanks...

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu grub2 Edit question
Assignee:
No assignee Edit question
Solved by:
Oliver
Solved:
Last query:
Last reply:
Revision history for this message
delance (olivier-delance) said :
#1

To know Grub version, run command:
    grub-install --version
1.98 is Grub2

The MBR includes number of partition which hold "/boot" folder. If partition number changed at end of operation, you have to rebuild Grub2 MBR.

"Grub 2 is contained in the partition itself": No, Grub2 is concatenation of:
   MBR on first boot disk sector (which is specific to Grub2)
   31.5kB of data, usually just after the MBR (you will see first partition start after 32KB from start of disk)
   "/boot" folder in boot partition

"What rewrites my PBR, why, and how can I stop it? Thanks..."
   90% probability you use a HP computer (and 10% a Dell one).
Am I right ?
Did you used Grub2 before ?
Instead of Grub Legacy, Grub2 uses the whole 32kB at start of disk, and some software of HP (and Dell) uses this area to store system data, broking Grub2.

Revision history for this message
Oliver (ok23) said :
#2

Hi,

>1.98 is Grub2
Yes it is.

>The MBR includes number of partition which hold "/boot" folder. If partition number changed at
>end of operation, you have to rebuild Grub2 MBR.

No, the partition number is unchanged. /dev/sda9 just sits "somewhere else" on the disk, that is all that has changed.

>"Grub 2 is contained in the partition itself": No, Grub2 is concatenation of:
 > MBR on first boot disk sector (which is specific to Grub2)
 > 31.5kB of data, usually just after the MBR (you will see first partition start after 32KB from start of disk)
 > "/boot" folder in boot partition

No, Grub2 sits inside the partition boot record (PBR), I installed it that way, because I use another boot manager (IBM). The IBM boot manager chainloads the boot loader in the partition boot record and then Grub should be up and running.

>"What rewrites my PBR, why, and how can I stop it? Thanks..."
> 90% probability you use a HP computer (and 10% a Dell one).
>Am I right ?

Sorry, no. Fujitsu.

>Did you used Grub2 before ?

Yes. Before I moved /dev/sda9 everything was fine...

>Instead of Grub Legacy, Grub2 uses the whole 32kB at start of disk, and some software of HP >(and Dell) uses this area to store system data, broking Grub2.

Luckily, IBMs boot manager doesn't. It has a standard-sized boot loader in the MBR, and everything else sits inside a small 8 MByte partition.

Revision history for this message
Oliver (ok23) said :
#3

I found the solution myself. For some unknown reason, a fresh install of Grub will always rely on partition layout data ?!

Grub has to be forced to store an up-to-date partition info (drive map) when it is freshly installed. To do so, grub-install has the command line parameter --recheck.

If you do not specify --recheck, grub-install will always use outdated drive maps. And the dangerous part is, that this old drive map does _not_ break your next boot. If will break the next but one! So if you want to be sure that Grub has re-installed correctly, you always (!) have to boot _twice_ to be sure. Annoying. I have no explanation why Grub does this (modify a partition boot record that has successfully worked) or why the outdated drive map does not break the next boot, but rather the next but one...

But anyhow, the correct statement to fix a partition boot record if you have moved a partition around, and you have to issue this command after the very first boot after the moving (remember, there will be no second reboot, if you missed the first one you have to boot the CD) is:

grub-install /dev/sdaN --recheck --force

where N is your partition number. And of course you got to be root to do that.