Hi Henrik,

> 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
> http://kaarpux.kaarposoft.dk/

Pretty cool!

> 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!

Thanks!
Alan
-- 
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