An experiment in collective intelligence. Stupidity. Whatever.
The following is my recommended partitioning for a typical workstation/server Debian GNU/Linux x86 box. You can also find useful guidelines the the Filesystem Hierarchy Standard (FHS), part of the debian-policy package, and the the Large Disk HOWTO.
This document was originally located at http://kmself.home.netcom.com/Linux/FAQs/partition.html as "Linux Partitioning mini-FAQ". Copied here by the author.
Ranges in my experience work.
You do not need to create all of these partitions. The order listed is the order in which I would recommend partitions be created, space permitting. That is, if you have a very small system with < 200 MB total storage, you might create only root (/) and swap. As more space is available, partitioning out more space becomes possible, and in my experience, advisable. If at all possible, I recommend root, swap, /usr, and /tmp. Additional details below.
| Partition | Size |
|---|
/ | 64 - 200 MiB |
| swap | partitions sized to current RAM up to 2GB, repeated to max installable RAM* |
/usr | 1 - 4+ GiB |
/boot | 24 - 48 MiB |
/tmp | 64 - 256 MiB typically. 1 GB+ in some cases (CD burning, etc.) |
/var | 512 MiB - 2+ GiB |
/usr/local | 1 - 2+ GiB |
/home | remainder |
| Additional | As needed for partitioning, workflow, performance, or storage |
For swap, see NixPartitioning#Swap.
A question that's frequently asked is what the use of partitioning is in the first place. After all, doesn't partitioning date back to times when a disk of a hundred, or even tens, of mebibytes, was considered large? Yes, somewhat, but there are other reasons:
- Reliability: Disk corruption tends to be specific to a given partition. By subsetting your disk(s), you're reducing the amount of space that's going to be effected by any given disk error. If part of your disk goes south, you'll still likely have most of your system available.
- Containment: It's very helpful to contain runaway processes. By restricting
/tmp and /var to their own partitions, you're pretty sure to have space available on the root filesystem or /home even if some process goes crazy with its tempfiles, or your system logs fill up.
- Security and privileges: By separating out your partitions, you can assign permissions appropriately. As a matter of course, only root need be mounted with device permissions, it and
/usr are the only partitions needing SUID permissions, /usr can be mounted readonly for the most part, etc. While these permissions can be changed without unmounting a filesystem, they may prevent some system exploits, and will almost certainly keep you from shooting yourself in the foot at some point.
- Backups: many backup utilities are partition based, or can be instructed to follow (or restrict themselves to) partition boundaries. Seperating system partitions (root,
/boot, /etc, /usr, /var) from locally managed (/usr/local, /home) and temporary (/tmp) makes system upgrades and migrations easier to handle as well.
- Management: With separate partitions, it's possible to back up one partition to another while performing administrative tasks. This is useful when performing, say, the ReiserfsShuffle, the partition dance needed to convert from an ext2 to a ResierFS? filesystem. If possible, having two large filesytems of comperable size may be helpful for on-system management.
- Overdoing it: yes, you can have too many partitions. Beyond a point, partitioning creates more issues -- you're subdividing your system, cutting into useable space, and adding complexity -- than you're solving. For small systems (< 500 MiB), root,
/usr, and swap may be all you need, with /tmp, /var, and /home symlinked under /usr. By priority, I'd create: root, swap, /usr, /boot, /tmp, /var, /home, and /usr/local as separate filesystems, with increasing space.
Linux really doesn't care. MS WinXX? prefers a single primary partition, though multiple primaries are possible as an undocumented feature on most Legacy MS Windows variants. Suit your preferences if you're multi-booting. I tend to create three primary partitions, one extended, and the remainder logical. / (root) usually goes on the first partition and is marked bootable, though as with most things, you have other options. YMMV.
I go with 3x physical RAM, in two or three separate swap partitions. A handy trick is to create three partitions each the size of your current memory allocation. As you increase memory allocation over the life of the system, you can activate additional swap partitions, it being easier to add memory than repartition disk, by adding them or uncommenting them in /etc/fstab.
With the 2.4.x and later kernels, GNU/Linux can support swap in excess of 2 GiB, with individual swap partitions of up to 2 GiB. This is more swap than you'll probably want to be using on a typical basis (e.g.: if you're filling all your swap, something's wrong). But if you need it, it provides you a buffer when the system does go into a memory-overrun condition, and there's a world of difference between having many applications loaded, some of which are swapped, and many applications loaded and actively paging in and out of swap (former is OK, latter indicates you've got too much load, too little RAM, or both). Typically, things will get so slow that you'll notice something's wrong. The extra swap should buy you time to shut down the offending process(es). Other sources say to provide 2x physical RAM, many preconfigured boxes come with 1x RAM as swap, which I see as shortsighted (see prior comments regarding adding memory vs. repartitioning).
For an excellent explanation of why you should create swap partitions regardless of how much RAM you have, see Martin Pool's Is swap space obsolete?
and followup on free memory.
Another religious issue. I start with the scheme illustrated above because:
- / needs to be mounted for the system to boot -- but other than
/bin, /boot, /dev, /etc, /initrd, /lib, /root, and sbin, other directory trees don't have to be mounted. Increase your chances for a clean boot by reducing the inodes at risk. You are also then able to mount other partitions nosuid and/or noexec and/or read-only, for additional security. The entire partition can be duplicated elsewhere on- or off-line for additional security.
- /usr -- Largely stable. Can be mounted read-only except for package upgrades.
- /boot -- Largely static. Can be mounted read-only except for kernel upgrades.
- /tmp -- highly variable. Don't risk .your root partition, isolate this content. Mount noexec and/or nosuid for added protection.
- /var -- likewise, highly variable. Mount noexec and/or nosuid for added protection.
- /home -- Variable content, usually most sensitive data both in terms of security and integrity. Can be mounted nosuid.
- /usr/local -- Largely stable, and not part of the packaging system. Can be mounted read-only, possibly nosuid.
At this point, you may choose to add additional partitions if desired to match local storage, application, or hardware needs and/or limitations.
There are those who argue for a minimum set of partitions, just root, swap, and /usr, or sometimes just root and swap. While you can certainly do this, there are problems:
- Any filesystem corruption affects most (or all) of your data.
- If you want (or need) to park data on another partition...you don't have one. Particularly useful when, say, doing the ReiserfsShuffle.
- Runaway files on one tree affect all trees. One advantage of a small
/tmp is that if a file starts growing out of control, you find out relatively soon, and have several spare partitions to park temporary files.
The arguments against overpartitioning tend to boil down to wasted "slack" space, and issues in repartitioning alter.
Slack space is the unutilized storage in partitions -- it isn't shared with other "full" partitions. With growing disk size (120 - 200+ GiB is now common), and the fact that system partitions as I suggest them total ~6GB, that leaves 104-194 GB of unallocated space. My recommendations would put this to /home. The wasted space argument doesn't hold water.
While more partitions may require repartitioning, it also tends to make this easier as there is space to park data while in the process. Aditionally, partition resizing tools (parted, reiserfsprogs, ext2resize) may be used to modify partitions on the fly. LVM, LogicalVolumeManager?, is another method for (relatively) painlessly managing partitions.
I provide some guidelines to utilization patterns and mounting options, as well as whether the partition is typically capable of being served over a network.
Static means that partition contents change little. Variable means they change a lot.
Mount options typically restrict features of the partition, including whether it can support executables, SUID files, and device files. While content on "static" partitions can change, it typically doesn't over a normal use cycle, and is only modified during system upgrades. Debian provides options to allow remounting partitions as writable and/or read-only during t..he upgrade process, see system documentation for more information [Ed: I should be more specific, it's apt related stuff 2001/04/13].
Note that while mount options can restrict settings, it's possible to "remount" a partition in place, and that this doesn't produce system warnings or messages. Think of this as protection against stupid mistakes and low-grade mischief, but not a significant bar to a determined cracker.
Networkable partitions can generally be shared among several systems. The distinction is that certain data, particularly those generating much I/O, or have data pertaining to local hardware and configurations, should be local to the system.
A minimal GNU/Linux system can fit on a single 1.7 MB formatted floppy disk
A useful recovery system (or partition) can fit in 30-200 MB.
For a useful desktop user system, I'd recommend 6 GB total storage, though with package selection, a 1 or 2 GB system can be created.
"Kitchen sink" or very complete power desktop user systems with large audio or video archives can easily chew up sever hundred GB, though your system allocation would typically be 6-10 GB total.
- /: A minimal installation can fit in 30 MB or less. Recommended is now 132-200 MB. I've generally allowed ~96 MB (going for round base-two sizes). However as kernels, and more significantly, kernel modules in stock kernel builds grow, this isn't enough space for two or more kernels and their libs. Journal files for ext3 or reiserfs filesystems also take their cut -- about 32 MB for a Reiser journal file. A recent 2.4.21 stock debian kernel package was almost 23 MB, and I'm finding myself running out of root filesystem space, typically in
/lib/modules. If you're using more than ~150 MB, you've probably included something in your root partition you don't need. Largely static, executable, suid, local.
- /tmp: Values suggested should work for most systems. /tmp is system temporary storage. If you've got specific applications with very large temporary storage requirements (e.g.: database, analytic tools, multimedia), you're better off allocating storage to these needs specifically. Some CD brning software expects to be able to create images in /tmp, and I've also found that the
mc program may cache large sent files in /tmp as well, which may raise your size requirement to above 1 GiB. I find this fundamentally troubling in some vaguely indefinable way. PCMCIA users note that most PCMCIA utilities expect to find /tmp to allow creation of device files. I've hacked my /etc/init.d/pcmcia file to provide for this by temporarily remounting the partition with the dev option. Variable, non-executable, non-suid, nodev, local.
- /var: if you're running extensive services (news, mail, website), you may want to increase this allotment significantly. Often various /var/spool subdirectories become their own partitions. Such partitions may consume hundreds of MBs to multiple GBs. For recent Debian releases, package lists and archives can push requirements to 1-2 GiB, and the higher end of that for a richly populated workstation. If you are planning a large local proxy or cache (say,
apt-proxy or squid), allow additional space upwards of 10 GB, or symlink to a larger partition such as /home. Highly variable, non-executable (?), non-suid, nodev, local.
- /usr: A minimal installation can fit in a few hundred MB or less. Likewise, if you have to install all packages and docs, or sources for multiple kernels, you may find 2GB is too thin, consider doubling the allocation. Adding full documentation sets (particularly HOWTOs or Linux Gazette archives) and multiple kernel sources may push you over 3 GiB. Tune to your needs. Static, executable, suid, nodev, networkable.
- /usr/local: This is where software installed directly by you, outside of the Debian packaging system, goes. Tarballs, binary non-deb installations, and locally built software. Again, if you're installing lots of stuff or very large packages, you could easily utilize several GB of space. Static, executable, non-suid (usually), networkable.
- /home: User directories, sometimes also where services such as websites, ftp sites, and databases are parked. On workstations and shared, directly-accessed systems, usually the largest single (or aggregate) storage area. In special-purpose or embedded systems may be lit.tle more than a vestige directory on the root filesystem. Variable, non-suid, nodev, networkable.
- /usr/src=, =/usr/local/src: depending on space constraints and variability, you may want to create these as separate partitions. Variable, non-executable, non-suid, nodev, networkable.
- OtherOS: If you have a multi-boot system, you'll want to allocate space for other OSs as appropriate. Tools such as VMWare and Samba may allow you to both run and access these partitions natively from within Linux.
- Sub-partitioning: I've running a set of (now) relatively small drives -- 2/2.4 GB each. As a result I've split out several subdirectories of
/usr and parked them on other partitions. While this is possible, it's probably generally best not to subdivide your filesystems overly much -- it does increase system complexity and management. Unless this is required by space constraints, I'd suggest not doing it. But if you need the option, it's there.
- Large filesystems: With single-disk sizes in excess of 200 GB available now or in the near future, more generous partitioning schemes are possible. My suggestion is to generally follow the guidelines suggested above. Even a "kitchen sink" installation is unlikely to require more than several GB storage for
/usr. A /usr/local partition might call for a larger allocation, particularly if large third-party applications are being installed. I would apply most of the discretionary storage as suits system needs. For example:
-
/home for a personal workstation.
- File storage for a fileserver.
- Mail, Usenet, or print spools for heavily taxed servers of respective function.
- Database and/or website storage for a large database or web server.
The following are simply my preferences and/or recommendations.
- /opt -> /usr/local (or
/usr/local/opt) I recommend creating /opt as a symlink to /usr/local as this rationalizes space and conforms to typical third-party application preferences. Some applications like to go under /usr/local, others under /opt. This link supports both transparently.
- /net This is a mount point for networked drives. Any SMB, NFS, or other partitions show up here.
- /mnt The starting mount point for removable media and temporary mount points. Usually contains
/mnt/floppy, /mnt/cdrom, /mnt/zip, /mnt/jaz, etc. Keeps your / partition cleaner and makes system backups a bit more rational.
Update, April, 2001.
Time changes all things. After a year and a half or so of running the configuration dating from my November, 1999 completion of a Red Hat-to-Debian conversion of the box, space was getting a bit pinched. I spent a day doing some partition rationalization to provide more usable space. Though sizes haven't changed much (mostly a slightly larger /usr, a slightly smaller /usr/local, and a fewer partitions overall, this gives me a bit more breathing room.
I've also acquired a laptop with a (by my old-fart standards) huge 20 GB drive (this will seem paltry in four years, I know Moore's law). So I've now got a partitioning example that's a bit more reflective of current (as of 2001Q2) hardware specs.
The primary changes are:
- Elimination of
/usr/doc and /usr/src, split-out partitions I'd created on account of an overflowing /usr partition.
- Increased size of
/usr from 1.2GB to 1.9GB.
- Decreased size of
/usr/local from 1.5 GB to 1.2 GB. Elimination of some data stored there made this possible.
- Increased size of
/var from ~300 MB to ~580 MB.
- Increased size of
/tmp from 100 MB to 250 MB.
-
/mnt/misc1 became /usr/local/data, and shrank from 1 GB to 375 MB. This is largely used as a /home overflow via symlinks.
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 152247 33526 110859 24% /
/dev/hda6 249871 2004 234967 1% /tmp
/dev/sda7 585008 457456 97836 83% /var
/dev/hda5 495960 87588 382772 19% /var/spool/news
/dev/sdb2 1929100 1518288 312816 83% /usr
/dev/sda5 1209572 574152 573976 51% /usr/local
/dev/hda7 378711 213496 145662 60% /usr/local/data
/dev/hda2 1007992 584132 372656 62% /home
/dev/hda1 157044 119252 37792 76% /mnt/dos
Disk /dev/hda: 128 heads, 63 sectors, 620 cylinders
Units = cylinders of 8064 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 39 157216+ 6 FAT16
/dev/hda2 40 293 1024128 83 Linux
/dev/hda3 * 294 332 157248 83 Linux
/dev/hda4 333 620 1161216 5 Extended
/dev/hda5 333 459 512032+ 83 Linux
/dev/hda6 460 523 258016+ 83 Linux
/dev/hda7 524 620 391072+ 83 Linux
Disk /dev/sda: 255 heads, 63 sectors, 261 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Bl.ocks Id System
/dev/sda1 1 17 136521 82 Linux swap
/dev/sda2 18 261 1959930 5 Extended
/dev/sda5 18 170 1228941 83 Linux
/dev/sda6 171 187 136521 82 Linux swap
/dev/sda7 188 261 594373+ 83 Linux
Disk /dev/sdb: 255 heads, 63 sectors, 261 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 17 136521 82 Linux swap
/dev/sdb2 18 261 1959930 83 Linux
# /etc/fstab: static file system information.
#
#
/dev/hda3 / ext2 defaults,errors=remount-ro 0 1
proc /proc proc defaults 0 0
/dev/hda6 /tmp ext2 defaults,nosuid,nodev 0 2
/dev/sda7 /var ext2 defaults,nosuid,nodev 0 2
/dev/hda5 /var/spool/news ext2 defaults,nosuid,noexec,nodev 0 2
/dev/sdb2 /usr ext2 defaults,rw,nodev 0 2
/dev/sda5 /usr/local ext2 defaults,rw,nosuid,nodev 0 2
/dev/hda7 /usr/local/data ext2 defaults,nosuid,nodev 2 2
/dev/hda2 /home ext2 defaults,nosuid,nodev 0 2
/dev/hdc /mnt/cdrom iso9660 noauto,user,ro,nodev,nosuid 2 2
/dev/fd0 /mnt/floppy auto noauto,gid=disk,umask=007,rw,user 2 2
/dev/hda1 /mnt/dos vfat auto,user,nosuid,nodev,gid=6,umask=002 2 2
/dev/sda1 none swap sw 0 0
/dev/sdb1 none swap sw 0 0
/dev/sda6 none swap sw 0 0
The only significant consideration here was that I'm running Reiserfs on most partitions. There are some issues reading a Reiserfs partition on boot from LILO, so I have one ext2fs partition, mounted read-only, as /boot. Otherwise, this largely approaches the ideal "large filesystem" partition schema mentioned above, allocating necessary space to system partitions, giving a generous allowance to /usr/local, and the balance to /home.
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 72280 55096 17184 77% /
/dev/hda1 23302 2136 19963 10% /boot
/dev/hda5 248948 32856 216092 14% /tmp
/dev/hda6 995932 836476 159456 84% /var
/dev/hda7 2995968 1190632 1805336 40% /usr
/dev/hda8 2995968 287944 2708024 10% /usr/local
/dev/hda10 11702932 2619504 9083428 23% /home
Disk /dev/hda: 255 heads, 63 sectors, 2432 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start . End Blocks Id System
/dev/hda1 * 1 3 24066 83 GNU/Linux
/dev/hda2 13 2432 19438650 5 Extended
/dev/hda3 4 12 72292+ 83 GNU/Linux
/dev/hda5 13 43 248976 83 GNU/Linux
/dev/hda6 44 167 995998+ 83 GNU/Linux
/dev/hda7 168 540 2996091 83 GNU/Linux
/dev/hda8 541 913 2996091 83 GNU/Linux
/dev/hda9 914 975 497983+ 82 GNU/Linux swap
/dev/hda10 976 2432 11703321 83 GNU/Linux
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/hda3 / reiserfs defaults 0 0
/dev/hda1 /boot ext2 ro,nosuid,nodev 0 2
/dev/hda9 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/hda5 /tmp reiserfs rw,nosuid,nodev 0 2
/dev/hda6 /var reiserfs rw,nosuid,nodev 0 2
/dev/hda7 /usr reiserfs rw,nodev 0 2
/dev/hda8 /usr/local reiserfs rw,nosuid,nodev 0 2
/dev/hda10 /home reiserfs rw,nosuid,nodev 0 2
/dev/fd0 /mnt/floppy auto defaults,user,noauto 0 0
/dev/cdrom /mnt/cdrom iso9660 defaults,ro,user,noauto 0 0
Red Hat provides a set of partitioning recommendations similar in spirit with these guidelines.
There's also a Linux Partitioning HOWTO at TLDP.
RH 7.3: 128 MiB insufficient for root fs?
I am told that 128 MiB is not sufficient for a RH 7.3 root partition as RPM updates fail to run. Why this is (e.g.: what temporary files are being created) is not clear or specified. Information from others would be helpful.
-- KarstenSelf - 05 Aug 2002
RickMoen posted a nice discussion of his thoughts on partitioning in zIWeThey post #116670 - http://z.iwethey.org/forums/render/content/show?contentid=116670
Drew wrote:
Edit /etc/fstab ...
... configure it appropriately ...
1) Edit it how?
2) Define "appropriately".
That's kind of a Religious Question™ Epic jihads have been lauched over the matter of system partitioning. Here's my wacky, somewhat over-complex entry into the sweepstakes, from my main server:
uncle-enzo:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# filesys mountpoint type options dump pass
/dev/sda5 / ext3 defaults,errors=remount-ro 1 1
/dev/sda7 none swap sw 0 0
/dev/sdb6 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /mnt/floppy auto defaults,user,noauto 0 0
/dev/sda1 /boot ext2 ro,noauto,noexec,nosuid,nodev 1 2
/dev/sda6 /mnt/recovery ext2 rw,noauto 0 2
/dev/sdb7 /var ext3 rw,nodev,nosuid,noatime 1 2
/dev/sda8 /var/log ext3 rw,nodev,nosuid,noatime 0 2
/dev/sdb8 /usr ext2 ro,nodev 1 2
/dev/sda9 /usr/local ext3 rw 1 2
/dev/sdb1 /home ext3 rw,nodev,nosuid 1 2
/dev/sdb5 /tmp ext3 rw,nosuid,nodev,noatime 0 2
uncle-enzo:~# df -H
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 985M 166M 769M 18% /
/dev/sdb7 2.0G 1.2G 745M 61% /var
/dev/sda8 985M 139M 797M 15% /var/log
/dev/sdb8 3.0G 848M 2.0G 31% /usr
/dev/sda9 5.0G 2.2G 2.6G 46% /usr/local
/dev/sdb1 985M 781M 154M 84% /home
/dev/sdb5 291M 9.2M 267M 4% /tmp
/dev/sda1 97M 10M 82M 11% /boot
uncle-enzo:~#
Since the machine has two physical disks (sda and sdb), I've put some swap space on each of them, and split pieces of the system filesystem between them, hoping to split head-seeking activity between them, to maximise mass-storage performance. Parts of the tree at risk for explosive file growth (/home, /var, /tmp) are carefully kept off the root filesystem to protect the latter. The separate /boot partition is a bit of an archaism, and I probably won't do that with future system builds.
The "noatime" flag is a performance aid on parts of the tree where I figure the atime date stamp isn't really needed or useful. The other "no*" flags are perhaps feeble measures at greater system security. (Don't try "noexec" on /tmp; packages often try to run preinst or postinst scripts in there!) Note that /boot and /usr are the only non-journaled filesystems: Being mounted read-only, there's no point in journaling overhead.
The read-only flag ("ro") on the /usr filesystem helps prevent accidental system catastrophe at the sysadmin's hands or equivalent, but you'll want some mechanisms to remount it read/write for package installation/removal, such as the shell scripts I call from /etc/apt/apt.conf:
DPkg {
// Auto re-mounting of a readonly /usr
Pre-Install-Pkgs {"/home/rick/aptdpkgro.sh";};
Pre-Invoke {"mount -o remount,rw /usr";};
Post-Invoke {"/home/rick/aptdpkgclean.sh; mount -o remount,ro /usr";};
}
uncle-enzo:/etc/apt# cd /home/rick
uncle-enzo:/home/rick# cat aptdpkgro.sh
#!/bin/sh
pathmatch="^/usr"
while read debname; do
pkg=$(dpkg --info $debname | sed -n 's/^ Package: *//p' | head -1)
(dpkg -L "$pkg" 2>/dev/null || true) | grep "$pathmatch" |
while read file; do
[ -f "$file" -a ! -L "$file" ] || continue
dir=`dirname "$file"`;
base=`basename "$file"`;
inode=`find "$file" -printf "%i\n"`
(cd "$dir" && ln "$base" ".${base}.dpkg-ro-used.$inode")
echo "$dir/.${base}.dpkg-ro-used.$inode"
done >>/var/lib/my_ro_hack.todel
done
uncle-enzo:/home/rick# cat aptdpkgclean.sh
#!/bin/sh
pathmatch="^/usr"
cat /var/lib/my_ro_hack.todel | while read file; do
[ -f "$file" ] || continue
N1=`find "$file" -printf "%i\n"`
b=`basename $file`; d=`dirname $file`
XF="${b#.}"; XF="$d/${XF%.dpkg-ro-used.*}"
N2=`find "$XF" -printf "%i\n"`
if [ "$N1" != "$N2" ] && ! fuser -s "$file"; then
rm -f "$file"
else
echo "$file"
fi
done >/var/lib/my_ro_hack.todel.new
mv /var/lib/my_ro_hack.todel.new /var/lib/my_ro_hack.todel
uncle-enzo:/home/rick#
Anyhow, the first thing you have to decide is which parts of your system tree will need their own partitions, and how big each will be. Then, decide which will be journaled using your journaling religion of choice (ext3, XFS, ReiserFS?, JFS).
- Boot the Knoppix disk.
- Open a terminal and run "sudo bash" to get a root shell.
- Type "mount" to see what Knoppix might have automounted at boot time;
umount anything it mounted from the target hard drive.
- Fire up
/sbin/fdisk or /sbin/cfdisk (your choice) to create desired partitions.
- Keep notes on paper of what you're doing and which partition is which.
- When you're done, save and exit, then use mkfs.ext3, mkreiserfs, mkfs.xfs, mkfs.ext2, or whatever is approriate to high-level format the various partitions.
- Don't forget to
mkswap for the swap partition(s).
- When you're done with that,
mount the target root filesystem onto /mnt (or wherever you prefer), then mount the various other target filesystems to their respective mountpoints underneath /mnt.
- Now, you're ready to copy files from some other machine across the network. (Examples of how to do so using various tools such as
tar, rsync, etc. are given in http://linuxmafia.com/faq/VALinux-kb/copying-directory-trees.html .)
- Last, don't forget to construct an appropriate
/etc/fstab (which at that moment will be /mnt/etc/fstab) using a text editor, to reflect the new filesystems you've created.
The table of filesystems I posted above is probably way, way overcomplex for most people's needs, but I've posted it because it illustrates some partitioning concepts. The one from my laptop is a bit more modest:
rick@guido:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# file system mount point type options dump pass
/dev/hda3 / ext3 defaults,errors=remount-ro 0 1
/dev/hda2 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /floppy auto defaults,user,noauto 0 0
/dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0
none /proc/bus/usb usbdevfs defaults 0 0
/dev/sda /mnt/fob vfat rw,uid=1000,gid=1000,user,noauto,noatime 0 0
/dev/hda1 /boot ext2 rw,noauto 0 2
When in doubt, go with something simple (maybe something really simple, more than the laptop example above). When you need something more complex, you'll know it, and can reconfigure your system at that time.
Rick Moen
rick@linuxmafia.com
-- AnotherScott - 06 Sep 2003
Hrm...
Examples of partitioning are good.
What exactly is in Rick's material that wasn't already covered here? Not that there might not be something, or that Rick doesn't state more clearly than I bits.
Part of this is that the post is answering more the question of "how do I clone an existing Debian system" than "how do I partition a GNU/Linux box", though it's not a clean cut.
-- KarstenSelf - 06 Sep 2003
Thanks for cleaning up the post.
I agree that RickMoen's post might better fit under a new section, or as a branch of this section. I don't know enough of the TWiki style and so forth to feel comfortable starting a new section, and didn't want to hack away at your excellent page to try to branch a new section.
The beauty of this TWiki stuff is that it's iterative. I would be happy if you (or RickMoen) or someone else could modify the information he provided to fit in better with your existing (and excellent) discussion. I thought Rick's post was quite valuable for its detail and for its discussion of why he did things the way he did (e.g. the noatime flag) and figured it would help more people as part of the TWiki than as a post in zIWeThey.
Perhaps Rick's post would be better in a section on migrating Linux to another machine, but his partitioning discussion was informative (as was yours).
No offense intended. I figured that I would merely start the ball rolling and I hoped that it wouldn't cause too much work for someone who wanted to edit it.
Thanks.
-- AnotherScott - 07 Sep 2003
TWiki is iterative. It can also be agglomerative, but what makes it most useful is that it allows for refactoring -- taking new contributions and sifting and filter them into the existing content, modifying, replacing, or deleting, as needed. Without this last, the content becomes unmanageably vague (see the current SCO topic, which I've been trying to refactor for, oh, a couple of months now).
The problems that TWiki addresses from other media are:
- Newsgroups, mailing lists, and typical web logs (such as zIWT or blogs) which are largely strictly agglomorative, and consequently highly repetitive. The same questions are asked, again and again, and answered, frequently with a shading of inaccuracy or inappropriateness, for which the only remedy is further agglomeration. The collective truth can only be gleaned by reading reams and reams of content.
- Highly structured docs, which can be highly refactored, but which suffer from a single editor. These all share two traits: they're chronically out of date, and they never specifically address the situation you're facing.
So again: I don't mind this dump from Rick's mind (I encourage it strongly). What I'm trying to figure out is: what question is this contribution answering.
The question answered by the topic initially was "how should I partition my GNU/Linux / 'Nix box, and what considerations should I make?". I'm looking for an integrity of topic here.
So, to the specific case: I see a lot of material that slightly modifies suggestions I've made. I see some additional examples of partitioning. I see a section on "how do I migrate/clone an existing Debian installation". Two of these fit within the existing structure. The third should be a new topic.
Clear?
-- KarstenSelf - 07 Sep 2003
-- KarstenSelf - 04 Aug 2002
|
|
Copyright © 2001-2006 by the contributing authors.
All material on TWikIWeThey is the property of the contributing authors. This content may be freely distributed, copied, or modified, with attribution, and this notice.
Works are provided AS IS with NO WARRANTY and NO LIABILITY for consequences of use.
Ideas, requests, problems regarding TWikIWeThey? Send feedback.
|
You have had a long-term stimulation relative to business.
pcmcia