[Leaplist] Install Fedora Core 8

Fri May 2 18:46:55 EDT 2008

Another alternative (not necessarily better, but may suit some people) 
is to create TWO root partitions and a /home partition. This will let 
you try two distros, or upgrade without destroying your stable system 
while you tinker the other one. For convenience each system mounts the 
other root partition on "/other" or similar.

By the way, I have one of the root partitions as extended, and grub has 
no problem getting to it.

I don't use LVM, but it's not a bad idea.

Jim Hartley

John Simpson wrote:
> -----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-----
> _______________________________________________
> Leaplist mailing list
> Leaplist at leap-cf.org
> http://lists.leap-cf.org/mailman/listinfo/leaplist
> 

-- 
Teen Angel - a ghost story - http://teenangel.netfirms.com