/FixMBR writes Disk's Boot Sector (commonly called
/FixBoot writes Partition's Boot Sector (commonly called
VBR or PBR).
All this boils down to how Windows boots on BIOS (non-UEFI) systems. As we know, due to limitations of BIOS firmware (it runs in real-mode and can't access more than 1 MiB of RAM), it cannot load and execute the actual OS (e.g. Windows or Linux kernel). So the system bootstraps execution process in stages from small-sized code to larger one. That's why we have bootloaders.
In first (or zero) stage BIOS loads the first sector of selected disk in RAM and starts execution at predefined offset. It happens on all BIOS compatible systems, irrespective of the installed OS. So the first sector involved in boot(strapp)ing is called Boot Sector.
Now isn't the MBR just a type of boot sector?
Yes. MBR is the boot sector we most commonly interact with.
/FixMBR writes "to the system partition" is not correct. MBR is written to the first sector of the disk (even on GPT disks).
Isn't MBR the only boot sector Windows uses?
No. It also uses VBR/PBR.
Depending on the installed bootloader and OS, there might exist more boot sectors on partitions too. In case of Windows, executable code in MBR finds Active Partition or Boot Partition (Windows calls it System Partition) in Partition Table (also part of the MBR) and executes that partition's boot sector (VBR) which contains BootMgr code. By now VBR is large enough to understand filesystem structure, so it executes
\bootmgr file (placed in root of the Active Partition), which reads its configuration from BCD file (usually
\Boot\BCD) and runs
winload.exe (or shows a selection menu if BCD contains multiple entries), which runs Windows kernel. See more details here.
But not all OSes boot alike. GRUB (popular boot loader in Linux world), for instance, installs itself to MBR which executes the next stage(s) written to few sectors right after MBR. It reads its configuration from
/grub/grub.cfg (placed in
/boot partition, which might be different than Linux installation partition mounted at
/) and loads Linux kernel (or shows a selection menu if
grub.cfg contains multiple entries). GRUB and other bootloaders like SYSLINUX can also be written to VBR.
On a multi-boot system
grub.cfg usually includes an entry for Windows, so it's the GRUB (not Windows) MBR which executes BootMgr in VBR (even if it's not on the Active Partition), when Windows entry is selected by user. Going further deeper, GRUB can be configured to directly run
\bootmgr executable file (by using
ntldr command instead of default
chainloader), entirely bypassing VBR executable code.
Once you decide to come back to Windows' native booting, run
BootRec /FixMBR, and GRUB is gone. Inversely we can also make Windows' BootMgr chainload GRUB by modifying BCD using third party tools like EasyBCD or BootICE, or using Windows'
bcdedit tool to add a new entry.
Rewriting VBR is usually not needed, except if you accidentally (or intentionally) write e.g. GRUB to VBR of Windows' Active Partition. In this case
BootRec /FixBoot is also required to successfully resume Windows' native boot chain.
Note that both of the above commands just rewrite the executable part of MBR/VBR, other parts are untouched e.g. Partition Table in MBR. Like Partition Table in MBR describes partition layout, BIOS Parameter Block in NTFS VBR describes filesystem layout.
/FixBoot cannot fix problems in BPB.
For instance if you replace the Windows Active Partition, or move the installation to another disk so that the starting sector number of the partition changes, Windows won't boot, even if you fix MBR/VBR and recreate/fix BCD entries (using
bcdedit, which is also required if the disk identifier/signature changes because that's hard-coded in BCD store entries). In one of the BPB fields the number of first partition sector is hard-coded, which needs to be fixed. You can see details here.