- Using an old Windows bootmgr instead of the new one
- Installing a bootmgr over a partition that contained another SO as FreeDOS (and removing its BCD)
- Installing a bootmgr on a system that contained a Linux, removing GRUB and the access to Linux
In the next graphics we can see how the boot process works and what happens when the bootmgr is installed on an undesired HDD (that's our second case)
0. Power Supply sends a PWR GOOD signal to the CPU, starting the boot process. I've ommited this step for being too "hard-warish"
1. The CPU (with the help of the chipset) will look for the reset vector, allocated 16 bytes before the memory space limit, and belonging to the ROM or FLASH memory (RAM is not even initialized yet). ROM memory is read-only and non-volatile (won't reset when switching off your equipment). FLASH memory can be rewritten with an OS already running on the machine and is non-volatile as well. At this stage is CPU is in real-mode (which is a 16 bits mode by the way), so in modern computers will need the help of the chipset to produce the address (32/64 bits).
2. BIOS executes a power-on-self test. If it passes, the boot continues.
3. A small routine pointed by the BIOS will be loaded to run a first VGA controller (Video BIOS). Other BIOS may be loaded (like the SCSI BIOS). These ROM routines are meant to provide a basic functionality.
4. Other system checks on the different elements will be performed.
5. The init screen (from which we can access the BIOS menu) will be displayed and the boot process starts. Some of them will indicate how to access the boot menu, from which we can select a drive that contains out chainloader. Some other screens aren't informative at all and we'll have to look for the instructions of the ensambler in its own resources site. A couple of examples:
A boot menu will look like these, depending on the manufacturer of the BIOS chipset. There will be a submenu for the boot process (a tab for this BIOS model). By choosing a device order, we are giving priorities to the devices in our equipment to start their own chainloaders. The BIOS will look for the device with highest priority and if present it will run its boot process starting from the MBR (Master Boot Record).
6. The BIOS indicates the CPU which device access
7. The CPU reach the device and will look for the MBR, an operative system independant small piece of memeory that will hold the number of partitions available in our device and their addresses. It will store as well which VBR contains the boot information (that is, which is the boot partition), so it can indicate the CPU which address move formard to.
8a. The small routine in the MBR is loaded to point to the boot partition. It will address the VBR, the firsts blocks of memory of the boot partition.
8b. The VBR is read, containing a operative system dependant routine that will forward to the entry point of the operative system. This routine is known as the boot manager (bootmgr in Windows, GRUB in Linux).
9. The boot manager is the first step of a two steps final process. If only one OS is available after installation, because we did the install to a clean device, the boot manager will point only to one address to start the OS. If more entrypoints for different operative systems were available to the boot manager a multi-boot screen will be displayed. These entrypoints are called BCDs and may point to a different physical device from where the boot manager was installed, to a (Windows) boot partition.
That a too many steps process and it would be better to fix it. First thing to do is creating a BCD to point to our Linux distro, that we have installed in the HDD. We can use bcdedit command to do so, but it is a complex command and requires some expertise. I would suggest using bcdedit at the end of the process to move the bootmgr to the desired partition. To create the BCD that will be recognized by out bootmgr we can use a tool called EasyBCD. In the next graph we'll see which steps we need to set up a BCD using this tool. If in doubt on which partition is your Kali Linux distro, you can check the Disk administrator tool under: Control Panel -> Administrative tools -> Computer Management.
If you had another SO (like FreeDOS) in your HDD and installed Windows in the SSD, it will look like this:
Notice the system tag on the G: partition? That's the way Windows calls the partition where its bootmgr was installed. It should be called "boot" (or "arranque", in spanish), instead of "System", but that's the Windows naming standard. Microsoft always being snicky with names. Our Kali was installed under the 225 MB partition, which Windows doesn't recognize as it's filesystem is a ext4. Unfortunatelly it's not possible to access an ext4 partition locally on Windows. That's a prize we pay. Our Windows is in the C: partition and, as this is the SO we have booted, it appears marked as "Boot" (should be "System", but for Microsoft is "Boot").
Let's create a BCD for the Kali Linux distro by using EasyBCD:
Choose a name for the Kali distro instead of the default one (that ugly NeoSmart Linux which means nothing). Mine is Kali Linux 1.0.5 as I used the distro that was available two years ago. The latest version is 1.0.9, which for compatibility reasons with the latest harware I encourage you to use.
Well, looking good! From now you have a multi-boot system! Congratulations. The bootmgr is where it shouldn't, but at least the bootmgr already recognize our Kali Linux Distro. Wanna try it? Reboot your computer. After the BIOS screen you should be redirected to the multi-boot Microsoft bootmgr screen.
If everything went fine we can check the bootmgr directly with the terminal tools before mentioned. Let's run on cmd:
> bcdedit /enum
and what we get is something like:
The pic is not complete but we can see the information we need here. If the BCD was added properly to the bootmgr, we'll have this section called Boot sector on Real Mode, which is how Windows calls other BCDs not being Windows. See the reference to the G: partition? As explained before, the BCD was added in the same partition where the bootmgr is, pointing however to a different partition (which in Windows is left without letter naming). We can see as well in the whole output that the bootmgr is in G: while Windows is running in C: We need the bootmgr with all their BCDs to be moved to the SSD disk, while making sure the pointers in the BCD still are congruent and will be still pointing to the proper partition, whether if in another disk or not. Fortunatelly for us there's a quick way to do it without pain. Let's run:
> bcdboot c:\windows /s c:
We are done! Let's run again bcdedit /enum to verify our BCDs and the bootmrg is finally in the Windows SSD partition:
> bcdedit /enum
Excellent! Now the bootmgr and the BCDs are stored in the Windows partition and not scattered among other disks recognized by Windows. In the meanwhile we have created a BCD for Kali Linux which points to our distro and that from now will be visible in the multi-boot screen.
That's all my friends. The intro was worth to know what you can expect of installing Windows depending if the filesystems on other partitions are recognized by it. In most cases a Linux GRUB could be stepped over or if a OS with a filesystem recognized by Windows is present we'll end up with a weird boot configuration scattered between systems (and yet without Linux being recognized). I hope you learned from the worst case. In the upcoming posts we'll see how to backport features from the Debian branch to our Kali Linux distro to ensure that our Hardware is recognize. Again, we'll do it starting from a worst case where the Ethernet/Wifi cards are not recognized.
