Saikee,
The last line was supposed to be a joke. Maybe not that good one but still, I try! Notice the at the end of the line. Still I thought you might get offended so I had also added a "no offense" at the beginning.


But I still stick by my question i.e why did they specifically state "you will need a primary partition" in the Slackbook? Note that I am taking this from the Slackbook that came with the Slackware 11 DVD. (slackbook/html/installation-partitioning.html in DVD) . If I am wrong abt taking it from there I am sorry!! I claim noob status .
They could have just let it been , an ambiguous statement ... saying nothing abt primary partitions etc. Why specifically state that?

duryodhan,

To be honest I wasn't offended at all. I welcome exchange of views as this is the way we can find gaps in our knowledge.

I felt there is a need to correct something that is fundamental but not technically accurate, as we all have a duty to serve the forum to weed out misinformation, to prevent other forum members from being confused.

I have eventually located the Slackbook in the #3 disk of Slackware 11.

It is possible the quotation was taken out of context. Here is the relevant text and the line that cause confusion is marked red.
It is noteworthy to point out the description is to create only 2 partitions using fdisk. As you can see the partition number allowed is between 1 to 4 and may be that is why you were wondering how one can install a Slackware in hdc59.

I believe the author could have the following in mind

(1) Since there are only 2 partitions involved there is no necessity in using logical partitions.

(2) The above red sentence may have meant "select the primary and not the extended". If an extended partition were created the author would have to spend more time explaining why, how an extended partition works and why not use the primary partitions etc, etc. He has already short-circuited his explanation by reducing the original 4 to 2 partitions to reduce the amount of explanation.

I could be wrong but I would not consider the above as the bible for not installing Slackware in logical partitions.
------------------------------------
Coming back to the partitioning tool of using fdisk

fdisk is the most robust partitiong tool I have come across as it reads the faulty disks when all other software have given up. However it is quite dated and offers no visual appreciation of the partitions, as you only get the chance to see the partition layout by pressing "p".

cfdisk program, also available in Slackware and all other Linux except the Red Hat family which uses sfdisk instead. cfdisk has a tabulated format so that you can see each partition as you are creating them. What is more the emtpy space is visible and so one can continue to create partitions until the space runs out. Thus one can create up to 60 partitions with cfdisk.

For reason I could not explain, as I don't know it myself, cfdisk and fdisk would not display partitions beyond the 60th although the declared limit is 63 and 15 for a Pata and Sata disk respectively. To get the 60th to the 63th one can use gparted.

I hope my reply isn't regarded as trying to win over the argument. It is never my intention. I just put the facts on the table to discharge my duty to the forum.

Thanks a lot for the info!!

And you dont have to be so "Gandhian" abt it all,("I hope my reply ... discharge duty .... welcome exchange of views... " ) its ok if you feel passionately abt something!! Infact its cool. As you feel that passionately abt it , you are ready to hammer down your point to me, even if I dont understand at the first go!

So to sum up, dont hesitate to say "RTFM you NOOB" (atleast to me. don't do it to others , the mods won't like it! bow to the mods. All your bases belong to them! )
If I wanted to be spoon-fed I would have installed SUSE.

The confusion about partitions comes about partly due to semantics.

Booting is when the BIOS reads in a boot sector, or chain booting reads in a boot sector.
Booting involves acessing the disk without any (or very little) filesystem information.
The boot sector code is usually altered in some way to reflect the actual location of the bootloader in terms of disk geometry.
All booting starts with a 512 byte program, which may load other code.

Loading is done by a bootloader, and usually requires that the bootloader understands the filesystem.
Bootloaders usually read an entire file or files, and may even do some parameter parsing or hardware configuration.
An example of that is NTLDR from Windows which uses NTDETECT.COM to do some hardware configuration and detection.

You can't boot LILO from a logical partition (logical drive).
LILO can be booted from the Master Boot Record (MBR) or a Partition Boot Sector (PBS) of a Primary partition.
LILO can load a Linux operating system from any kind of partition with a compatible filesystem.
LILO can chain boot to another partition. Theoretically ony a Primary partition is valid for chain booting, but it may be possible to chain boot to a logical partition.

LILO actually cheats a little, since it generates some block vectors to load Linux.
That allows LILO to know less about the filesystem during loading, but it also requires LILO to be reinstalled when the boot menu changes.
In contrast, GRUB knows more about the filesystem and does not have to be reinstalled when the menu or locations of files has changed.

The other confusing thing is the concept of an Active Primary Partition. The Active partition is only meaningful if you haven't installed LILO to the Master Boot Record and are using the "standard" MBR code.
The "standard" MBR code is a small chain loader that loads the Partition Boot Sector of whichever partition is marked as Active.
In "fdisk" or "cfdisk" the Active partition is actually called the "Boot" partition.

