[lfs-support] What Is "The" LFS Partition?
AFeuerbacher at ALLEGROMICRO.com
Tue Nov 6 10:59:18 PST 2012
> For your grandmother (-:
I'll be sure to forward your email to her. ;-)
Seriously, this is among the most useful articles -- and I do mean "article" -- that I've read about this topic. Thank you!
> Suggestion: Stick to MBR for now!
> When you have learned how it works, you may try out GPT.
Now I'm waffling about what to do, given that I've gone to the trouble of learning about and installing both GPT and LVM systems. I feel a lot more comfortable with the terminology and concepts now, given all the help from this list and other reading.
> 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.
>From other recent reading I now understand that this whole scheme is a kludge, and that's why it's not straightforward to understand. I always wondered why there was a limit of four primary partitions, and why there was even the notion of primary partitions, as opposed to extended partitions, at all. The extended type is a kludge.
> 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.
So "mount" essentially associates a physical location in a particular partition (say, the first few magic bytes of /dev/sda7) with a directory name ("/mnt"), no?
Why does one have to create a directory with that name before executing the "mount" command? Just because that's the traditional way mounting is done? Or are there more basic reasons? In other words, why could the "mount" command not create an actual directory (in the sense that "/usr" is an actual directory) if the directory requested in the mount command (say, mount /dev/sda7 /mnt/lfs) does not exist? I'm asking because this has caused me no end of trouble, because I've not seen in any documentation the requirement that said directory exist before doing the mount command.
> 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!
But LVM is touted as being easier to deal with than the older system. Is that not the case?
For example, last night I managed to make GPT partitions and an LVM filesystem on my new hard disk (earlier today I emailed this list with a blow-by-blow account of doing this), based only on material from Net searches. Now, if I can do that, I would think that the process is substantially easier than the old methods.
> 8) DISCLAIMER AND MY 5 CENTS
> 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
Something along those lines is what I'd like ultimately to do. But my wife keeps telling me I should get a Mac. :-)
> 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 -
Can you elaborate?
> I now find it much easier to just have
> the whole system on one partition.
Easier mainly because you don't have to create a lot more partitions?
> This may not be optimal for a production system, but for experimenting
> with LFS/BLFS/KaarPux it works great (for me).
Experimenting is what I'm doing, so probably that's the way for me to go.
> Good luck!
More information about the lfs-support