Bruce Dubbs wrote:
> Alexander E. Patrakov wrote:
>> Hello,
>>
>> Some newbies get caught by our advertisement (which might be true for older 
>> versions of LFS, but is untested as of LFS-6.3):
>>
>>> It is not difficult to build an LFS system of less than 100 megabytes (MB),
>>> which is substantially smaller than the majority of existing installations.
>>> Does this still sound like a lot of space? A few of us have been working on
>>> creating a very small embedded LFS system. We successfully built a system
>>> that was specialized to run the Apache web server with approximately 8MB of
>>> disk space used. Further stripping could bring this down to 5 MB or less. 
>>> Try
>>> that with a regular distribution! This is only one of the many benefits of
>>> designing your own Linux implementation.
> 
> The above is still true, but perhaps there should be a modification:
> 
> "It is not difficult to modify a standard LFS system to use less than 100 
> megabytes (MB)..."

Yes, this is acceptable.

> I can't find anywhere where the book refers to a slow 586-class system.

It doesn't do so explicitly, but by showing how slim the final system can be, 
it 
implicitly suggests that it won't consume a lot of resources and is thus a 
suitable choice for old hardware.

> The SBU section already says that "Glibc .. could take up to three days on 
> slower 
> systems!"

Sorry, I missed it. But see the proposed alternative/additional wording below. 
The point that "there is a better way than to wait three days" is currently not 
addressed.

>> P.S. I accept the challenge to "try that with a regular distribution".
> 
> I am waiting for your results.  Can you do it without breaking updates via 
> their 
> package manager?

I started with Debian Etch, choosing "No localization" (i.e., "C" locale).

Fresh network-based installation with all options in tasksel (even "standard 
system" deselected): 268 MB (according to "df", which also reports 
filesystem-related overhead).

After running "apt-get clean" to remove downloaded *.deb files: 209 MB

Then I removed the following "obvious" packages:

acpid, dselect, tasksel, tasksel-data, info, man-db, manpages, ed, vim-common, 
vim-tiny (nano is the remaining editor), libc6-i686, installation-report, 
iptables, netcat, traceroute, libsasl2, groff-base, acpi, bsdmainutils, 
console-common, console-data, console-tools, libconsole, dmidecode, 
laptop-detect, usbutils, libgdbm3: the remaining system occupies 196 MB, out of 
that /var is 51 MB, /lib/modules is  43 MB, and /usr/share is 40 MB.

The next step is to install "debconf-english" instead of "debconf-i18n" and 
remove the following packages that are no longer needed: 
liblocale-gettext-perl, 
libtext-charwidth-perl, libtext-iconv-perl, libtext-wrapi18n-perl, so that the 
result is 195 MB.

Then, for a web server, install lighttpd "without recommends". This will pull 
in 
  lighttpd, mime-support and libpcre3. Thus, a Debian-based system with a 
static 
web server and with no manually-removed files takes 196 MB.

One can comment out all lines in /etc/apt/sources.list and run "aptitude 
update". This will remove long package lists from /var, bringing it down to 18 
MB (out of that, /var/log occupies 9.4 MB, and the total size of the system is 
162 MB).

