[lfs-support] What Is "The" LFS Partition?

Henrik /KaarPoSoft henrik at kaarposoft.dk
Tue Nov 6 09:04:51 PST 2012

On 11/05/12 14:24, Alan Feuerbacher wrote:
> Howdy,
> I've done a major reset by giving up on installing an LFS system on my
> old 32-bit computer, and am now installing it on a new 64-bit system.
> The new system now has Fedora as the host system. It's installed on
> /dev/sdb and I want to put LFS on a blank 256G SSD -- /dev/sda.
> In trying to format /dev/sda I'm running into a conceptual problem. I
> partition the disk into:
> /dev/sda1 for /boot
> /dev/sda2 Extended partition
> /dev/sda5 swap
> /dev/sda6 for /
> /dev/sda7 for /usr
> and so forth. This is following the suggestions in the LFS book, section
> When I go to section 2.3 to create a file system "on the partition", the
> book says:
> ################
> To create an ext3 file system on the LFS partition, run the following:
> mke2fs -jv /dev/<xxx>
> Replace <xxx> with the name of the LFS partition (hda5 in our previous
> example).
> ################
> What should "<xxx>" be in the above example?
> I'm confused because the book speaks of "THE" LFS partition, as if there
> were just one, but there are obviously a number of partitions.
> Alan
Hi Alan,

For your grandmother (-:


A disk is a piece of hardware. When you boot the kernel, it shows
up as a block device such as /dev/sda.
This block device represents the whole disk, basically seen as an
array of bytes. Each byte can be read and written by the kernel.


Since you may want to use different parts of the disk for different
things, you can partition it.
The kernel shows each partition as e.g. /dev/sda1, /dev/sda2, etc.
Each of those partitions are again block devices, basically seen as an
array of bytes. Each byte can be read and written by the kernel.

There are different systems which can be used to partition disks,
such as the MBR scheme (fdisk) and GPT.

Suggestion: Stick to MBR for now!
When you have learned how it works, you may try out GPT.

[ I guess I might receive some flaming on this, so just a disclaimer:
I am dualbooting with Windows, and have always used MBR.
Maybe I should look into GPT... ]


When you partition a disk, e.g. using fdisk, a "partition table" is
written to the first few sectors of the disk.

When the kernel boots up, it reads the first few sectors of the disk,
and if it looks like a (MBR or GPT) partition table, it creates the
block devices corresponding to each partition.

Basically, a partition table is very simple:
It just states that partition X starts at position N on the disk,
and continues for M bytes.

For historical reasons, the MBR scheme only allowed four partitions.
And (using e.g. fdisk) you can create exactly four PRIMARY partitions.
So, if you need four partitions or less, that's fine. But if you need
more, one of the four partitions (usually the last) can be an EXTENDED
partition. This extended partition (usually) covers the rest of the
disk, and in the beginning you will have an extended partion table.

So, in the end, you will have the one physical disk partitioned into
a number of partitions, each of them acting like an array of bytes,
plus a few sectors of management stuff:

|  /dev/sda
|  +--------------------------------
|  |  MBR + partition table
|  +--------------------------------
|  |  /dev/sda1
|  +--------------------------------
|  |  /dev/sda2
|  +--------------------------------
|  |  /dev/sda3
|  +--------------------------------
|  |  /dev/sda4
|  |  +-----------------------------
|  |  |  extended partition table
|  |  +-----------------------------
|  |  |  /dev/sda5
|  |  +-----------------------------
|  |  |  /dev/sda6
|  |  +-----------------------------
|  |  |  ...
|  |  +-----------------------------
|  +--------------------------------

Now the kernel / you (root) / programs can access several block
devices, i.e. arrays of bytes.


Now, for some uses, accessing a disk, or a part(ition) of a disk
as an array of bytes is just what you need:

The kernel uses swap, which is just images of memory written to disk,
and for this an array of bytes is just what it needs.


However, accessing storage as just an array of bytes is usually not
terribly convenient. So filesystems where invented.

When you format a block device as a filesystem (e.g. with mke2fs),
the first few bytes of the (block device seen as an) array of bytes
gets initialized with some "magic" values.

When the "mount" command is used on a block device
(e.g. "mount /dev/sda7 /mnt"), it looks at the first few bytes
for those "magic" values, to figure out which type of filesystem
is there. It then instructs the kernel to interpret the block device
as a filesystem of a certain kind.

A filesystem is basically an organisation of the block devices' array
of bytes in such a way, that you can access e.g. "mydir/file.txt",
and the kernel will ask the file system drivers to give you some
of the bytes in the block devices' array of bytes.

There are many different types of file systems, such as:
FAT/FAT16/FAT32: used primarily in Windows
NTFS: used primarily in Windows
ext2/3/4: used primarily in Linux
btrfs: used primarily in Linux
ufs: used primarily in *BSD
... and many others.

But they all have one thing in common: They "translate" the block
devices' array of bytes into a "map" from a path
(path = directory/directory/.../filename) to the contents of a file.

Suggestion: Stick with ext4 until you understand more!

5) LVM

LVM is great in many situations, however:

Suggestion: Do not play with LVM until you understand the basics!


Now let's rewind a bit...

When the computer boots, it executes the code in the BIOS.
After some initializations, the BIOS reads the Master Boot Record
(MBA) which is the first sector (512 bytes) on the disk.
The BIOS then executes this block of 512 bytes of code.

(There are many different BIOS'es out there, and you need to configure
the BIOS to tell it which disk device to use for boot).

The MBR is written e.g. when you install GRUB.
GRUB installs a small program which will access the "real" GRUB
to boot the system.


- the kernel sees the whole disk as an array of bytes
- using fdisk you may partition this into several sub-arrays
- each array of bytes shows up as a block device in the kernel
- any partition may be formatted with a filesystem if you wish,
   and then be mounted.


I have build LFS and BLFS a couple of times, and now created

On my disk I usually have
- possibly a Windows partion
- a swap partition
- one or two partitions with Fedora/Gentoo or other "stock" linux.
- several partitions for several LFS/BLFS/KaarPux systems
-- each of those partitions are ususally 64G to fit a whole system
    on one partition/filesystem

Although using several partitions for one system (e.g. /, /boot,
/usr, /var, /opt) has it's merits - in particular if you have a
power break and the filesystems are broken - I now find it much
easier to just have the whole system on one partition.
This may not be optimal for a production system, but for experimenting
with LFS/BLFS/KaarPux it works great (for me).

Good luck!


More information about the lfs-support mailing list