Dual-boot with Windows. Part III

We are almost there: We have seen the three main possibilities of having an undesired bootmgr configuration:

• 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.

Dual-boot with Windows. Part II

In the previous post we saw the different partitions we can create in an environment. These partitions are OS dependant due to the nature of the file system, however most OS will recognize the most popular filesystems. A partition will hold the load manager (this is the small program that will let us select an OS at the setup screen) and each OS installed will contain a loader that will be read by the load manager to boot the OS. For some reason, Windows calls Boot partition to the partition containing the OS with its loader, while it calls System Partition to the partition containing the load manager being pointed by the MBR/PBR of one of our storage devices.

2. Installing Windows 7: Choosing a partition

So we have chosen the SSD disk to keep our Windows 7 because it will increase dramatically the performance. We had a previous SO in the SATA disk (Windows XP, Vista, a FreeDOS, Ubuntu, …) that we want to keep but without occupying to much space in the SATA. When we are asked to select a disk to install W7 we can access to disk manager and shrink the space occupied by other OSs

We are done here! But when we reboot of PC, we have three possible scenarios: Two of them are positive while the other will give us more work, depending on the previous preinstalled OSs in the SATA, if any.

- Pre-installed Windows: In this case, the Windows 7 installer will recognize the preinstalled OS. It will add an entry for itself in the boot manager (this entry is a boot loader, Windows calls it BCD) and will leave intact the previous entry of a Windows OS. Moreover, the System partition won't change and it will be the one hosting the Windows boot manager. Since Vista, Windows uses bootmgr as the boot manager addressed by the active partition VBR.

When you reboot, the BIOS will see the previous entry in the MBR/PBR and will jump to the partition that holds the old boot manager. It will select this boot manager from the System partition (the one from the pre-installed version!) that, back to the MBR, will display the two available OSs. We can select one of them and that will be the OS to be booted. We are going to have a multi-boot with two Windows systems.

- Pre-installed FreeDOS: The Windows 7 installer will recognize it as well and won't remove the entry from the MBR. The System partition will be still the FreeDOS partition in fact, so it will contain the manager. However as opposed to the previous case, the Windows 7 will be the only Boot partition. When we restart the computer, we'll move from the BIOS to the MBR, and from the MBR to the FreeDOS manager. Which will be in fact pointing to the Windows 7 loader! When we restart we will boot directly into Windows 7 through a too-many-steps process. This is far from being a fine tuning. This is unavoidable if we had a FreeDOS in the SATA, so we'll give steps to create an optimal environment for this case.

We don't need the manager in the SATA, but, as we didn't have any OS installed in the SSD, even if it goes first in the BIOS boot order, it will be ignored and will pass through the next option. This may seem strange, but that's exactly what happened to me! When installing Windows, it will look for system partitions (partitions containing already a manager) in other HDD to store its manager AND if it wasn't Windows, it will delete it from the boot chain to place its manager. Yuck!

As said above, we'll see how to modify ot boot chain. No worries. This is a suboptimal case where the boot chain will pass through some HDD to start Windows, but we'll see how to modify the boot chain to fix it to the optimal state. We are talking of a delay of less than half a second to boot Windows 7, but we can avoid it.