The BIOS knows nothing about partitions (from the standpoint of booting). The BIOS only reads the Master Boot Record of the Primary Master hard disk.
The "standard" MBR code extends the concept of booting to the partition table, which can contain four partitions.
Some other bootloader such as LILO installed in the MBR can extend the boot choices further.
LILO works just as well installed in a Primary partition boot sector as in the Master Boot Record.
The advantage to installing LILO in the MBR is that LILO always boots.
If LILO is installed in a Primary partition boot sector, then LILO boots if that partition is the Active (Boot) partition.
Really what happens is the MBR code boots, and then chains to the Partition boot sector which boots LILO.

I usually install Windows and Linux in a dual boot configuration. I like to install LILO in the Partition boot sector instead of the Master Boot Record.
I add LILO to Windows' boot menu, and I add Windows to LILO's boot menu. I can choose the default bootloader by changing the Active partition.
Whichever bootloader boots first can chain to the other bootloader (through the partition boot sector).
Recently I've started using GRUB, since the boot sector file used by Windows has to be created every time the LILO configuartion is changed.
Since GRUB does not have to be reinstalled when the boot menu changes, it is only necessary to create the boot sector file used by Windows once.

The only way that something could conceivably boot form a Logical partition is if some other bootloader code was booted first.
The BIOS is incapable of loading anything except the Master Boot Record.
The "standard" Master Boot Record can only chain boot to the Active Primary partition.
Though you might be able to install LILO to a Logical partition boot sector, it can't be booted by the BIOS.

thanks for the detailed post erik...
could someone tell me where the 4 partitions limit on the no. of primary partition comes from? is it arbitrary or due to some reason?

The four Primary partition limit is due to the standard for the Partition Table and Master Boot Record.

If you look at how a hard disk is partitioned, the first sector is the Master Boot Record containing the Partition Table.
That identifies up to four partitions, one of which can be an Extended partition.
The standard Master Boot Record chain loader only knows how to chain to a Primary partition's boot sector.

MBR (Partition Table)
PARTITION-1 (Primary)
PARTITION-2 (Primary)
PARTITION-3 (Primary)
PARTITION-4 (Extended)
LOGICAL-1 (not in Partition Table)
LOGICAL-2 (not in Partition Table)
LOGICAL-3 (not in Partition Table)
LOGICAL-4 (not in Partition Table)
...

The four partition entries in the Partition Table identify the exact location of each of the four possible partitions.
In an Extended partition, there is no information to indicate the location of the Logical partitions (drives).
Software has to iterate through each Logical partition's BIOS Parameter Block BPB (first sector) to find the next one.
Originally, there were no Extended partitions or Logical partitions, and the limit was four partitions for the whole hard disk.
Boot code (software) can rather easily locate each Primary partition's boot sector using the Partition Table. It isn't so easy to locate a Logical partition.
That's part of the reason why booting from Logical partitions is not supported by the standard Master Boot Record code.

There are really two issues with extending the number of Primary partitions. The first is of course, booting. The second is the problem of operating systems identifying partitions.
The only thing that is really "cast in concrete" is the location of the Master Boot Record in the first sector of the hard disk.
Everything else is defined by software. It's entirely possible to boot from anything (indirectly) by putting the appropriate code (software) in the Master Boot Record.
Software expects to find a Partition Table in the Master Boot Record but ignores the actual boot code (software).
Software expects to find a BIOS Parameter Block (BPB) in the first sector of each partition but ignores the actual boot code.

The installation of most bootloaders involves patching the Master Boot Record or Partition Boot Sector to update the code.
Some bootloaders store other information such as the location of a loader program along with the code.
There's always a tradeoff between the complexity of the bootloader, and the flexibility in choosing what will be loaded.

If one isn't concerned with compatibility, any hard disk partitioning and filesystem format can be used on a PC.
The only requirement is that the first sector of the hard disk contains software capable of booting the operating system.
To play nicely with other operating systems, at least the standard Partition Table should be supported.
Supporting the standard Partition Table also requires that the first sector of a partition contains the boot code for that partition.
Although most operating systems put a BIOS Parameter Block (BPB) in the first sector of a partition, that isn't an absolute requirement.
The BPB contains a lot of the same information as the Partition Table entry, and is mostly there for the convenience of the boot code.

An interesting development is the Intel Extensible Firmware Interface (EFI) which is going to completely replace the BIOS, partitioning and booting standards.
The boot information is stored in a database, and the operating system and boot code are more insulated from the actual disk format.

You still didn't tell me where did the number come from! Is it that there were only 2 bits available to store the choice and thats why the limit is 4 or something?

Thanks for all the info though!

I always thought there was only 1 BPB per HDD (just before the Boot Strap), atleast thats what I was taught for a Floppy.

Also, if it has to go through each BPB to go the next one (for logical partition).. then for someone like Saikee won't it be noticeable slower for the 60 partitions ?

