[Leaplist] Install Fedora Core 8

[John Simpson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-05-01, at 1224, William H. Ferguson wrote:
>
> So, I conclude that since I have installed the "Default  
> Partitioning" all of the Hard Drive's
> space has been taken up by that choice.
>
> My question is:  How can I clean everything off the Hard Drive, now  
> apparently jam-packed full of the Default Installation?

boot into a "live cd" of some sort.

open a terminal window, and become root.

run "fdisk /dev/hda" (or /dev/sda, or whatever device corresponds to  
your hard drive.)

delete all of the partitions. use "p" to print the current partition  
table (to see what's there already) and "d" to delete a partition.  
delete them in reverse numeric order (i.e. from highest number to  
lowest number.)

quit, saving your changes (i.e. the "q" command.)

then boot the install CD for whatever you want to install. the  
installer should see a blank hard drive and allow you to set things up  
however you like.

the next question, "what's the best way to partition the disk?" is  
somewhat of a religious issue with some people, much like the "vi/ 
emacs" holy war from days of old. at the risk of starting another  
battle, this is how i personally do it:

on a system using IDE drives, where the BIOS may not be able to  
directly address partitions which extend beyond the first 1023  
cylinders of the disk, partition #1 is 75 to 150MB, formatted using  
ext3 (or whatever filesystem you like), mounted on the final system as  
"/boot". this is because the kernel, and the initrd (initial ram disk)  
image which contains the device drivers, need to be able to be loaded  
by the boot loader (i.e. grub, lilo, or something similar) which at  
that point only has the BIOS services available to access the disk.

the (first or next) partition, at or near the beginning of the disk,  
is the swap space. i put this at the beginning because filesystems  
normally fill from the beginning toward the end, so the disk head will  
be closer to the beginning of the main partition most of the time- and  
if the system needs to swap, having the swap partition near the  
beginning of the disk means the system doesn't have to wait so long  
for the disk head to move into and out of the swap partition.

after the swap, i usually have one large partition, mounted as "/",  
using the remainder of the drive. i do this because i've run into too  
many problems where one partition will fill up but the rest of the  
system is fine.

with that said, it may make sense to do something else on some  
machines. maybe you're going to be doing something which generates  
large log files, and want to have "/var" or "/var/log" as a separate  
partition which, if it fills up, won't kill the rest of the system. it  
just depends on what you plan to do with the machine.

however, i've found that the "one large /" strategy works fairly well  
for about 90% of the machines i've built over the years, and is in  
fact how my own server is built (actually, the MACHINE is running xen  
and LVM, and the xen child session which is my server has the "one  
large /" partition.)

another strategy, especially for somebody who's experimenting and who  
has a lot of disk space available to play with, is to use LVM (linux  
volume manager.) this is a lot more flexible than traditional  
partitioning schemes- the idea is that you create a VG (volume group),  
which is a pool of disk space made up of one or more PVs (physical  
volumes, or physical partitions as you're used to seeing them.) once  
you have a VG defined, you can allocate LVs (logical volumes) from  
that pool of space as needed.

the advantages of this are:

- - you can have more than 4 (or 8, or 16) partitions- you can have up  
to 256 LVs within a VG. and you can create, modify, and remove them  
without having to reboot (unless, of course, you need to modify the LV  
containing your "/" partition, in which case you need to boot into  
"something else" like a live CD environment before making the change.)

- - you can resize LVs on the fly. some filesystems can't support being  
resized after being created, but ext3 supports it without any problems.

- - if the VG is running out of space, you can add another physical disk  
to the machine, create an "LVM PV" partition on it, and add the PV to  
the group... and you immediately have more space available within the  
group to create new (or extend existing) LVs.

this is what the "default disk layout" used by the installers for  
fedora, centos, and a few others- if you see something involving  
"VolGrp00", you're using LVM already.

using LVM also requires that you create a separate "/boot" partition  
on the first hard drive, but that's only because grub doesn't  
understand LVM. basically, create the /boot partition, and if you're  
not planning to use virtualization, create a swap partition as well...  
but then create an "LVM physical container" partition using the rest  
of the disk, create an LVM volume group which uses that space, and  
then create an "LVM logical volume" big enough for the system you want  
to install- usually 5-10GB is enough for a full system with a graphic  
desktop. tell the installer to use that "logical volume" as the "/"  
partition, and go to town.

again, the xen host uses LVM to manage disk space, and the xen  
children are configured with LVs as the "physical device" underlying  
what they see as /dev/xvda1 and /dev/xvda2. so if one of my child  
sessions needed more space, i'm able to shut down their child session,  
resise their LVM container, resize the ext3 filesystem within the  
container, and start it back up again (assuming i have the space  
available- at the moment the machine only has about 5.5GB not  
allocated.)

- --------------------------------------------------------
| John M. Simpson  --  KG4ZOW  --  Programmer At Large |
| http://www.jms1.net/                 <jms1 at jms1.net> |
- --------------------------------------------------------
|   Hope for America  --  http://www.ronpaul2008.com/  |
- --------------------------------------------------------





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIG5VcEB9RczMG/PsRAu7mAJ4v/xzkWTqb6ctBOK03NO/rHpbd6gCfYhkD
ZCttUlQmyOYqCMPJIsl/TB8=
=09gx
-----END PGP SIGNATURE-----