On 12/18/2013 05:54 PM, Bruce Dubbs wrote:
> Dan McGhee wrote:
>> On 12/18/2013 04:09 PM, akhiezer wrote:
>>> And, again IIUYC re 'primaries': no such concept in GPT, at least not in
>>> pre-GPT sense; and in pre-GPT sense, yes, the spec only allows for 4 
>>> primaries
>>> anyhow.
>> This is another source of misunderstanding. May be too strong a word.
>> It's all vocabulary. MSDOS MBR's don't have the "bit length" to
>> physically support more than what is know as a "primary," as opposed to
>> "extended" partition.
> Not quite.  The MBR handles 32-bit words.  That gives addressing of up
> to 4G of 512-byte partitions.  That's how you get the 2T limit.  The
> limit could be higher if the block size is 4K, but that creates a lot
> more problems for the legacy BIOS, so it's better to just use GPT that
> has 128-bit lengths for sector addressing.  That's enough for a zetabye
> or so even with 512-byte sectors.  Try to run fsck on that!  :)
>
> Extended partitions have the same limitations as MBR primary partitions,
> but there are just in a linked list and not an array.
>
>> I don't have a "pdf reader" set up on my new LFS
>> yet so I can't refer to an article I'm thinking of. But if I remember,
>> the "old" MBR is 16 bit. The UEFI bios firmware is 128 bit. There, of
>> course, is a limit to the number of partitions, but it's large. :)
> I think it is 128 partitions by default, but it can be made to handle more.
>
> Another difference is that classical systems start the first partition
> at the 2nd 'physical' track (often faked in drives) of 63 sectors.  That
> leaves about 31K for the GRUB2 code.  For GPT, we make a raw boot
> partition for grub, usually 1Mb, that give it lots of space for
> expansion, but is negligible compared to the whole disk drive.
>
>   From our perspective, the only thing that is needed is to load one
> 512-byte sector into memory and execute it.  The bootstrapping continues
> from there and only needs very basic BIOS calls to load other sectors
> into memory.  Of course after booting, the kernel does not need the
> BIOS/UEFI at all.
Bruce, I think we're saying the same thing and are being limited by our 
language--at least from my side of the fence.

I would provide a link to the article I have used in my research, but 
I've misplaced it. I am sorry for a long quote, but I wanted to provide 
it to show why I think we're saying the same thing. The notes at the 
bottom of the pages of this article by John Lang say "<page no.>LFX 
March 2013." (Linux Forum Journal (????))

> The BIOS was originally devised as an interface between hardware 
> devices and the Disk Operating System (DOS, more commonly known as 
> MS-DOS). It was, and remains, a 16-bit real-mode programme. As 
> operating systems have evolved through the years to 32- and now 64-bit 
> code, they no longer use the BIOS interface, but contain their own 
> device drivers instead. The BIOS’s role has been reduced to beginning 
> the boot process, and is largely irrelevant once the operating system 
> has booted.
> The MBR serves two purposes: it contains the bootloader that the BIOS 
> executes to boot the computer, and it contains the partition table 
> that defines the location of the filesystems on the disk. All of this 
> information is stored in the first sector (called sector0) of the 
> disk, and is therefore limited to 512 bytes: 446 bytes for the 
> bootloader, and a partition table containing up to four 16-byte 
> records. The last two bytes contain a signature that the BIOS uses to 
> recognise a valid MBR. The partition tables use 32-bit sector 
> addresses fields, which means they can’t address disks larger than 
> 2TiB. This type of partition table is often referred to as an MSDOS 
> partition table in an attempt to differentiate it from the new GPT.
> The problems with this configuration include being limited to one 
> bootloader, the limitation of
> four partitions and the 2TiB maximum disk size. The UEFI supports 
> multiple bootloaders, and the GPT supports up to 128 partitions and 
> works with disks that are bigger than 2TiB. The other thing that UEFI 
> brings to the table is the ability to secure the boot process.
> Because the BIOS expects the bootloader to be located in the first 
> sector of the disk, there can only be one per disk. Most BIOSes allow 
> selection of the boot disk and, therefore, can support as many 
> bootloaders as there are physical disks. In contrast, UEFI ignores any 
> bootloader in sector 0, but instead allows multiple bootloaders to 
> exist on a single disk by using a special partition instead of an 
> absolute sector. The special partition is known as the EFI System 
> Partition, or ESP, and is formatted with a FAT filesystem (usually 
> FAT32) and typically sized between 100MiB and 250MiB. The UEFI 
> specification requires it to be the first partition and that it must 
> have its boot flag set. On a Linux system it is customary to mount the 
> ESP under /boot/efi. Convention dictates that bootloaders are stored 
> on the ESP in vendor-specific sub-directories....

As an interesting, I think, side light, a panel in this article says:

> Hard disks have increased in size beyond what the MSDOS partitioning 
> scheme can handle. It can’t address disks larger than 2TiB because the 
> partition tables store sector addresses as 32-bit numbers, and this 
> means that there can’t be more than 2^32 sectors. As each sector 
> contains 512 bytes, this gives a maximum size of 2TiB. The new GPT 
> partitioning scheme overcomes this limitation by using 64-bit fields, 
> and these allow storage of 2^64 512-byte sectors, or 8ZiB (9.4ZB).
> That is more than all the storage currently existing in the world.

I apologize for posting quotes from articles. Because I've gone through 
a number of laptops in the last two years and am now migrating from 
Ubuntu to LFS, my archiving is a bit jumbled and things aren't were I 
expect them to be. I'll be straightening that out in the next couple of 
weeks. This is one of the references the link to which I was going to 
provide in my adjunct to the write up for booting using the efi-stubs of 
the kernel.

I also wanted to post it in this discussion because, at least in my 
mind, the concepts of BIOS, UEFI, GPT and partitions get jumbled. This 
article articulates in clear language, which is good for me, the 
situation. In fact, re-reading this quote refreshed my memory. This 
whole discussion of GRUB and UEFI is not relevant for hardware older 
than 2011--Windows 7--and not 64-bit.

Dan


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Reply via email to