Then one can remove unneeded modules. I allowed only ne2k-pci, 8390, piix, 
ide-disk, ide-core, jbd, ext3 and mbcache modules (required by qemu virtual 
hardware) to stay (and to propagate to initramfs, by running "update-initramfs 
-u -k all").

Then, translated message catalogs (/usr/share/locale), character set conversion 
modules (/usr/lib/gconv) and optimized libraries ({/usr,}/lib/i?86*) go away. 
Then, configuration data from stale packages:

dpkg -l | grep ^rc | awk '{ print $2 }' | xargs dpkg --purge

So, the system is down to 76 MB according to "df" (including 18 MB of data in 
/var), still boots, serves static HTML files, logs everything, rotates logs, 
and 
can be fully restored from a Debian mirror. It is interesting that the ext3 
overhead is significant: according to "du -shx /", the system takes 65 MB.

Further reduction requires sacrificing the ability to restore from a Debian 
mirror (i.e., to remove apt and related packages). This doesn't remove the 
ability to install packages "by hand" with dpkg, so counts only as "breaking 
repository support", not as "completely breaking a package manager". However, 
due to dependency of lighttpd (in particular, mod_auth.so) on libldap2, this 
doesn't help. Well, further manual reduction is possible, but breaks 
dependencies (e.g., one can manually remove libldap2 dependencies as long as 
mod_auth is not used, and lighttpd will work, but dpkg will complain). So I 
didn't try doing this, and thus let's settle at 65 - 18 = 47 MB for data 
outside 
of /var without breaking updates via the package manager.

So, the only remaining option to reduce the size further is to construct a 
chroot and copy only the needed files there, and to rewrite the initscripts. I 
removed and reinstalled this Debian system, this time selecting xfs instead of 
ext3 as a file system (goal: completely remove the need for the "fsck" 
program). 
Here is the list of files that make a minimal static HTTP server that also logs 
access to syslog and rotates logs:

./bin/busybox
./bin/login
./bin/sh (link to busybox)
./etc/crontab
./etc/environment
./etc/fstab
./etc/group
./etc/group-
./etc/gshadow
./etc/gshadow-
./etc/host.conf
./etc/hostname
./etc/hosts
./etc/inittab
./etc/ld.so.conf
./etc/lighttpd/lighttpd.conf
./etc/lighttpd/mime.assign
./etc/localtime
./etc/login.defs
./etc/logrotate.conf
./etc/modules
./etc/nsswitch.conf
./etc/pam.conf
./etc/pam.d/common-account
./etc/pam.d/common-auth
./etc/pam.d/common-password
./etc/pam.d/common-session
./etc/pam.d/cron
./etc/pam.d/login
./etc/pam.d/other
./etc/pam.d/su
./etc/passwd
./etc/passwd-
./etc/profile
./etc/protocols
./etc/rc (written manually)
./etc/resolv.conf
./etc/security/pam_env.conf
./etc/services
./etc/shadow
./etc/shadow-
./etc/shells
./etc/timezone
./init (link to /sbin/init)
./lib/ld-2.3.6.so
./lib/libattr.so.1.1.0
./lib/libc-2.3.6.so
./lib/libcrypt-2.3.6.so
./lib/libdl-2.3.6.so
./lib/libm-2.3.6.so
./lib/libnsl-2.3.6.so
./lib/libnss_dns-2.3.6.so
./lib/libnss_files-2.3.6.so
./lib/libpam_misc.so.0.79
./lib/libpam.so.0.79
./lib/libpopt.so.0.0.0
./lib/libproc-3.2.7.so
./lib/libselinux.so.1
./lib/libsepol.so.1
./lib/libutil-2.3.6.so
./lib/<links to these libraries>
./lib/modules/2.6.18-6-686/kernel/drivers/ide/ide-core.ko
./lib/modules/2.6.18-6-686/kernel/drivers/ide/ide-disk.ko
./lib/modules/2.6.18-6-686/kernel/drivers/ide/pci/piix.ko
./lib/modules/2.6.18-6-686/kernel/drivers/net/8390.ko
./lib/modules/2.6.18-6-686/kernel/drivers/net/ne2k-pci.ko
./lib/modules/2.6.18-6-686/kernel/fs/xfs/xfs.ko
./lib/modules/2.6.18-6-686/modules.alias
./lib/modules/2.6.18-6-686/modules.ccwmap
./lib/modules/2.6.18-6-686/modules.dep
./lib/modules/2.6.18-6-686/modules.ieee1394map
./lib/modules/2.6.18-6-686/modules.inputmap
./lib/modules/2.6.18-6-686/modules.isapnpmap
./lib/modules/2.6.18-6-686/modules.ofmap
./lib/modules/2.6.18-6-686/modules.pcimap
./lib/modules/2.6.18-6-686/modules.seriomap
./lib/modules/2.6.18-6-686/modules.symbols
./lib/modules/2.6.18-6-686/modules.usbmap
./lib/security/pam_env.so
./lib/security/pam_lastlog.so
./lib/security/pam_motd.so
./lib/security/pam_rootok.so
./lib/security/pam_securetty.so
./lib/security/pam_unix.so
./sbin/getty
./sbin/halt
./sbin/hwclock
./sbin/init
./sbin/killall5
./sbin/modprobe
./sbin/shutdown
./sbin/sysctl
./usr/lib/libcrypto.so.0.9.8
./usr/lib/libpcre.so.3.12.0
./usr/lib/libssl.so.0.9.8
./usr/lib/libz.so.1.2.3
./usr/lib/lighttpd/mod_accesslog.so
./usr/lib/lighttpd/mod_access.so
./usr/lib/lighttpd/mod_alias.so
./usr/lib/lighttpd/mod_dirlisting.so
./usr/lib/lighttpd/mod_indexfile.so
./usr/lib/lighttpd/mod_staticfile.so
./usr/sbin/cron
./usr/sbin/lighttpd
./usr/sbin/logrotate

That's 5.6 MB, without any debian-specific tricks (plus the kernel, which is 
1.2 
MB). This collection of files is available as an initramfs image, i.e., is 
meant 
to be run from RAM (compressed size: 2.4 MB):

