On systems with such a recovery partition, usually the active partition is the recovery partition. The recovery partition displays the "Press F11" message, and if not pressed, forwards over to the main OS partition.
The MBR is essentially dumb; all it does is choose one of the partitions, and forwards over to that partition's VBR.
If you wanted a linux/windows dual boot, then the recovery partition would need to be forwarding to the GRUB partition, which would then allow options, and would forward to Windows if Windows got picked.
I'd not waste time with the recovery partition -- you can get all the drivers there from HP's web site, and if you've already got 7 on the box I think we can both agree wanting to revert back to Vista is unlikely.
So, to your specific questions.
- Yes, your understanding is correct
- Answered above
- Not sure specifically what GRUB does when installed to the MBR. To my understanding it didn't really put business logic there, but I could be wrong.
Hope that helps :)
What exactly makes BIOS decide if a drive is bootable or not?
The BIOS decides if a drive is bootable based on the 16-byte partition record, present after the MBR code area (held in a table starting at the 446th byte). The first byte in each partition record represents the drive's bootable status (and is set to 0x80 if bootable, or 0x00 if not). Some BIOSes may check other parts of the MBR (e.g. partition types, checksums), but the basic requirement is the bootable flag.
How does the boot sequence skip from drive #1 and proceed trying to boot from drive #2 if more than one drive is installed in the system?
This is implementation dependent, and is why you need to properly select a boot order. In most cases, the BIOS will look through each storage medium in the order you set, and determine whether it can boot from that device (via the MBR data). If it can, it does - if not, it continues looping through the other devices (again, in the order you selected).
After BIOS transferred control to the bootloader on drive #1 which happened to have no "bootable" partitions - how exactly is the bootloader on the second drive invoked?
Once a valid boot device is found (i.e. the bootable flag is set, and other additional checks pass), the BIOS copies the MBR sector into RAM. The BIOS then relocates the instruction pointer to the beginning of this location (using a JUMP instruction), where the MBR code segment is located, and the computer then starts.
If the BIOS supports the BIOS Boot Specification, MBR code can return control to BIOS with a certain instruction, signaling it of boot failure and prompting it to try the next device. Older BIOSes just print an error message though. A good tell if you BIOS supports it is whether you can boot from USB.
My understanding is that the only thing BIOS normally checks on an MBR is its signature at the very end of the 512-byte sector, and then it just transfers control to the initial bootloader situated in the first 446 bytes of the boot sector.
This is correct, although it should be noted that most modern BIOSes will also look for a GUID Partition Table as well as the older, conventional MBR-style table.
Does it imply that the first 446 bytes of the boot sector MUST contain some meaningful bootloader code even if the disk is not bootable?
No, but the drive must have a valid MBR or GUID partition table - otherwise, it won't be detected by the computer. While the code part of the MBR can indeed be empty, the first sector of the drive must have a well-formed MBR/GPT.
Best Answer
Yes, and in practice, the MBR bootstrap code often does exactly that.
But the bootstrap code needs some method to find where the next stage of the bootloader is stored. (The whole bootloader is never just 446 bytes; the MBR is just its stage 1.)
Having a bootsector which parses the MBR partition table and looks for the 'active' flag just happens to be a very versatile solution to this problem – it allows for a completely static bootsector (no special tool needed to generate it), and any bootsector doing so works equally well with any OS.
For example, the syslinux MBR bootsector appears to be fully interchangeable with the Windows MBR bootsector. If you dual-boot Linux and Windows, it doesn't matter which bootsector you have, they both do the same thing so you can always just swap the 'active' bit to swap OSes. (And installing the bootsector is just copying mbr.bin to raw disk.)
But different bootloaders certainly have different approaches: for example, the popular Linux GRUB2 stores its second stage in the "post-MBR gap" and dynamically generates the bootstrap code according to its location; i.e. the MBR bootsector knows which LBA the second stage starts at (completely ignoring the partition table and the 'active' flag), and this might vary between disks, so the bootsector must be written by the
grub-installprogram individually for each disk.(GRUB2 does not normally use partition VBRs either; while it can "chainload" those, its typical configuration actually directly accesses the real filesystem and loades the OS kernel files.)