Hi, I'm reading a text on linux partions and file systems, it says:
My question is: why a linux distribution may have "no access to the kernel outside the first 1024 cylinders" on a disk?

Also, what does "putting the /boot partition at the beginning of the drive" mean?

PS. The text is extracted from "LPIC 1 Certification Bible"

This was a limitation of the BIOS and IDE drives years ago which is no longer a factor. Drives were divided into cylinders-heads-sectors which was used as an address to find data starting at zero. Cylinder 0 where the legacy MBR is located is the start of the drive. So creating a partition at the start of the drive is the beginning.

http://docs.freebsd.org/doc/3.3-RELE...os/limits.html

http://en.wikipedia.org/wiki/Cylinder-head-sector

1 members found this post helpful.

You are reading some OLD documentation.

This limitation goes back to old disk controllers that didn't implement logical block addressing, and instead used cylinder, head, sector addressing.

The problem wasn't with Linux, which didn't have any issues...

The problem was with the old BIOS in that it only used 16 bit numbers for addressing, so getting the right address would overflow the 16 bit value. Even then, getting it right involved tricks - like knowing that if you specified 64 heads, that the truncation (disks normally never had more than 16, and usually only 8... or 4) would still get the right head number (since it was always zero for the first head, and zero for the first sector)... but reduce the size of necessary cylinder to something it could handle.

Once the boot block is loaded, it was the loader that actually did the work - unfortunately, it still had to use the BIOS for I/O, so it had to remain with the clumsy limitations built into the BIOS.

Thus, keeping the cylinder to something less than 1024 would always work.


Now "putting the /boot partition at the beginning of the drive" is to place the boot loader into something under cylinder 1024... It was the original reason to have a /boot as a filesystem anyway - the entire partition had to fit in the first 1024 cylinders - cylinder 0, head 0, sector 0, through cylinder 1024, head <whatever the max number was>, sector <whatever the max was, usually 32>.

The result was that the master boot record (the MBR) was at the beginning of the disk (making it always cylinder 0, head 0, sector 0), and anything the boot program read from that block would also be readable by the BIOS disk input functions - thus putting the kernel file into the boot partition would make it available to the boot loader.

1 members found this post helpful.

That limitation most certainly does not apply to GPT disks.

Here is my partition layout:
As you can see, the EFI system partition is at the very "end" of the disk and it boots just fine.

The BIOS boot partition can be placed anywhere within the first 2TiB of the disk and it should still boot in non-EFI mode (GPT disks only).

1 members found this post helpful.

yes, in LBA mode, each sector is assigned to a single unique number. But how can this unique number lead the firmware to read the correct head and cylinder?

Also, now that it is no longer the probem with BIOS and boot loader, what is the current role of /boot directory?

The /boot directory holds your kernel & initial ramdisk images.

In EFI systems, /boot (/boot/efi in most distributions) must be FAT formatted as it is read by the firmware and also contains the boot loader/manager and it's configuration files.

It can also be used to store the PK, KEK, db & dbx keys needed for Secure Boot if you have a signed kernel image & boot loader/manager.

It now depends on the boot loader. The LILO loader read list of blocks to be loaded. Quite fast, but it depends on installing the boot loader each time you change the kernel. Grub knows about several filesystems. If you have grub you will see that the "stage 1.5" loader (grub legacy) has different filesystem support available. One of these is copied into the extended boot area of the boot disk. Grub2 does the same, though most of grub2 is now external to the /boot partition. This permits the boot loader to essentially, "mount" the filesystem and read from the disk according to the filesystem layout. This permits a more flexibility (at the cost of being a bit slower), and eliminates the need to reinstall the boot loader for each change. All that is needed is to put the kernel boot file in /boot, and adjust the grub configuration file. Since grub can follow the installed filesystem - it can read the necessary files.

Note, this still depends on the boot loader being able to read the filesystem that is used for /boot. It can't boot things it can't read - such as making /boot a ZFS filesystem (at least, not until a module has been written that would process it). It works fine for various ext filesystems, FAT, ... I understand it doesn't recognize btrfs yet).

One advantage to a separate /boot is that it becomes easy to make and restore backups.

One last thing - it isn't even necessary to have the /boot partition even mounted for the system to operate correctly. Once the kernel and initrd are loaded there isn't any need. Of course, if you are going to update the /boot files it will have to be mounted, but that is the only reason.

1 members found this post helpful.

The head and cylinder concept is no more required to access hard disk drives. Instead every OS uses linear LBA sector addresses counted from zero to end.