Is the boot sector really just the beginning of a drive?

First, I am assuming that drives and/or partitions have a linear address from start to finish. This must be the case, or else programs like dd would not be able to function as a copying mechanism.

Is the boot sector pretty much always just address 0 in this array of bytes? I suppose it depends on the filesystem being used on that drive?

Sorry I'm really not knowledgeable about these low-level things, and I want to learn!

Yes, the boot sector is always in sector 0 for MBR. The hard drive is divided into sectors which traditionally are 512 bytes, but 4TB+ drives are starting to use 4096 byte sectors.

You have to read or write an entire sector.

Today LBA, Logical Block Allocation, has a standard progression of sectors from 0 to the capacity of the drive.

Ancient hard drives actually use Cylinders,heads, and sectors. Wherein each head held so many sectors and each cylinder held so many heads.

The file system doesn't start in sector 0 instead the partition table indicated the start of the partition, so file systems play no part in this.

Also GPT has started to replace MBR as MBR has a limit of approx 2.2TB and has a convoluted way of representing more than 4 primary partitions. You need logical partitions and each extended partition can contain many logical partitions.

GPT has done away with many of the complexities and updated and simplified things.

Here is more details.

https://en.wikipedia.org/wiki/GUID_Partition_Table

First, we'll need to specify the partitioning scheme used. The classic one for PCs is the MBR, which shares the name with the very first block of the disk (logical block address #0) in this partitioning scheme: the Master Boot Record. So, the answer to the question title for MBR partitioning is yes.

The Master Boot Record contains a maximum of 446 bytes of boot code, the partition table for primary partitions (only 16 bytes per partition) and a boot signature (2 bytes). Of each 16-byte partition entry, only 4 bytes are actually useable for specifying the first block of a partition on modern disks, and only 4 bytes for specifying the number of blocks in a partition. As a result, the starting point of a MBR partition must be within (2^32 - 1) blocks from the beginning of the disk, and the size of a MBR partition must be (2^32 - 1) blocks or less. In practice, this limits the usefulness of MBR partitioning to disks of 2 TB or less.

Traditionally, the MBR boot code would just identify the active primary partition, load the first block of that partition (sometimes called a Partition Boot Record, or PBR) and execute it. The PBR would then contain an operating-system-specific boot program. But modern bootloaders, like GRUB for Linux, or some full-disk encryption solutions, may wish to do more complex things and so won't fit in a single block.

In an old disk, back when the Cylinder/Head/Sector geometry values actually had some actual meaning, the entire first track of the first head of the disk was reserved for the MBR block alone: the convention was to start each partition at the beginning of a track, so as track #0 had its first block occupied by the MBR, the entire track was skipped, and the first partition would start at track #1 instead. As a result, the sectors on track #0 after the MBR block were available for use by more advanced bootloaders. On a MBR-partitioned disk, the GRUB bootloader will usually embed at least some parts of itself in there.

On modern disks, where LBA addressing is the norm, a new convention was established: the first partition would normally start at logical block address #2048, or exactly 1 MiB from the beginning of the disk. This would ensure that even if the disk would internally handle the blocks in groups of some power-of-two, the start of the first partition would still be aligned with the beginning of such a block group. On RAID arrays and other larger storage systems, such data alignment can be an important part for getting full performance out of the storage. As a side effect, this new convention was likely to cause even more "wasted" space between the MBR block and the beginning of the first partition.

In 2011, when the Intel Sandy Bridge microarchitecture was released, the new UEFI firmware was introduced to the masses, to eventually replace the traditional BIOS. Along with it, came a new partitioning scheme: GUID Partition Table or GPT for short. Since the MBR had a pretty fundamental maximum size limit of 2 terabytes (assuming the standard block size of 512 bytes), a new scheme was needed.

The GPT partitioning scheme actually contains a "protective MBR": the very first block (LBA #0) of a GPT-partitioned disk contains a valid MBR block that essentially says "this disk has been fully allocated to a partition type you don't know about, don't touch" to systems that only understand MBR-style partitioning. Starting from LBA #1 is then the actual partition table data of the GPT. It allows partition sizes to grow into the zettabytes range - that should be plenty for the foreseeable future.

The GPT partitioning scheme does away with the restrictions of MBR:

• With GPT, there is no longer a limit of only 4 primary partitions per disk.
• The MBR-style division of primary/extended/logical partitions no longer exists: all partitions are equal in that sense.

The UEFI firmware also specifies a new bootloader scheme. The bootloader no longer has a fixed location on the disk. Instead, the firmware will have a built-in capacity to read files from a FAT32-type filesystem, and a bootloader will be just a regular file on a FAT32 partition marked with a specific partition type GUID. Such a partition is called ESP, or EFI system partition. (UEFI firmware standard was developed from EFI firmware, which existed mainly on Intel Itanium systems, and the name and structure of the bootloader partition was inherited from there.)

So, for other partitioning schemes, including GPT, you cannot assume the boot sector is the first block on the drive - in fact, you cannot assume that the concept of a boot sector even exists!

I suppose it depends on the filesystem being used on that drive?

No. At least on a PC-compatible computer it cannot depend on the file system used.

Why?

The BIOS is responsible for loading the boot sector from the hard disk. Because it does not know about the file system used, it will always do the same. And this means: Loading sector #0.

On non-PC-compatible systems, the boot sector may be located elsewhere.

On systems with UEFI, booting also works differently.

By the way:

When booting from CD-ROM, the BIOS searches for a special sector which may be located somewhere after sector #16 (not 100% sure). This sector will contain information about the location of the actual boot sector. The BIOS must understand this information to be able to load the boot sector from the CD-ROM.

So on CD-ROMs, the location of the boot sector is indeed not sector #0 of the CD-ROM.

Drives are split into logical sectors (which may not be the same as physical sectors), normally of 512 bytes. Some APIs may present a drive as a linear sequence of bytes but the actual interface protocol works in terms of whole sectors.

In the traditional PC BIOS sector 0 of the drive was/is known as the master boot record and contains both the initial boot code and the partition table. Individual partitions also had sector 0 as a boot sector. Traditionally under dos/windows the code in the MBR would identify the active partition and pass off code to the boot sector of the active partition.

Linux systems running on traditional PC bioses usually do things a bit differently. Typically a grub "stage 1" is installed in the MBR. This loads "stage 1.5" from the empty space in-between the MBR and the first partition. Stage 1.5 has enough capabilities to understand filesystems and load "stage 2" from a file-system on one of the partitions. Stage 2 then goes on to present the boot menu and load the kernel.

UEFI and it's partition table type GPT handle things rather differently. Sector 0 now contains a "protective MBR" that hopefully reduces the risk of non-efi aware tools accidentally destroying the GPT partition structure. The GPT partition table itself is stored starting in sector 1. The firmware is filesystem-aware and loads the boot loader from a partition.

Non-PC systems can be different again. Arm systems in particular can be all-over the map in terms of their boot processes. IIRC the imx6 boots from a hard drive by reading boot code from sector 1, leaving sector 0 free for the partition table. The raspberry pi on the other hand expects to find a MBR style partition table with a FAT partition containing it's boot code.