There's nothing magic about the number four. That was just the number that was chosen when the Partition Table format was created.
It was probably kept to a small number for a few reasons.

• The boot sector is limited to 512 bytes
• Software has to have some limit on partitions for displaying them
• At the time nobody thought there would be more partitions required

Each partition table entry uses 16 bytes, so one 512-byte sector could theoretically have 32 partitions defined.
That leaves no room for any boot code. Four entries requires 64 bytes leaving 448 bytes for code (software).
The Partition Table uses up about 12% of the Master Boot Record.

When PCs first were developed they mostly booted from floppy disk.
The IBM XT supported a hard disk.
The hard disk initially just had one BIOS Parameter Block like a floppy disk.
I guess the correct term is really Disk Parameter Block (DPB) not BPB.
The only filesystem supported on PCs was FAT-16.

The next development was adding a Partition Table in the first sector instead of the Disk Parameter Block.
To keep things backward compatible, the Master Boot Record uses the same signature as a Partition Boot Sector.
The BIOS just loads whatever is in the first hard disk sector, checks the signature bytes and executes the code.

As disks got larger, people wanted more partitions. The Extended Partition type was added.
That still allowed three Primary partitions to contain operating systems.

The limitations on partitions are mostly historical, and if different choices had been made they might be different.

Since disk drives are much larger now, there is no need to be so frugal with disk sectors for boot code.
In fact, NTFS reserves 16 sectors for boot code instead of just 1. The boot code currently requires 7 sectors.

It would be entirely possible to reserve the first 16 sectors (or more) of the hard disk for a Master Boot Record.
The BIOS would still only load the first sector, but the first sector could just load the rest.
The problem would be existing software. Think of all the operating systems and disk utilities that would have to be changed.

Identifying the Logical partitions in the Extended partitions only has to be done once, so the time required is not important.
The reason that Logical partitions aren't in the MBR is simply because it would require changing the MBR to support more partitions.
It was possible to add a new partition type "Extended" without changing the format of the MBR.
Things that don't understand an "Extended" partition just see it as one big partition of unknown type.
That still allows a relatively dumb operating system that only knows about its own boot partition.

Erik_FL's description is accurate and I don't want to intervene.

However for those who have a problem of why can't we have more than 4 primary partitions here is my interpretation.

When a Bios finishes POSTing and has been instructed to find a system to boot (so that it can leave for its lunch break) it does so by reading the MBR of the first 512 bytes of the hard disk at the front end of the booting queue.

Every Bios loads this 512bytes into the memory and extracts the 64 bytes from the 447th to 510th position and anticipates the 1st 16 bytes describews the hda1, 2nd 16 bytes are for hda2, 3rd 16 bytes for hda3 and the 4th 16 bytes for hda4. (hda will be changed to sda if the disk is a Sata).

The above description is in Linux term assuming the loaded MBR came from a Linux.

The MBR will then boots its master using the partition table and the Bios loader is relieved of its duty.

MS systems has a common MBR that loads any one from these 4 primary partition if it has the booting flag made "active". This is why older MS systems must be installed in a primary partition if it is to be bootable.

If an extended partition is used it can only come from one of the primaries which has the exact layout but otherwise a different partiotion ID. The extended partition partition has no information on the number of logical partitions inside, or the addresses of any of them or any of their sizes. It does has the address of the begining, thus the location of the first logical partition, and the termination of the last logical partition.

Technically a boot loader has to scan more than one pass to obtain the hard disk locations of the logical partitions. Both Lilo and Grub can do the multiple scans and so able to find the a logical partition address and boot up the system inside.

There is no magic why a hard disk must have a maximum of 4 primaries. It is just just historical evolution. To change it will amount to scarping all the existing Bios and their mobo. One can devise a scheme to have 10o times more primaries but his/her scheme will not be compatible with the existing OSs. That is all.

As MS systems are happy with the 26 alphabets to denoting partitions in a box and Linux users seldom have a need to go to the 63 partitions limit in one hard disk nobody see any need to alter the 4 primaries arrangement.

The addresses of the logical partitions can be rounded up at boot time in one operation and so the drop in speed in trivial.

Actually, the BIOS doesn't know about partitions, it only knows about hard disks.
Changing the number of partitions supported wouldn't require changing the BIOS.
All the BIOS cares about is that the MBR contains 0xAA55 at the end.

The first byte of the MBR has to be executable code, but the rest of the sector can contain anything.
Since the smallest JMP instruction is 3 bytes, the first three bytes are always used for code.
It is actually the executable code in the Master Boot Record that uses the Partition Table.
Even though the BIOS doesn't care about the partition table, lots of other software does.

The BIOS identifies hard disks using a hexadecimal number that doesn't correspond to a specific partition.
All partitions are accessed using their absolute sector offset from the beginning of the hard disk.
Any software that deals with partitions has to add the base sector of the partition before giving the sector number to the BIOS.