- Pre-installed Linux: Worst case. Chances are Windows installer won't have mercy on the MBR/PBR entries. It will wipe out previous entries on the MBR/PBR and will assign to itself the boot and system partitions. The good point? Well, if we were lucky as we wanted to install Windows 7 on the SSD disk, maybe it won't wipe the entries from the SATA, plus the Windows 7 boot loader will be in the system partition (that is, the boot partition and system partition will be the Windows 7 installation partition and we won't have to copy the bootloaders from one partitions to others). Depending on the disks we gave priority in the BIOS menu, we'll boot directly in Windows 7 for the SSD or, if the entries in the MBR/PBR SATA disk weren't removed, we'll boot into out pre-installed Linux. Again, I can't guarantee what a Windows installer will do on non-recognized MBR entries that could be on a different disks than the one to be installed. If you wanted to keep a previous version of a Linux system, back-up before playing the roulette (if for some reason you want to end up with a Windows7 - Previous Linux - Kali Linux environment).

Dual-boot with Windows. Part I

It's most likely that if we have a brand new equipment we will prefer to have two OS instead of only Linux, so we can have the best of world worlds without dedicating in exclusivity a whole machine. This is today a more and more common option as HDDs space has been increasing exponentially while prices have shown little variability. In the 80's a hard disk of few megas could cost thousands of dollar. Now we have HDDs in the magnitude of TB (1024 Gb!) for less than a hundred dollars. Our space needs however will rarely meet this amount, so a multi-boot option for system management in more common nowadays than it was in the past. This system management is, however, still a bit tricky and will require advance knowledge to set a working efficient system. The introduction in the first post will help us to understand what is really happening when we install a new operative system and how we can make our system to recognize both without drawbacks. For this post we are going to assume a non-trivial case, but extremely useful to understand what we can achieve with the right tools and administration knowledge.

Dual-boot with Windows 7 and Kali Linux on a brand new machine

In the first post I commented that most modern systems won't try to take the whole system space for them. Whether this affirmation is true, it's not complete. It would be better to say: Modern OS won't take the whole system space for their exclusive use, but may not recognize other OS to share resources with. Even if OS will keep their partitions for their own use we are going to find an ugly surprise from Windows systems: Installing a Windows OS on a HDD will rewrite the MBR information of other previously installed OS. The partitions from previously OS will be still there, but inaccessible and the boot routines will be removed from the MBR, so they BIOS won't be able to boot another OS. How to proceed? Let's get it on.

1. Installing Windows 7: Partitions of an equipment with two or multiple hard disks

Windows will try to rewrite our MBR area in the HDD where we want to install it, so it will be wise and commonly less problematic to install it first, so we can later redo our MBRs. Let's start by installing Windows 7 and creating our first partitions:

Pass through the typical installation first steps: Select your main language, keyboard configuration (the country and language your keyboard was made specifically for), time zone, etc. Nothing special to do in here. At one point Windows will ask you for creating partitions. Here's where the magic starts. It's better to think carefully how do we want our equip to be configured for in the future it will be more difficult to set again a new configuration.

As said in the title, we are going to assume we have two or more hard disks. If we have bought a new equipment even if we purchased it without a OS preinstalled typically it will come with a minimal OS, let's say a freeDOS. If we purchased it with another OS that we don't want to use, or use minimally, we may want to keep them but reserve them a minimal space in our hard disk. Whatever premises we may have at this point what is really important for ourselves is to know that we can shrink the space that a previous preinstalled OS was occupying.

Moreover, if we have a new equipment with two hard disks, let's say a standard SATA hard disk (the typical hard disk that comes with all PCs, with around 1Tb of space) and a SSD or solid state hard disk (a new version of hard-disk that became popular recently, with a much higher read/write speed than the normal SATA disks, but more expensive and typically with less space. Commercial SSD hard disks are sold with a storage space of 128/256 Gb, beginning of 2014) chances are the pre-installed OS was preinstalled on the SATA disk, except if we asked the retailer to install it specifically in the SSD disk. If we didn't have this option and we purchased a new equipment with an extra disk, let's say a SSD, chances are any preinstalled OS will come in our SATA disk. This is going to create us a little trouble, but that's why you are reading these lines, aren't you? Nothing to worry, we can have many OS in a multi-drive system. For now just remember the past lessons: There's one MBR per HDD, where we can have many boot-loaders for different OSs, not necessarily installed in the same HDD.

Let's make an incise on what is going to happen during installation before we proceed. It's important to know what will happen with the MBRs and the differences between partitions. Not any partition can be used as a boot-loader.

Windows partition types:

• Primary partitions: These are the standard partitions created by Windows. There's a limit in the number of them that can be created per HDD. A MBR record written by windows will allow up to 4 primary partitions, or 3 primary partitions + an extended partition. Only a partition formatted as primary will be able to host a bootable OS.

• Extended partition: If we would like to create more than 4 partitions, we will need to create the fourth as an extended partition. The extended partition can contain however many other partitions called logical partitions. The number of logical partitions on a extended partition is limited only by the number of letters in the alphabet, that Windows will assign to each partition, but I'm sure you don't need more than 29 logical partitions.

• Boot partition: Ha! Windows calls it boot, but its in fact the last part of the chain that starts in the MBR to boot an OS. A partition tagged as boot will contain a loader to run the OS that it holds. However the boot manager that will be started after the MBR checks the partitions on a HDD may be in another partition. Only a primary partition can be tagged as boot, and it will contain a loader to boot the OS it stores.

• System partition: The primary partition holding the boot manager. After the BIOS jumps to the MBR of the HDD assigned to boot a system from, it will move to a volume boot record (VBR) that contains a little program commonly known as boot manager. After a MBR is read, it will move to the partition holding this manager. The manager can contain the address of many loaders , each of them in different disks. The manager, however, must be in the same disk than the MBR. A MBR can't be redirected to a manager in a different HDD.

• Active partition: The partition named as active is the one holding the operative system that we have booted. The one you are running while reading this. The active tag is assigned consecuently after booting a OS, and we can't choose it. Nothing to do in here.

Main File-Systems recognized by Kali

Non-linux, but supported	Max. Single file size	Max. Partition size	Journaling*
FAT16 (Legacy, don't use)	2 GB	2 GB	No
FAT32 (Legacy, don't use)	4 GB	8 TB	No
NTFS - Windows standard	2 TB	256 TB	Yes
Linux
ext2 (Legacy, don't use)	2 TB	32 TB	No
ext3	2 TB	32 TB	Yes
ext4	16 TB	1 EB**	Yes

* Consistency support. Detects faulty write processes before overwritting files with corrupted data.

** Yes, that's an Exabyte. 10⁶ TB.

Probably you have heard of the FAT file systems. Sometimes pendrives comes formatted with a FAT32 system. These were the ones used in Windows versions before Windows XP. There's no reason to use a FAT filesystem to install Windows nowadays, as NTFS is recognized by Linux OSs. They are still disposable however in gParted and the Windows Disk Manager for legacy reasons.

NTFS is the standard file system for Windows OSs since XP. It's recognized by Kali, but don't use it for installing it.

ext is the typical file system for Linux Oss. ext4 started to take over the reign of ext3 and nowadays can be accessed from Windows OSs with tools like ext2fsd. In doubt, use ext4.

More to come in Part II, where we will learn about boot managers and boot loaders.

Installing Kali on brand new machines

Hello World!

Hello my friends. This is my first post on what is my passion and dedication: the world of Linux and more concise, the world of security on IT infrastructures.

Nowadays installing Linux on a personal machine tends to be easy and painless, thanks to  tools as GRUB, which will scan our hardware to propose a neat solution to carry on with our installation instead of assuming it will be the only operative system running on our computer. All modern operative systems follow this paradigm and are no longer invasive (i.e. trying to format all space in disks for itself). Instead, when installation occurs, a disk administrator (GParted, in the case of Kali Linux and the Disk Manager in case of Microsoft latests OS) will ask you to define how do you wish to partition your disks and where to host the OS itself, along with other performace partitions (swap space, home folder partition, root partition and so on, these last two being optional while the first mentioned being very important in terms of efficiency but not strictly mandatory)

So let's start with the basics: An introduction to install Kali Linux on our machines. Among the typical installations we can use a CD Live or USB Live to boot our machine with Kali Linux. If we proceed this way we'll simply insert the CD or u USB key in a slot so at init the OS used is Kali instead of the default SO we have in our HDD. But wait, let's make an incise here to explain how our machine is really booting the SO. Some of you will notice that inserting a CD-Live or USB-Live distro is not enough and instead your machine boots with the pre-installed SO. What's going on here? Let's explain briefly what is a BIOS and how we can modify it. This is important to explain further concepts in order to create a more sophisticated environment (i.e. multiboot, boot on machines with several HDDs, etc).

The BIOS and its evolution

The BIOS is the first software piece that will be processed by our machine. It's an old standard in the industry used by all commercial motherboard providers. The function of the BIOS is detecting the hardware in a machine and make it visible for our operative system, so all parts of our system are visible for our OS before it's loaded. Now it's easy to see why it' s an standard, as our hardware pieces won't have to be dependant on a specific BIOS provider, giving us the choice to upgrade and modify our system without looking for specific BIOS hardware versions. Typically it will access a so called MBR area on a specific peripheral (MBR stands for Master Boot Record, normally is written on a hard-disk at installation time and contain the first bytes to be read to load a OS) and will start our OS, to give it control on our computer. Nowadays BIOS are being upgraded into a new standard called UEFI, that allows more and bigger partitions on our HDDs. UEFI BIOS can access to standard partitions with a MBR area, or bigger partitions (over 2Gb) that were created with a GPT, replacing MBR. Despite efforts were made to make both systems totally compatible, specific installations may require exotic formatting on the HDD, but in theory a UEFI BIOS will be able to boot a SO from a normal MBR. Backwards compatibility was not in scope, despite is possible to load from a standard BIOS a GPT partitioned disk with specific rewritting of their boot records.

The BIOS will detect most of the hardware available, as vendors adapt the hardware for it, but there's still risks that it won't detect brand new parts. For this case motherboard vendors should provide new firmware versions to update the BIOS. In the past it was not possible to modify it, as it was written on a ROM memory, that can't be overwritten. Nowadays the BIOS is tipycally written on a flash memory, that we can overwrite. This process can be done from our OS, so once we have initiated our system we can download a new firmware that will check and update the BIOS. This process is not exent of risks, as a failure in the update could create a corrupted BIOS, leaving our system unusable as it wouldn't be able to boot anymore. To protect our system from failure is wise to make a copy of our previous BIOS firmware state, so in case of a corruption we have a way to go back in the process. This step is confusing and up to the motherboard vendor specifications: Sometimes it won't be possible to back-up the BIOS firmware from the BIOS menu and sometimes it won't be possible to back-up at all from our OS due to lack of software for this purpouse. Tipically computer ensamblers (Lenovo, Dell, MSI, etc) will offer new firmware versions for our BIOSs, to be updated from a OS. As commented above, this process is very risky as an error during update could leave us an unusable BIOS firmware that won't allow us to boot the system anymore. In fact, a BIOS backup could be useless if we can't even restart the system anymore. This is the worst case and has no solution at all that doesn't require to change our hardware, so if you are not in a real need t modify your BIOS, don't do it. Except for specific hardware modifications  urges (typically a need for different partition systems or a RAID installation for several HDD) an update of your BIOS is not performing any improvement in your system. Let's show an example on how a specific ensambler (MSI for this case) gives new BIOS firmware to their clients to update, with specific instructions to do it.

How to access your BIOS boot menu


case our BIOS firmware is in good state, we can modify it to allow us to restart our from a bootable different pheripheral, and that's how it links with the previous explanation at the firsts paragraphs: If we weren't able to boot Kali from a copy on a bootable USB-key or DVD it's because probably our BIOS was not set to recognize other peripherals as the main boot routine. By selecting in the boot menu to use another bootable peripheral as the main boot, we will be giving it priority to load an OS.

Typically the shortcuts to access your BIOS menu are the following keys:

• F8
• F2
• F1
• Supr

The BIOS menu key will have to be pressed BEFORE our operative system is loaded. Normally in the few seconds while the image of the system ensambler is displayed. Once we are inside we have to locate the boot menu and ensure that USB or DVD peripherals have priority over the hard disks to run a live distro. Next time we reboot our system, the DVD-live or USB-live will be booted instead of our default operative system. Yay! First problem solved. Remember that, in order to boot from a live distro, your peripheral MUST be set as bootable, that is, containing its own MBR or other compatible boot record to let the BIOS know how where to locate the first routines of your OS to be run. A burned .iso image won't be enough except if the iso image was prepared for it, as a DVD can ocuppy is full space and we can set with the content we need the first sector to be read. This is the case of Kali DVD images by the way. The UBS key will have to be prepared. Mentioning that the peripheral must be bootable was not redundant.