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 > 2.2.1.3. > > 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 (-: 1) DISKS 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. 2) PARTITIONS 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... ] 2a) TRADITIONAL PARTITIONS 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. 3) SWAP 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. 4) FILESYSTEMS 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! 6) THE MASTER BOOT RECORD 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. 7) TO RECAP So: - 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. 8) DISCLAIMER AND MY 5 CENTS I have build LFS and BLFS a couple of times, and now created http://kaarpux.kaarposoft.dk/ 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! /Henrik -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