0x80 - First hard disk
0x81 - Second hard disk (not second partition!)
0x00 - First floppy disk
0x01 - Second floppy disk

Linux assigns device names based on a pair of numbers (major / minor device ID).
The major device ID corresponds to an entire hard disk, and minor ID 0 refers to the disk.
Other minor IDs refer to partitions on the disk.
For example, Linux could assign devices like this.

hda - BIOS drive 0x80
hdb - BIOS drive 0x81
hda1 - First partition on BIOS drive 0x80
hda2 - Second partition on BIOS drive 0x80

Since Linux doesn't use the BIOS there isn't always a predictable mapping between the BIOS drive ID and the Linux device.

sda - BIOS drive 0x80
hda - BIOS drive 0x81

hda - BIOS drive 0x81
hdb - BIOS drive 0x80

When the device name "hda,hdb,hdc,hdd" doesn't match the BIOS drive ID you may have to tell the boot loader the correct drive ID.
For example, if you tell a boot loader to load Linux from sda1 and "sda1" is on the second hard disk, you will probably have to specify the drive ID (0x81)

It is the bootloader or operating system that figures out partitions on a drive, not the BIOS.
That's one of the reasons that the "fdisk" utility is not part of the BIOS.

hey, I finally understood why I have boot-as=0x80 in my lilo.

Anyways , tell me something ... (going a lot further off topic )

How does the BIOS know which drive is bootable or not? I mean , If I set the boot device property as

1> CD 2>HDD

how does it knw when CD is bootable or not ? How is it that it doesn't go to the cD and just hang (which it might if HDD is non bootable)

thanks

The Bios tries the first device. When no bootable system is found it tries the second device. It will continue to search for a system to boot in the order specified by the user.

yeah that I know, but how does it know wether a system is bootable or not ?

At the microproccessor level, it will try to transfer the instruction cycle to the 0 sector of the CD ROM and then how does it realize that the CD is not bootable and come back to the HDD?

That is the job of a boot loader.

The boot loader can fail and the system hangs without passing control to the next device.

I don't think the Bios cares if the system can boot successfully or not. If the boot loader has done its job I suppose there could be a handshake protocol or an interrupt signal so that the Bios can satisfy that PC control has been successfully transferred.

If no boot loader is found the Bios would report "No operating system found" or something to that effect.

The way that the BIOS tells if a device is bootable depends on the type of device.
For floppy disks and hard disks, "bootable" means that the first sector can be read and contains the signature 0xAA55 at the end.
For a CD-ROM or DVD-ROM "bootable" means that the disc contains a valid El-Torito header denoting a bootable disc.

After the BIOS loads and executes the boot sector, the boot code can later tell the BIOS that the device is not bootable.
Boot code uses "INT 18h" to reenter the BIOS and cause the BIOS to try the next device.
So, a bootloader can at some point decide that the disk is not bootable and go back to the BIOS.

As an example, the software in the MBR tries to find a Primary partition marked as Active.
If the MBR code can't find an Active partition, then the MBR executes "INT 18h".
The same thing happens in the Partition Boot Sector of a partition.
If the boot sector code of a Windows partition can't find the "NTLDR" file, then it executes "INT 18h".
Sometimes boot code displays a message "NTLDR is Missing" and then asks you to press a key before calling "INT 18h".

Devices like network controllers obviously have no boot sector that the BIOS can check.
The BIOS just calls the boot code in the network controller's BIOS and then the boot code uses "INT 18h" if unable to boot.

All the software that I've seen which writes the hard disk MBR assumes that the drive ID will be 0x80.
It's also common for code in the Partition Boot Sector to assume drive ID 0x80 (Windows does that).
Keep in mind that only applies to booting (reading in the bootloader, NTLDR, LILO, GRUB).
The drive ID applies to ALL partitions on the drive, so this doesn't limit which partitions can boot.
If the BIOS supports a choice of which hard disk to boot, the BIOS also shuffles the drive ID bytes.
Whichever hard disk is chosen to be the boot disk ends up with drive ID 0x80.

Floppy disks have a boot sector that always contains drive ID 0x00. You can't boot from drive B: (0x01).

CD/DVD booting adds another complexity to the whole process. El-Torito allows drive emulation.
When the CD is emulating a floppy disk, drive ID 0x00 accesses the emulated floppy on the CD.
When the CD is emulating a hard disk, drive ID 0x80 accesses the emulated hard disk.
No-emulation booting doesn't remap any drive IDs and the boot code on the CD has to figure out drive IDs.

Today, the BIOS is used mostly for booting, and operating systems use very little of the BIOS.
The BIOS supports some functions for configuration and power management that operating systems may use.
Mainly those are used during initialization.