Edit:
I know now: I overwrited the mbr with a totally wrong one, and I have no backup

So far as I can recall, I had two primary partitions; the first one for xp, and there were several logical volumes for linux in the second primary partition).
None of these partitions are found now, grub reports "Error 22" with the wrong mbr.

Can the mbr be corrected/recovered somehow, in a way that all of the original partitions show up again?
I think, the partitions themselves are not damaged, since only the mbr was overwritten.

I suppose a fixmbr command from the recovery console of the xp installation CD would fix the mbr and make the xp system in the first primary partition bootable. Am I right? How about the second primary partition; would fixmbr find that too? (Sorry for the silly questions, but I do not want to commit more mistakes, especially irreversible ones.)

MBR and PT are two separate things. 'testdisk' can recover your Partition Table and can write a Master Boot Record.

1 members found this post helpful.

According to the wiki(http://en.wikipedia.org/wiki/Master_boot_record), the mbr has a "Table of Primary Partitions" at hex address 01BE: four 16-byte entries. That is what I damaged by overwriting the mbr with a wrong one.

In the meantime I run fixmbr from the xp installation CD, and now I can boot into xp. But it did not find and register the second primary partition in the mbr. Though that starts immediately after the first primary partition (which it has found), and stretches to the end of the disk...

I have testdisk on the linux system, but that is not accessible now. All what I have is an ancient knoppix-based System Rescue CD, and the xp system that is working again . I think it would be easier to find some windows tools, to analize the disk, and find and register the second primary partition in the mbr.

By the way: what if I would create the second primary partition by fdisk? Would it only register it in the mbr, or would it create a blank partition table for it; meaning that its existing logical volumes would be deleted?

As far as I know the MBR of every operating system never dare to touch the partition table. The boot code is restricted from the 1st to the 446th bytes and the last two bytes may also be used as a counter or magic number. In between lies the 4x16 bytes partition table.

No operating system I know of "dare" to trash an existing partition table. It would simply be treated as an outcast because every operating system needs it to operate.

Post here the output from a root terminal to demonstrate the claimed damage.

You're still confusing the MBR with the PT. Anyway, there's a D/L for photorec/testdisk you can install and use on your mcrsft.

Oops, I found testdisk on the System Rescue CD. Thanks to unSpawn's hint, I could recover all the missing partitions with it.

Now I only have to find a way to install grub in the mbr. It will not be a problem, as I did it several times. I used to do it by mounting the necessary hdd partitions, chrooting to them, then running yast. (This time I got a "kernel too old" error when trying to chroot to the mounted hdd partitions, but I will solve that by burning a boot CD with a newer kernel somewhere.)

By the way: all this mess started with a disappearing grub boot menu, and grub always starting xp instead of letting me choose the system to be booted.

Why does this happen, and how to correct it? It happens once in a year, rarely enough to allow me to forget how I solved the same problem the last time...

If I understand things correctly, the MBR (AKA the boot sector) includes the partition table. Here is another reference:
http://www.pcguide.com/ref/hdd/file/structMBR-c.html

regardless, you can install GRUB using any Linux "live CD". Once running from Live CD, do "fdisl -l" to confirm how the disks and partitions are being seen---then start the grub shell (enter "grub").

From the grub shell, do this Assumes that the desired /boot/grub/menu.lst is on sda2 (partition #2 on disk #1), and that the boot code is going on sda (disk #1):
root (hd0,1)
setup (hd0)

The most common thing that happens is that Windows is installed---there is no choice, the MBR is taken over by the Windows boot code.

Well, I think I will setup grub in the mbr by grub's own commands this time, for the sake of simplicity.

Anyway, my first thought was also that the grub boot menu disappeared because of xp messing up the boot code in the mbr. That is why I tried to recover the original mbr from a backup (but using the wrong backup unfortunately).

But thinking it over, I remember grub's boot message to flash for a half second each time it started xp. So, it may happen that grub was in place, but "not working correctly" in the mbr.

My second thought is that the file system on which grub's stageX files are located may be damaged, and that is why grub no longer loads its boot menu sometimes. But this is also an unlikely reason, as I mounted all file systems using the System Rescue CD correctly (in fact, the reiserfs driver rolling back some transactions), but the grub boot menu would not appear after that, either.

So, I am still clueless, why the grub boot menu is permanently "disabled" occasionally...

I reinstalled grub in the mbr, and it still only started xp.

The new System Rescue CD has now a "Boot installed linux system" item in the boot menu, by which I could boot into the existing linux system without manually chrooting to it.

That solved the problem: from that time on, the grub boot menu works.

I think it is not xp messing up with the mbr or grub, but it may rather be an old linux-related bug.