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.