[lfs-support] Brand new and confused. Mostly about the 7.5 book.

Ken Moffat 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
> estimate.

 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 mailing list