From c732abcf45261385451e8916a4609a86fd09857b Mon Sep 17 00:00:00 2001
From: Eric Andersen <andersen@codepoet.org>
Date: Thu, 11 Dec 2003 07:41:48 +0000
Subject: more minor cleanups

---
 docs/uclibc.org/FAQ.html   | 15 +++++++++++++++
 docs/uclibc.org/index.html |  6 ------
 2 files changed, 15 insertions(+), 6 deletions(-)

(limited to 'docs')

diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html
index 70dd14366..f49f33082 100644
--- a/docs/uclibc.org/FAQ.html
+++ b/docs/uclibc.org/FAQ.html
@@ -251,6 +251,21 @@ How could it be smaller and not suck?</a></h2>
     and use resize2fs to make them fill a partition...  Whatever works best for
     you.
 
+    <p>
+    The quickest way to get started using a root_fs image (using the i386
+    platform as an example) is:
+    <ul>
+    <li>Download root_fs_i386.bz2 from kernel.org</li>
+    <li>bunzip2 root_fs_i386.bz2</li>
+    <li>mkdir root_fs</li>
+    <li>su root</li>
+    <li>mount -o loop root_fs_i386 root_fs</li>
+    <li>chroot root_fs /bin/sh</li>
+    </ul>
+    Type "exit" to end the chroot session and return to the host system.
+    <p>
+
+
 
 <hr />
 <p>
diff --git a/docs/uclibc.org/index.html b/docs/uclibc.org/index.html
index 45d9479ad..a046564ef 100644
--- a/docs/uclibc.org/index.html
+++ b/docs/uclibc.org/index.html
@@ -25,12 +25,6 @@ of storage, then using glibc may make more sense.  Unless, for
 example, that 12 Terabytes will be Network Attached Storage and
 you plan to burn Linux into the system's firmware...
 
-<p>
-
-uClibc is maintained by 
-<a href="http://www.codepoet.org/andersen/erik/erik.html">Erik Andersen</a>
-
-
 <p>
 
 uClibc is maintained by <a href=
-- 
cgit v1.2.3