[lfs-support] Brand new and confused. Mostly about the 7.5 book.
zarniwhoop at ntlworld.com
Sun Mar 30 15:44:19 PDT 2014
On Sun, Mar 30, 2014 at 11:31:59PM +0200, Aleksandar Kuktin wrote:
> >On Sun, 30 Mar 2014 14:05:50 -0700
> >Al Szymanski <aszy at mac.com> wrote:
> > I am just trying to figure out the overall smallest size of hard
> > drive space needed for all of the partitions. My sums from the 7.5
> > book come to 80 Gig plus whatever space I want for /home .
> > [ suggested partition sizes:
> > root LFS 10Gig
> > /usr/src 30-50Gig
> > /opt 5-10Gig
> > /usr 5Gig
> > /tmp <5Gig
> > swap 2xRAM
> > /boot 100Meg
> > =~81Gig ]
> Are these numbers your own estimates, or did you pick them up
> somewhere? I'm asking because they overestimate. In particular, the line
> for /usr/src seems way too big. My own tarball dir (which cotains
> everything I build) is 2.7 GB, almost ten times smaller that your low
I think we are all following Al in asking the wrong question ;-)
Surely, the first question ought to be "What partitions will suit
_my_ usage ?".
In my own builds, /sources is an nfs mount (and it contains in
excess of 20GB : I pruned it last week, but it has source for most
of the packages in BLFS, so that I could test them for 7.5. My own
builds are motly on desktops, and in general I have the following as
separate filesystems : /, /boot, /home and swap. I _only_ use LFS,
so I need at least two partitions which can be used for '/', and I
also allocate my remaining space [ modern disks are stupidly big for
desktop users ] to /scratch which does _not_ get backed up.
Also, if you have the space in /home, you can keep the sources
Re the other places mentioned :
/usr/src : why do anything here ? In BLFS you are recommended to
_not_ build as root (although I do in my scripts) and by default
/usr/src is only writable by root. Similarly, anyone who says that
the kernel tree belongs in /usr/src/linux is living in the distant
past - that idea was obsolete even when I first used linux at the
turn of the millenium. Building newer kernels in ~/ is good.
/opt : Sometimes it is useful to keep this separate, but unless you
intend to put TeX or KDE in /opt I would NOT make it separate. Even
if you do intend to use those space-hogs, a bigger '/' [ ideally
with room for TWO versions of /opt ] will make building a newer
version on the current system _much_ easier. If you do separate
/opt, please remember that its programs and libraries will link to
libs in '/lib' and '/usr/lib', so sharing /opt between multiple
systems on the same machine is not usually possible.
Perhaps I should stress that the recommended upgrade path for LFS
is to build a new system. So, if you have /opt as a separate
filesystem for the first LFS you will need a simialr amount of space
for the replacement system.
IMHO, far better to make '/' big, with /opt and /usr part of the
root filesystem. But whatever you do, if you keep building LFS or
similar systems you will eventually find that your partitioning no
longer meets your requirements. A rescue CD is essential [ please
let me mention systemrescuecd, even though it uses zsh and is
therefore not always plain-sailing when entering chroot ].
/usr : A separate /usr is a very old idea. Useful if you are on a
network where /usr is an nfs mount shared by several machines. I'm
sure there are other use cases, but I can't think of any at the
moment. For most of us, giving /usr on its own filesystem makes no
/tmp : This is separate ?
ken at ac4tv ~ $mountpoint /tmp
/tmp is not a mountpoint
At one time we used to mount a tmpfs on /tmp, but somewhere along
the way (perhaps between 6.8 and 7.0) we stopped doing that, which
from my POV was a shame. But I cannot see any good reason to give
/tmp its own filesystem.
swap : yes. The traditional theory was 2 x physical memory, but I
might go with more than that if physical memory is small (e.g. <=
4GB). On what is now a small disk I would not go overboard with the
/boot : yes, it makes things easier when you upgrade your LFS
syustem by building a fresh system. For me, at the moment I have <3
MB in /boot/grub, and <5 MB per kernel - and I've got a lot of
those, but they are generally slimmed-down to match my hardware.
Sticking a finger i nthe air, 100MB lookss adequate.
For *servers*, some other directories might benefit from having
their own filesystem, it all depends on what you are doing. I've
seen a use-case for separating /var/log, and I myself separate
/var/tmp on my server - I also have other non-standard filesystems
there. That is all a question of what fits best with what you
intend to do.
I used to use 6GB partitions for '/' with /sources separate (nfs),
but my desktop builds increased to cover more of what is in BLFS. I
now use 8GB, but that is not enough for all of the desktop
alternatives, and doesn't give enough space for TeX even on my
normal desktop [ I put TeX in my /sccratch partition, and bind it if
I need to use it, but for a "full-ish" desktop including more than
one DE [ 64-bit ] I guess I would be looking at 12GB for '/' if I
wanted to include TeX. On my server (apache to provide local
copies of the LFS/BLFS books, a postgres database, and separate
filesystems for my backups and for my media files) I am currently
using just over 2.5GB in the rootfs.
das eine Mal als Tragödie, dieses Mal als Farce
More information about the lfs-support