http://kerrek.linuxfromscratch.org/~alexander/initrd.img-light

The root password is "lfs". It needs this kernel image:

http://kerrek.linuxfromscratch.org/~alexander/vmlinuz-2.6.18-6-686

It will run in qemu, using the XFS filesystem on /dev/hda2 as the /var 
partition, and serving documents from /var/www. It also needs /var/log/lighttpd 
with owner www-data and group www-data (uid = gid = 33), and will log to 
/var/log/messages.

Since the total size of the kernel and the compressed initramfs image is 3.6 
MB, 
I think that the result meets the "try to do this with a regular distribution" 
challenge. Yes, there is some overhead due to PAM and selinux libraries 
(probably can be worked around by starting from Slackware), but by copying 
files 
from a binary distro instead of building LFS I saved some time.

Note that there is a Debian-specific way to reduce the size further (by 
removing 
unneeded symbols from glibc), but in this case it strips only 300 KB 
uncompressed (because busybox is a heavy user of symbols) and thus isn't worth 
the trouble.

>> Proposal:
>>
>> 1) Remove this advertisement.
> 
> Disagree.  It is still valid, but could use some tweaks.

Settled, let's tweak it.

>> 2) List hardware requirements (CPU, RAM, hard disk space) on the same page 
>> as 
>> software host requirements, or immediately before it. These requirements 
>> should 
>> be set so that the total build time (including all testsuites) is less than 
>> 8 
>> hours, and that the build process never needs to get into swap (the worst 
>> case 
>> seems to be Chapter 5 gcc Pass1 when starting from a host that is based on 
>> gcc-3.3).
> 
> Disagree.  The SBU page already can give a user an idea about how long it 
> takes 
> for various combinations of hardware.  A user can judge for himself from 
> there.
> Again, the SBU page could use some updates.

Correct, my original proposal would lead to duplicating the information. I 
retract this part of my proposal because it is better addressed by updating 
(and 
possibly retitling) the SBU page and moving it near the Host requirements page. 
However, something like this should definitely be said: "While LFS will run on 
weak 586-class computers, it is recommended not to attempt to build it there. A 
better approach (currently undocumented) is to build LFS on your fastest 
computer, and then transfer it to the target in the binary form."

>> 3) When package management enters the book, include a procedure for building 
>> packages for a lower CPU (basically, import config.site from the LiveCD and 
>> adjust toolchain and perl configure arguments as done there) and 
>> transferring 
>> LFS and subsequent packages to a different machine.
> 
> Disagree.  This is something for a hint or something similar to the user 
> notes 
> on BLFS.  Trying to address every corner case in the book would be 
> distracting 
> to the majority of users.

I disagree that this is a corner case. It came up several times on the livecd 
list, so this has to be addressed somehow (possibly even by explicitly 
recommending to use a binary distro).

-- 
Alexander E. Patrakov
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to