[gentoo-doc-cvs] cvs commit: handbook-mips.xml

[Josh Saddler]

nightmorph    06/02/12 13:54:32

  Added:       xml/htdocs/doc/en/handbook/draft/2006.0 handbook-mips.xml
                        hb-install-mips-bootloader.xml
                        hb-install-mips-disk.xml hb-install-mips-kernel.xml
                        hb-install-mips-medium.xml
                        hb-install-mips-stage.xml
  Log:
  Initial import of *unmodified* docs into handbook/draft/2006.0 for bug
  111652. Patching will begin shortly. One completely new doc,
  hb-install-mips-stage.xml, is now present.

Revision  Changes    Path
1.1                  xml/htdocs/doc/en/handbook/draft/2006.0/handbook-mips.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/handbook-mips.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/handbook-mips.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: handbook-mips.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE book SYSTEM "/dtd/book.dtd">

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/2006.0/handbook-mips.xml,v 1.1 2006/02/12 13:54:32 nightmorph Exp $ -->

<book link="handbook-mips.xml">
<title>Gentoo Linux/MIPS Handbook</title>

<author title="Author">
  <mail link="swift@g.o">Sven Vermeulen</mail>
</author>
<author title="Author">
  <mail link="uberlord@g.o">Roy Marples</mail>
</author>
<author title="Author">
    <mail link="drobbins@g.o">Daniel Robbins</mail>
</author>
<author title="Author">
  <mail link="chouser@g.o">Chris Houser</mail>
</author>
<author title="Author">
  <mail link="jerry@g.o">Jerry Alexandratos</mail>
</author>
<author title="Gentoo x86 Developer">
  <mail link="seemant@g.o">Seemant Kulleen</mail>
</author>
<author title="Gentoo Alpha Developer">
  <mail link="taviso@g.o">Tavis Ormandy</mail>
</author><!-- Does not want to be listed on the rendered page
<author title="Gentoo Developer">
  Aron Griffis
</author>
-->
<author title="Gentoo AMD64 Developer">
  <mail link="jhuebel@g.o">Jason Huebel</mail>
</author>
<author title="Gentoo HPPA developer">
  <mail link="gmsoft@g.o">Guy Martin</mail>
</author>
<author title="Gentoo PPC developer">
   <mail link="pvdabeel@g.o">Pieter Van den Abeele</mail>
</author>
<author title="Gentoo SPARC developer">
  <mail link="blademan@g.o">Joe Kallar</mail>
</author>
<author title="Editor">
    <mail link="zhen@g.o">John P. Davis</mail>
</author>
<author title="Editor">Pierre-Henri Jondot</author>
<author title="Editor">
    <mail link="stocke2@g.o">Eric Stockbridge</mail>
</author>
<author title="Editor">
    <mail link="rajiv@g.o">Rajiv Manglani</mail>
</author>
<author title="Editor">
    <mail link="seo@g.o">Jungmin Seo</mail>
</author>
<author title="Editor">
    <mail link="zhware@g.o">Stoyan Zhekov</mail>
</author>
<author title="Editor">
    <mail link="jhhudso@g.o">Jared Hudson</mail>
</author>
<author title="Editor">
    <mail link="peitolm@g.o">Colin Morey</mail>
</author>
<author title="Editor">
    <mail link="peesh@g.o">Jorge Paulo</mail>
</author>
<author title="Editor">
    <mail link="carl@g.o">Carl Anderson</mail>
</author>
<author title="Editor">
    <mail link="avenj@g.o">Jon Portnoy</mail>
</author>
<author title="Editor">
     <mail link="klasikahl@g.o">Zack Gilburd</mail>
</author>
<author title="Editor">
  <mail link="jmorgan@g.o">Jack Morgan</mail>
</author>
<author title="Editor">
  <mail link="bennyc@g.o">Benny Chuang</mail>
</author>
<author title="Editor">
  <mail link="erwin@g.o">Erwin</mail>
</author>
<author title="Editor">
  <mail link="kumba@g.o">Joshua Kinard</mail>
</author>
<author title="Editor">
  <mail link="stuartl@××××××××××××××××××.org">Stuart Longland</mail>
</author>
<author title="Editor">
  <mail link="dertobi123@g.o">Tobias Scherbaum</mail>
</author>
<author title="Editor">
  <mail link="neysx@g.o">Xavier Neys</mail>
</author>
<author title="Reviewer">
    <mail link="g2boojum@g.o">Grant Goodyear</mail>
</author>
<author title="Reviewer">
    <mail link="gerrynjr@g.o">Gerald J. Normandin Jr.</mail>
</author>
<author title="Reviewer">
    <mail link="spyderous@g.o">Donnie Berkholz</mail>
</author>
<author title="Reviewer">
    <mail link="antifa@g.o">Ken Nowack</mail>
</author>
<author title="Contributor">
   <mail link="pylon@g.o">Lars Weiler</mail>
</author>

<abstract>
This is the Gentoo Handbook, an effort to centralize Gentoo/Linux information.
This handbook contains the installation instructions for an Internet-based
installation on MIPS systems and parts about working with Gentoo and Portage.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>4.3</version>
<date>2005-12-19</date>

<part>
<title>Installing Gentoo</title>
<abstract>
In this part you learn how to install Gentoo on your system.
</abstract>

<chapter>
<title>About the Gentoo Linux Installation</title>
<abstract>
This chapter introduces you to the installation approach documented in this
part.
</abstract>
  <include href="hb-install-about.xml"/>
</chapter>

<chapter>
<title>Choosing the Right Installation Medium</title>
<abstract>
You can install Gentoo in many ways. In this chapter we explain how to install
Gentoo using the MIPS Netboot images.
</abstract>
  <include href="hb-install-mips-medium.xml"/>
</chapter>

<chapter>
<title>Configuring your Network</title>
<abstract>
To be able to download the latest source code, you will need to setup
networking.
</abstract>
  <include href="hb-install-network.xml"/>
</chapter>

<chapter>
<title>Preparing the Disks</title>
<abstract>
To be able to install Gentoo, you must create the necessary partitions.
This chapter describes how to partition a disk for future usage.
</abstract>
  <include href="hb-install-mips-disk.xml"/>
</chapter>

<chapter>
<title>Installing the Gentoo Installation Files</title>
<abstract>
Gentoo installs work through a stage3 archive. In this chapter we
describe how you extract the stage3 archive and configure Portage.
</abstract>
  <include href="hb-install-stage.xml"/>
</chapter>

<chapter>
<title>Installing the Gentoo Base System</title>
<abstract>
After installing and configuring a stage3, the eventual result is that you
have a Gentoo base system at your disposal. This chapter describes how
to progress to that stadium.
</abstract>
  <include href="hb-install-system.xml"/>
</chapter>

<chapter>
<title>Configuring the Kernel</title>
<abstract>
The Linux kernel is the core of every distribution. This chapter
explains how to configure your kernel.
</abstract>
  <include href="hb-install-mips-kernel.xml"/>
</chapter>

<chapter>
<title>Configuring your System</title>
<abstract>
You need to edit some important configuration files. In this chapter
you receive an overview of these files and an explanation on how to
proceed.
</abstract>
  <include href="hb-install-config.xml"/>
</chapter>

<chapter>
<title>Installing Necessary System Tools</title>
<abstract>
As mentioned before, Gentoo is about choices. In this chapter we help you
choose and install some important tools.
</abstract>
  <include href="hb-install-tools.xml"/>
</chapter>

<chapter>
<title>Configuring the Bootloader</title>
<abstract>
On both Silicon Graphics machines, and on Cobalt servers, both require the use
of a bootloader to load the kernel.  This section covers setting up
arcboot (for SGI machines) and colo for Cobalt servers.
</abstract>
  <include href="hb-install-mips-bootloader.xml"/>
</chapter>

<chapter>
<title>Finalizing your Gentoo Installation</title>
<abstract>
You're almost done. We'll just create one (or more) users for your
system.
</abstract>
  <include href="hb-install-finalise.xml"/>
</chapter>

<chapter>
<title>Where to go from here?</title>
<abstract>
Now you have your Gentoo system, but what's next? 
</abstract>
  <include href="hb-install-next.xml"/>
</chapter>
</part>

<part>
<title>Working with Gentoo</title>
<abstract>
Learn how to work with Gentoo: installing software, altering variables, changing
Portage behaviour etc. 
</abstract>

<chapter>
<title>A Portage Introduction</title>
<abstract>
This chapter explains the "simple" steps a user definitely needs to know to
maintain the software on his system.
</abstract>
  <include href="hb-working-portage.xml"/>
</chapter>

<chapter>
<title>USE flags</title>
<abstract>
USE-flags are a very important aspect of Gentoo. In this chapter, you learn to
work with USE-flags and understand how USE-flags interact with your system.
</abstract>
  <include href="hb-working-use.xml"/>
</chapter>

<chapter>
<title>Portage Features</title>
<abstract>
Discover the features Portage has, such as support for distributed compiling,
ccache and more.
</abstract>
  <include href="hb-working-features.xml"/>
</chapter>

<chapter>
<title>Initscripts</title>
<abstract>
Gentoo uses a special initscript format which, amongst other features, allows
dependency-driven decisions and virtual initscripts. This chapter explains all
these aspects and explains how to deal with these scripts.
</abstract>
  <include href="hb-working-rcscripts.xml"/>
</chapter>

<chapter>
<title>Environment Variables</title>
<abstract>
With Gentoo you can easily manage the environment variables for your system.
This chapter explains how you do that, and also describes frequently used
variables.
</abstract>
  <include href="hb-working-variables.xml"/>
</chapter>
</part>

<part>
<title>Working with Portage</title>
<abstract>
"Working with Portage" provides an in-depth coverage of Portage, Gentoo's
Software Management Tool.
</abstract>

<chapter>
<title>Files and Directories</title>
<abstract>
Once you want to know Portage in-depth you need to know where it stores its
files and data.
</abstract>
  <include href="hb-portage-files.xml"/>
</chapter>

<chapter>
<title>Configuring through Variables</title>
<abstract>
Portage is completely configurable through various variables you can set in the
configuration file or as environment variable.
</abstract>
  <include href="hb-portage-configuration.xml"/>
</chapter>

<chapter>
<title>Mixing Software Branches</title>
<abstract>
Gentoo provides software separated in several branches, depending on stability
and architectural support. "Mixing Software Branches" inform you how these
branches can be configured and how you can override this separation
individually.
</abstract>
  <include href="hb-portage-branches.xml"/>
</chapter>

<chapter>
<title>Additional Portage Tools</title>
<abstract>
Portage comes with a few extra tools that might make your Gentoo experience even
better. Read on to discover how to use dispatch-conf and other tools.
</abstract>
  <include href="hb-portage-tools.xml"/>
</chapter>

<chapter>
<title>Diverting from the Official Tree</title>
<abstract>
"Diverting from the Official Tree" gives you some tips and tricks on how to use
your own Portage tree, how to synchronise only the categories you want, inject
packages and more.
</abstract>
  <include href="hb-portage-diverttree.xml"/>
</chapter>

<chapter>
<title>The Ebuild Application</title>
<abstract>
In "The Ebuild Application" you are informed about the steps Portage takes while
installing software and how you can do this yourself using the ebuild
application.
</abstract>
  <include href="hb-portage-ebuild.xml"/>
</chapter>
</part>

<part>
<title>Gentoo Network Configuration</title>
<abstract>A comprehensive guide to Networking in Gentoo.</abstract>

<chapter>
<title>Getting Started</title>
<abstract>
A guide to quickly get your network interface up and running in most common
environments.
</abstract>
<include href="hb-net-start.xml"/>
</chapter>

<chapter>
<title>Advanced Configuration</title>
<abstract>
Here we learn about how the configuration works - you need to know this
before we learn about modular networking.
</abstract>
<include href="hb-net-advanced.xml"/>
</chapter>

<chapter>
<title>Modular Networking</title>
<abstract>
Gentoo provides you flexible networking - here you are told about choosing
different DHCP clients, setting up bonding, bridging, VLANs and more.
</abstract>
<include href="hb-net-modules.xml"/>
</chapter>

<chapter>
<title>Wireless Networking</title>
<abstract>
Wireless isn't straight-forward. Hopefully we'll get you working!
</abstract>
<include href="hb-net-wireless.xml"/>
</chapter>

<chapter>
<title>Adding Functionality</title>
<abstract>
If you're feeling adventurous, you can add your own functions to networking.
</abstract>
<include href="hb-net-functions.xml"/>
</chapter>

<chapter>
<title>Network Management</title>
<abstract>
For laptop users or people who move their computer around different networks.
</abstract>
<include href="hb-net-management.xml"/>
</chapter>
</part>

</book>



1.1                  xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-bootloader.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-bootloader.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-bootloader.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: hb-install-mips-bootloader.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-bootloader.xml,v 1.1 2006/02/12 13:54:32 nightmorph Exp $ -->

<sections>

<version>1.8</version>
<date>2006-01-19</date>

<section id="sgi">
<title>Silicon Graphics Machines -- Setting Up Arcboot</title>
<subsection>
<title>Installing arcboot</title>
<body>

<p>
Previously in this guide, we showed you how to make a kernel, then copy it to
the volume header using <c>dvhtool</c>.  There were two main flaws with this
system:
</p>

<ul>
  <li>This is not supported on all SGI systems</li>
  <li>It requires a significantly larger volume header</li>
</ul>

<p>
In order to boot the machine, a bootloader, <c>arcboot</c> was developed for
this purpose.  Instead of putting the kernel directly into the volume header, we
leave it in <path>/boot</path> (which resides on a EXT2/3 partition), and tell
<c>arcboot</c> (which sits in the volume header in place of the kernel) where to
find it.  So our first step, is to emerge some tools that we'll use later...
</p>

<pre caption="Installing the required tools">
# <i>emerge dvhtool arcboot</i>
</pre>

<p>
That should have installed two tools, <c>arcboot</c> which sits in the volume
header and loads kernels for us, and <c>dvhtool</c> which helps us put
<c>arcboot</c> into the volume header.
</p>
<p>
The magic binary we want, hides in <path>/usr/lib/arcboot</path> -- on IP22
systems (Indy, Indigo 2, Challenge S), it'll be called
<path>arcboot.ip22</path>.  Other systems should be similar.  We
first copy this file into the volume header.
</p>

<pre caption="Installing arcboot into the volume header">
# <i>dvhtool --unix-to-vh /usr/lib/arcboot/arcboot.ip?? arcboot</i>
</pre>

<p>
We then verify the presence of the file in the volume header. 
</p>

<pre caption="Checking if arcboot made it okay">
# <i>dvhtool --print-volume-directory</i>
----- directory entries -----
Entry #0, name "linux", start 4, bytes 3262570
Entry #1, name "newlinux", start 6377, bytes 7619627
Entry #3, name "arcboot", start 21260, bytes 51448
#
</pre>

<note>
You'll notice that in my case, I've got two old kernels sitting around there,
<path>linux</path> and <path>newlinux</path>.  This is a hangover from before we
started using <c>arcboot</c>.  Their presence doesn't matter -- just so long as
<c>arcboot</c> is present, everything is fine.
</note>

</body>
</subsection>

<subsection>
<title>Configuring arcboot</title>

<body>

<p>
If you've ever set up the Linux Loader (<c>lilo</c>) before, you'll find that
<c>arcboot</c> employs a similar syntax in its configuration file.  Bear in mind
though; <c>arcboot</c> expects to find its configuration file existing on an
EXT2/3 partition as <path>/etc/arcboot.conf</path>.  The easiest way around this
is to make sure <path>/boot</path> is an EXT2/3 partition and that there's a
file called <path>arcboot.conf</path> inside the <path>/boot/etc</path>
directory.  An example config can be found in
<path>/etc/arcboot.conf.sample</path>
</p>

<pre caption="Putting arcboot.conf in its place">
<comment>(Create the /boot/etc directory)</comment>
# <i>mkdir /boot/etc</i>

<comment>(Put our configuration into the target directory)</comment>
# <i>cp /etc/arcboot.conf.sample /boot/etc/arcboot.conf</i>

<comment>(Create a symlink back to /etc)</comment>
# <i>ln -s /boot/etc/arcboot.conf /etc/arcboot.conf</i>

<comment>(... and a symlink in /boot pointing to itself)</comment>
# <i>(cd /boot; ln -s . boot)</i>
</pre>

<p>
You can then edit <path>/etc/arcboot.conf</path> to your own preference.
Personally, I prefer to set up two kernel images: <path>new</path>, a freshly built
image that may or may not work; and <path>working</path>, a proven trustworthy 
kernel image.  My <path>arcboot.conf</path> looks a bit like this.
</p>

<pre caption="Example arcboot.conf">
<comment># arcboot.conf</comment>
<comment>#</comment>
<comment># copyright 2002 Guido Guenther &lt;agx@×××××××.org&gt;</comment>
<comment>#</comment>
label=working
        image=/vmlinux
        append="root=/dev/sda3"

<comment># backup version</comment>
label=new
        image=/vmlinux-new
        append="root=/dev/sda3"
</pre>

<p>
Once that is set up, there's then just some little tweaks that you need to do
within the SGI PROM to make this magic work.  This is covered in, not the next
section (that's for Cobalt servers) but the following section
<uri link="#reboot">Rebooting the System</uri>.
</p>

</body>
</subsection>
</section>

<section id="cobalt">
<title>Cobalt MicroServers -- Setting Up CoLo</title>
<subsection>
<title>Installing CoLo</title>
<body>

<p>
On Cobalt servers, these machines have a much less capable firmware installed on
chip.  The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and has a
number of serious limitations.
</p>

<ul>
  <li>
    There's a 675kB limit on kernels.  The current size of Linux 2.4 makes it
    damn near impossible to make a kernel this size.  Linux 2.6 is totally out
    of the question.
  </li>
  <li>
    64-bit kernels are not supported by the stock firmware (although these are
    highly experimental on Cobalt machines at this time)
  </li>
  <li>
    The shell is basic at best
  </li>
</ul>

<p>
To overcome these limitations, an alternative firmware, called
<uri link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> (Cobalt
Loader) was developed.  This is a BOOTROM image that can either be flashed into
the chip inside the Cobalt server, or loaded from the existing firmware.
</p>

<note>
This guide will take you through setting up CoLo so that it is loaded by the
stock firmware.  This is the only truly safe, and recommended way to set up CoLo.
</note>

<warn>
You may, if you wish, flash it into the server, and totally
replace the original firmware -- however, you are entirely on your own in that
endeavour.  Should anything go wrong, you will need to physically remove the
BOOTROM and reprogram it yourself with the stock firmware.  If you are not
sure how to do this -- then <e>DO NOT</e> flash your machine.  We take no
responsibility for whatever happens if you ignore this advice.
</warn>

<p>
Okay, with the warnings over now, we'll get on with installing CoLo.  First,
start by emerging the package.
</p>

<pre caption="Emerging colo">
# <i>emerge colo</i>
</pre>

<p>
With that installed (I hope you read those messages ;-) you should be able to
look inside the <path>/usr/lib/colo</path> directory to find two files,
<path>colo-chain.elf</path>: the "kernel" for the stock firmware to load, and
<path>colo-rom-image.bin</path>: a ROM image for flashing into the BOOTROM.  We
start by mounting /boot and dumping a compressed copy of
<path>colo-chain.elf</path> in <path>/boot</path> where the system expects it.
</p>

<pre caption="Putting CoLo in its place">
# <i>gzip -9vc /usr/lib/colo/colo-chain.elf &gt; /boot/vmlinux.gz</i>
</pre>

</body>
</subsection>

<subsection>
<title>Configuring CoLo</title>

<body>

<p>
Now, when the system first boots up, it'll load CoLo which will spit up a menu
on the back LCD.  The first option (and default that is assumed after roughly 5
seconds) is to boot to the hard disk.  The system would then attempt to mount
the first Linux partition it finds, and run the script
<path>default.colo</path>.  The syntax is fully documented in the CoLo
documentation (have a peek at
<path>/usr/share/doc/colo-X.YY/README.shell.gz</path> -- where X.YY is the
version installed), and is very simple.
</p>

<note>
Just a tip: when installing kernels, I usually create two kernel images,
<path>kernel.gz.working</path> -- a known working kernel, and
<path>kernel.gz.new</path> -- a kernel that's just been compiled. You can either
use symlinks to point to the curent "new" and "working" kernels, or just rename
the kernel images.
</note>

<pre caption="A basic default.colo">
<comment>#:CoLo:#</comment>
mount hda1
load /kernel.gz.working
execute root=/dev/hda3 ro console=ttyS0,115200
</pre>

<note>
CoLo will refuse to load a script that does not begin with the <c>#:CoLo:#</c>
line.  Think of it as the equivalent of saying <c>#!/bin/sh</c> in shell
scripts.
</note>

<p>
It is also possible to ask a question, such as which kernel &amp; configuration
you'd like to boot, with a default timeout.  This is the configuration I use on
my Cobalt server:
</p>

<impo>
Please note that you need to be using CoLo v1.12 or v1.13 to use the <c>menu</c>
command. The following example won't work with v1.11.
</impo>

<impo>
The <c>menu</c> command was replaced by the <c>select</c> command in CoLo v1.14.
If you've installed a later version by hand, have a look at
<path>menu.colo</path> in the <path>examples</path> subdirectory of the CoLo
distribution.
</impo>

<pre caption="Menu-based configuration">
<comment>#:CoLo:#</comment>

lcd "Mounting hda1"
mount hda1
menu "Which Kernel?" 50 Working working New new
lcd "Loading Linux" {menu-option}
load /kernel.gz.{menu-option}
lcd "Booting..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot
</pre>

<p>
The above script asks the user which kernel he/she would like to boot (either
New or Working), then loads <path>vmlinux.gz.new</path> or
<path>vmlinux.gz.working</path> depending on the selection.  If a selection is
not made within 5 seconds (50/10ths of a second) it boots the first option.
</p>
</body>

</subsection>
</section>

<section>
<title>Setting up for Serial Console</title>

<subsection>
<body>

<p>
Okay, the Linux installation as it stands now, would boot fine, but assumes
you're going to be logged in at a physical terminal.  On Cobalt machines, this
is particularly bad -- there's no such thing as a physical terminal.
</p>

<note>
Those who do have the luxury of a supported framebuffer may skip this section if
they wish.
</note>

<p>
First, pull up an editor and hack away at <path>/etc/inittab</path>.  Further
down in the file, you'll see something like this:
</p>

<pre caption="inittab Configuration">
<comment># SERIAL CONSOLE</comment>
<comment>#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102</comment>

<comment># TERMINALS</comment>
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

<comment># What to do at the "Three Finger Salute".</comment>
ca:12345:ctrlaltdel:/sbin/shutdown -r now
</pre>

<p>
First, uncomment the <c>c0</c> line.  By default, it's set to use a terminal
baud rate of 9600 bps.  On Cobalt servers, you may want to change this to 115200
to match the baud rate decided by the BOOT ROM.  This is how that section looks
on my machine.  On a headless machine (e.g. Cobalt servers), I'll also recommend
commenting out the local terminal lines (<c>c1</c> through to <c>c6</c>)
as these have a habit of misbehaving when they can't open
<path>/dev/ttyX</path>.
</p>

<pre caption="Example snippet from inittab">
<comment># SERIAL CONSOLE</comment>
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102

<comment># TERMINALS -- These are useless on a headless qube</comment>
<comment>#c1:12345:respawn:/sbin/agetty 38400 tty1 linux</comment>
<comment>#c2:12345:respawn:/sbin/agetty 38400 tty2 linux</comment>
<comment>#c3:12345:respawn:/sbin/agetty 38400 tty3 linux</comment>
<comment>#c4:12345:respawn:/sbin/agetty 38400 tty4 linux</comment>
<comment>#c5:12345:respawn:/sbin/agetty 38400 tty5 linux</comment>
<comment>#c6:12345:respawn:/sbin/agetty 38400 tty6 linux</comment>
</pre>

<p>
Now, lastly... we have to tell the system, that the local serial port can be
trusted as a secure terminal.  The file we need to poke at is
<path>/etc/securetty</path>.  It contains a list of terminals that the system
trusts.  We simply stick in two more lines, permitting the serial line to be
used for <c>root</c> logins.
</p>

<pre caption="Enabling root logins on serial console">
<comment>(/dev/ttyS0 -- the traditional name for the first serial port)</comment>
# <i>echo 'ttyS0' >> /etc/securetty</i>

<comment>(Lately, Linux also calls this /dev/tts/0 -- so we add this
too)</comment>
# <i>echo 'tts/0' >> /etc/securetty</i>
</pre>

</body>
</subsection>
</section>

<section id="reboot">
<title>Rebooting the System</title>
<subsection>
<body>

<p>
Exit the chrooted environment and unmount all mounted partitions. Then type in 
that one magical command you have been waiting for: <c>reboot</c>.
</p>

<pre caption="Exiting the chroot, unmounting all partitions and rebooting">
# <i>exit</i>
cdimage ~# <i>cd</i>
cdimage ~# <i>umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo</i>
cdimage ~# <i>reboot</i>
</pre>

<note>
<e>Cobalt Users:</e> The rest of this section covers the setting up of the SGI
PROM so that it boots <c>arcboot</c> off disk and loads Linux.  This is not
applicable to the setup of Cobalt servers.  In fact, all your work is done --
there is no configuration needed for the first boot up, you can skip to the next
section: <uri link="?part=1&amp;chap=11">Finalising your Gentoo
Installation</uri>
</note>

</body>
</subsection>
</section>
<section>
<title>Tweaking the SGI PROM</title>
<subsection>
<body>

<p>
When you are rebooted, go to the <e>System Maintenance Menu</e> and select 
<e>Enter Command Monitor</e> (<c>5</c>). If you want to test your new Gentoo 
installation, you can just run <c>boot -f &lt;kernel name&gt;</c>. To have your 
system permanently boot into the Gentoo installation, you need to set some 
variables in the SGI PROM: 
</p>

<pre caption="Configuring the PROM to Boot Gentoo">
1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? <i>5</i>
Command Monitor.  Type "exit" to return to the menu.

<comment>(&lt;root device&gt; = Gentoo's root partition, e.g. /dev/sda3)</comment>
&gt;&gt; <i>setenv OSLoadPartition &lt;root device&gt;</i>

<comment>(To list the available kernels, type "ls")</comment>
&gt;&gt; <i>setenv OSLoader &lt;kernel name&gt;</i>
&gt;&gt; <i>setenv OSLoadFilename &lt;kernel name&gt;</i>

<comment>(Declare the kernel parameters you want to pass)</comment>
&gt;&gt; <i>setenv OSLoadOptions &lt;kernel parameters&gt;</i>

<comment>(Provide the location of the Volume Header)</comment>
&gt;&gt; <i>setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)</i>

<comment>(Automatically boot Gentoo)</comment>
&gt;&gt; <i>setenv AutoLoad Yes</i>

<comment>(Set the timezone)</comment>
&gt;&gt; <i>setenv TimeZone EST5EDT</i>

<comment>(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))</comment>
&gt;&gt; <i>setenv console d1</i>
</pre>

<p>
Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and finish 
up with <uri link="?part=1&amp;chap=11">Finalizing your Gentoo 
Installation</uri>.
</p>

</body>
</subsection>
</section>
</sections>



1.1                  xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-disk.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-disk.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-disk.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: hb-install-mips-disk.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-disk.xml,v 1.1 2006/02/12 13:54:32 nightmorph Exp $ -->

<sections>

<version>1.11</version>
<date>2005-10-02</date>

<section>
<title>Introduction to Block Devices</title>
<subsection>
<title>Block Devices</title>
<body>

<p>
We'll take a good look at disk-oriented aspects of Gentoo Linux
and Linux in general, including Linux filesystems, partitions and block devices.
Then, once you're familiar with the ins and outs of disks and filesystems,
you'll be guided through the process of setting up partitions and filesystems
for your Gentoo Linux installation.
</p>

<p>
To begin, we'll introduce <e>block devices</e>. The most famous block device is
probably the one that represents the first SCSI HD in a Linux system, namely
<path>/dev/sda</path>.
</p>

<p>
The block devices above represent an abstract interface to the disk. User
programs can use these block devices to interact with your disk without worrying
about whether your drives are IDE, SCSI or something else. The program can
simply address the storage on the disk as a bunch of contiguous,
randomly-accessible 512-byte blocks.
</p>

</body>
</subsection>
<subsection>
<title>Partitions</title>
<body>

<p>
Although it is theoretically possible to use a full disk to house your Linux
system, this is almost never done in practice. Instead, full disk block devices
are split up in smaller, more manageable block devices. These are called 
<e>partitions</e>. 
</p>

</body>
</subsection>
</section>
<section>
<title>Designing a Partitioning Scheme</title>
<subsection>
<title>How Many and How Big?</title>
<body>

<p>
The number of partitions is highly dependent on your environment. For instance,
if you have lots of users, you will most likely want to have your
<path>/home</path> separate as it increases security and makes backups easier.
If you are installing Gentoo to perform as a mailserver, your 
<path>/var</path> should be separate as all mails are stored inside 
<path>/var</path>. A good choice of filesystem will then maximise your 
performance. Gameservers will have a separate <path>/opt</path> as most gaming 
servers are installed there. The reason is similar for <path>/home</path>: 
security and backups. You will definitely want to keep <path>/usr</path> big:
not only will it contain the majority of applications, the Portage tree alone
takes around 500 Mbyte excluding the various sources that are stored in it.
</p>

<p>
As you can see, it very much depends on what you want to achieve. Separate
partitions or volumes have the following advantages:
</p>

<ul>
<li>
  You can choose the best performing filesystem for each partition or volume
</li>
<li>
  Your entire system cannot run out of free space if one defunct tool is
  continuously writing files to a partition or volume
</li>
<li>
  If necessary, file system checks are reduced in time, as multiple checks can
  be done in parallel (although this advantage is more with multiple disks than
  it is with multiple partitions)
</li>
<li>
  Security can be enhanced by mounting some partitions or volumes read-only, 
  nosuid (setuid bits are ignored), noexec (executable bits are ignored) etc.
</li>
</ul>

<p>
However, multiple partitions have one big disadvantage: if not configured 
properly, you might result in having a system with lots
of free space on one partition and none on another. There is also a 15-partition
limit for SCSI and SATA.
</p>

</body>
</subsection>
</section>
<section>
<title>Using fdisk on MIPS to Partition your Disk</title>
<subsection>
<title>SGI Machines: Creating an SGI Disk Label</title>
<body>

<p>
All disks in an SGI System require an <e>SGI Disk Label</e>, which serves a 
similar function as Sun &amp; MS-DOS disklabels -- It stores information about 
the disk partitions. Creating a new SGI Disk Label will create two special 
partitions on the disk:
</p>

<ul>
  <li>
    <e>SGI Volume Header</e> (9th partition): This partition is important. It
    is where the bootloader will reside, and in some cases, it will also contain
    the kernel images.
  </li>
  <li>
    <e>SGI Volume</e> (11th partition): This partition is similar in purpose to
    the Sun Disklabel's third partition of "Whole Disk". This partition spans
    the entire disk, and should be left untouched. It serves no special purpose
    other than to assist the PROM in some undocumented fashion (or it is used by
    IRIX in some way).
  </li>
</ul>

<warn>
The SGI Volume Header <e>must</e> begin at cylinder 0. Failure to do so means
you won't be able to boot from the disk.
</warn>

<p>
The following is an example excerpt from an <c>fdisk</c> session. Read and
tailor it to your needs...
</p>

<pre caption="Creating an SGI Disklabel">
# <i>fdisk /dev/sda</i>

Command (m for help): <i>x</i>

Expert command (m for help): <i>m</i>
Command action
   b   move beginning of data in a partition
   c   change number of cylinders
   d   print the raw data in the partition table
   e   list extended partitions
   f   fix partition order
   g   create an IRIX (SGI) partition table
   h   change number of heads
   m   print this menu
   p   print the partition table
   q   quit without saving changes
   r   return to main menu
   s   change number of sectors/track
   v   verify the partition table
   w   write table to disk and exit

Expert command (m for help): <i>g</i>
Building a new SGI disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content will be irrecoverably lost.

Expert command (m for help): <i>r</i>

Command (m for help): <i>p</i>

Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 17482 cylinders
Units = cylinders of 2048 * 512 bytes

----- partitions -----
Pt#     Device  Info     Start       End   Sectors  Id  System
 9:  /dev/sda1               0         4     10240   0  SGI volhdr
11:  /dev/sda2               0     17481  35803136   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----

Command (m for help):
</pre>

<note>
If your disk already has an existing SGI Disklabel, then fdisk will not allow
the creation of a new label. There are two ways around this. One is to create a
Sun or MS-DOS disklabel, write the changes to disk, and restart fdisk. The
second is to overwrite the partition table with null data via the following
command: <c>dd if=/dev/zero of=/dev/sda bs=512 count=1</c>.
</note>
</body>
</subsection>

<subsection>
<title>Getting the SGI Volume Header to just the right size</title>
<body>

<impo>
This step is often needed, due to a bug in <c>fdisk</c>.  For some reason, the
volume header isn't created correctly, the end result being it starts and ends
on cylinder 0.  This prevents multiple partitions from being created.  To get
around this issue... read on.
</impo>

<p>
Now that an SGI Disklabel is created, partitions may now be defined. In the
above example, there are already two partitions defined for you. These are the
special partitions mentioned above and should not normally be altered. However,
for installing Gentoo, we'll need to load a bootloader, and possibly multiple
kernel images (depending on system type) directly into the volume header.
The volume header itself can hold up to <e>eight</e> images of any size, 
with each image allowed eight-character names.
</p>

<p>
The process of making the volume header larger isn't exactly straight-forward;
there's a bit of a trick to it. One cannot simply delete and re-add the volume
header due to odd fdisk behavior. In the example provided below, we'll create a
50MB Volume header in conjunction with a 50MB /boot partition. The actual layout
of your disk may vary, but this is for illustrative purposes only.
</p>

<pre caption="Resizing the SGI Volume Header correctly">
Command (m for help): <i>n</i>
Partition number (1-16): <i>1</i>
First cylinder (5-8682, default 5): <i>51</i>
 Last cylinder (51-8682, default 8682): <i>101</i>

<comment>(Notice how fdisk only allows Partition #1 to be re-created starting at a     )
(minimum of cylinder 5?  Had you attempted to delete &amp; re-create the SGI      )
(Volume Header this way, this is the same issue you would have encountered.   )
(In our example, we want /boot to be 50MB, so we start it at cylinder 51 (the )
(Volume Header needs to start at cylinder 0, remember?), and set its ending   )
(cylinder to 101, which will roughly be 50MB (+/- 1-5MB).                     )</comment>

Command (m for help): <i>d</i>
Partition number (1-16): <i>9</i>

<comment>(Delete Partition #9 (SGI Volume Header))</comment>

Command (m for help): <i>n</i>
Partition number (1-16): <i>9</i>
First cylinder (0-50, default 0): <i>0</i>
 Last cylinder (0-50, default 50): <i>50</i>

<comment>(Re-Create Partition #9, ending just before Partition #1)</comment>
</pre>

<p>
If you're unsure how to use <c>fdisk</c> have a look down further at the
instructions for partitioning on Cobalts.  The concepts are exactly the same --
just remember to leave the volume header and whole disk partitions alone.
</p>

<p>
Once this is done, you are safe to create the rest of your partitions as you see
fit. After all your partitions are laid out, make sure you set the partition ID
of your swap partition to <c>82</c>, which is Linux Swap. By default, it will be
<c>83</c>, Linux Native. 
</p>

<p>
Now that your partitions are created, you can now continue with <uri
link="#filesystems">Creating Filesystems</uri>.
</p>

</body>
</subsection>

<subsection>
<title>Cobalt Machines: Partitioning your drive</title>
<body>

<p>
On Cobalt machines, the BOOTROM expects to see a MS-DOS MBR, so partitioning the
drive is relatively straightforward -- in fact, it's done the same way as you'd
do for an Intel x86 machine.  <e>However</e> there are some things you need to
bear in mind.
</p>

<ul>
  <li>
    Cobalt firmware will expect <path>/dev/hda1</path> to be a Linux partition
    formatted <e>EXT2 Revision 0</e>.  <e>EXT2 Revision 1 partitions will NOT
    WORK!</e>  (The Cobalt BOOTROM only understands EXT2r0)
  </li>
  <li>
    The above said partition must contain a gzipped ELF image,
    <path>vmlinux.gz</path> in the root of that partition, which it loads as the
    kernel
  </li>
</ul>

<p>
For that reason, I recommend creating a ~20MB <path>/boot</path> partition
formatted EXT2r0 upon which you can install CoLo &amp; your kernels.  This
allows you to run a modern filesystem (EXT3 or ReiserFS) for your root
filesystem.
</p>

<p>
I will assume you have created <path>/dev/hda1</path> to mount later as a
<path>/boot</path> partition.  If you wish to make this <path>/</path>, you'll
need to keep the PROM's expectations in mind.
</p>

<p>
So, continuing on... To create the partitions you type <c>fdisk /dev/hda</c> at
the prompt.  The main commands you need to know are these:
</p>

<ul>
  <li>
    <c>o</c>: Wipe out old partition table, starting with an empty MS-DOS
    partition table
  </li>
  <li>
    <c>n</c>: New Partition
  </li>
  <li>
    <c>t</c>: Change Partition Type
    <ul>
      <li>Use type <c>82</c> for Linux Swap, <c>83</c> for Linux FS</li>
    </ul>
  </li>
  <li>
    <c>d</c>: Delete a partition
  </li>
  <li>
    <c>p</c>: Display (print) Partition Table
  </li>
  <li>
    <c>q</c>: Quit -- leaving old partition table as is.
  </li>
  <li>
    <c>w</c>: Quit -- writing partition table in the process.
  </li>
</ul>

<pre caption="Partitioning the disk">
# <i>fdisk /dev/hda</i>

The number of cylinders for this disk is set to 19870.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

<comment>(Start by clearing out any existing partitions)</comment>
Command (m for help): <i>o</i>
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 19870.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

<comment>(You can now verify the partition table is empty using the 'p' command)</comment>

Command (m for help): <i>p</i>

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System

<comment>(Create the /boot partition)</comment>

Command (m for help): <i>n</i>
Command action
   e   extended
   p   primary partition (1-4)
<i>p</i>
Partition number (1-4): <i>1</i>

<comment>(Just press ENTER here to accept the default)</comment>

First cylinder (1-19870, default 1):
Last cylinder or +size or +sizeM or +sizeK (1-19870, default 19870): <i>+20M</i>

<comment>(and now if we type 'p' again, we should see the new partition)</comment>
Command (m for help): <i>p</i>

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          40       20128+  83  Linux

<comment>(The rest, I prefer to put in an extended partition, so I'll create that)</comment>

Command (m for help): <i>n</i>
Command action
   e   extended
   p   primary partition (1-4)
<i>e</i>
Partition number (1-4): <i>2</i>

<comment>(Again, the default is fine, just press ENTER.)</comment>

First cylinder (41-19870, default 41):
Using default value 41

<comment>(We want to use the whole disk here, so just press ENTER again)</comment>
Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870):
Using default value 19870

<comment>(Now, the / partition -- I use separate partitions for /usr, /var,
etc... so / can be small.  Adjust as per your preference.)</comment>

Command (m for help): <i>n</i>
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
<i>l</i>
First cylinder (41-19870, default 41):<i>&lt;Press ENTER&gt;</i>
Using default value 41
Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): <i>+500M</i>

<comment>(... and similar for any other partitions ...)</comment>

<comment>(Last but not least, the swap space.  I recommend at least 250MB swap,
preferrably 1GB)</comment>

Command (m for help): <i>n</i>
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
<i>l</i>
First cylinder (17294-19870, default 17294): <i>&lt;Press ENTER&gt;</i>
Using default value 17294
Last cylinder or +size or +sizeM or +sizeK (1011-19870, default 19870): <i>&lt;Press ENTER&gt;</i>
Using default value 19870

<comment>(Now, if we check our partition table, everything should mostly be ship
shape except for one thing...)</comment>

Command (m for help): <i>p</i>

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot      Start         End      Blocks      ID  System
/dev/hda1               1          21       10552+  83  Linux
/dev/hda2              22       19870    10003896    5  Extended
/dev/hda5              22        1037      512032+  83  Linux
/dev/hda6            1038        5101     2048224+  83  Linux
/dev/hda7            5102        9165     2048224+  83  Linux
/dev/hda8            9166       13229     2048224+  83  Linux
/dev/hda9           13230       17293     2048224+  83  Linux
/dev/hda10          17294       19870     1298776+  83  Linux

<comment>(Notice how #10, our swap partition is still type 83?)</comment>

Command (m for help): <i>t</i>
Partition number (1-10): <i>10</i>
Hex code (type L to list codes): <i>82</i>
Changed system type of partition 10 to 82 (Linux swap)

<comment>(That should fix it... just to verify...)</comment>

Command (m for help): <i>p</i>

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot      Start         End      Blocks      ID  System
/dev/hda1               1          21       10552+  83  Linux
/dev/hda2              22       19870    10003896    5  Extended
/dev/hda5              22        1037      512032+  83  Linux
/dev/hda6            1038        5101     2048224+  83  Linux
/dev/hda7            5102        9165     2048224+  83  Linux
/dev/hda8            9166       13229     2048224+  83  Linux
/dev/hda9           13230       17293     2048224+  83  Linux
/dev/hda10          17294       19870     1298776+  82  Linux Swap

<comment>(Now, we write out the new partition table.)</comment>

Command (m for help): <i>w</i>
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

#
</pre>

<p>
And that's all there is to it.  You should now be right to proceed onto the
next stage: <uri link="#filesystems">Creating Filesystems</uri>.
</p>

</body>
</subsection>
</section>

<section id="filesystems">
<title>Creating Filesystems</title>
<subsection>
<title>Introduction</title>
<body>

<p>
Now that your partitions are created, it is time to place a filesystem on them. 
If you don't care about what filesystem to choose and are happy with what we use
as default in this handbook, continue with <uri 
link="#filesystems-apply">Applying a Filesystem to a Partition</uri>.
Otherwise read on to learn about the available filesystems...
</p>

</body>
</subsection>
<subsection>
<title>Filesystems?</title>
<body>

<p>
Several filesystems are available.  ReiserFS, EXT2 and EXT3 are found stable
on the MIPS architectures, others are experimental.
</p>

<p>
<b>ext2</b> is the tried and true Linux filesystem but doesn't have metadata
journaling, which means that routine ext2 filesystem checks at startup time can
be quite time-consuming. There is now quite a selection of newer-generation
journaled filesystems that can be checked for consistency very quickly and are
thus generally preferred over their non-journaled counterparts. Journaled
filesystems prevent long delays when you boot your system and your filesystem
happens to be in an inconsistent state.
</p>

<p>
<b>ext3</b> is the journaled version of the ext2 filesystem, providing metadata
journaling for fast recovery in addition to other enhanced journaling modes like
full data and ordered data journaling. ext3 is a very good and reliable
filesystem. It has an additional hashed b-tree indexing option that enables 
high performance in almost all situations. You can enable this indexing by
adding <c>-O dir_index</c> to the <c>mke2fs</c> command. In short, ext3 is an 
excellent filesystem.
</p>

<p>
<b>ReiserFS</b> is a B*-tree based filesystem that has very good overall 
performance and greatly outperforms both ext2 and ext3 when dealing with small 
files (files less than 4k), often by a factor of 10x-15x. ReiserFS also scales 
extremely well and has metadata journaling. As of kernel 2.4.18+, ReiserFS is 
solid and usable as both general-purpose filesystem and for extreme cases such 
as the creation of large filesystems, the use of many small files, very large 
files and directories containing tens of thousands of files. 
</p>

<p>
<b>XFS</b> is a filesystem with metadata journaling which comes with a robust
feature-set and is optimized for scalability. We only recommend using this
filesystem on Linux systems with high-end SCSI and/or fibre channel storage and
an uninterruptible power supply. Because XFS aggressively caches in-transit data
in RAM, improperly designed programs (those that don't take proper precautions
when writing files to disk and there are quite a few of them) can lose a good
deal of data if the system goes down unexpectedly.
</p>

<p>
<b>JFS</b> is IBM's high-performance journaling filesystem. It has recently 
become production-ready and there hasn't been a sufficient track record to 
comment positively nor negatively on its general stability at this point.
</p>

</body>
</subsection>
<subsection id="filesystems-apply">
<title>Applying a Filesystem to a Partition</title>
<body>

<p>
To create a filesystem on a partition or volume, there are tools available for 
each possible filesystem:
</p>

<table>
<tr>
  <th>Filesystem</th>
  <th>Creation Command</th>
</tr>
<tr>
  <ti>ext2</ti>
  <ti><c>mke2fs</c></ti>
</tr>
<tr>
  <ti>ext3</ti>
  <ti><c>mke2fs -j</c></ti>
</tr>
<tr>
  <ti>reiserfs</ti>
  <ti><c>mkreiserfs</c></ti>
</tr>
<tr>
  <ti>xfs</ti>
  <ti><c>mkfs.xfs</c></ti>
</tr>
<tr>
  <ti>jfs</ti>
  <ti><c>mkfs.jfs</c></ti>
</tr>
</table>

<p>
For instance, to have the boot partition (<path>/dev/sda1</path> in our
example) in ext2 and the root partition (<path>/dev/sda3</path> in our example)
in ext3, you would use:
</p>

<pre caption="Applying a filesystem on a partition">
# <i>mke2fs /dev/sda1</i>
# <i>mke2fs -j /dev/sda3</i>
</pre>

<p>
Now create the filesystems on your newly created partitions (or logical
volumes).
</p>

<warn>
If you're installing on a Cobalt server, remember <path>/dev/hda1</path> MUST be
of type <e>EXT2 revision 0</e>; Anything else (e.g. EXT2 revision 1, EXT3,
ReiserFS, XFS, JFS and others) <e>WILL NOT WORK!</e>
You can format the partition using the command: <c>mke2fs -r 0 /dev/hda1</c>.
</warn>

<warn>
Also, be aware that arcboot currently is not able to read any filesystem other
than EXT2, EXT3 and ISO9660 (recent versions).  For that reason,
<path>/boot</path> on SGI machines must also reside on an EXT2 or EXT3 partition.
</warn>

</body>
</subsection>
<subsection>
<title>Activating the Swap Partition</title>
<body>

<p>
<c>mkswap</c> is the command that is used to create and initialize swap partitions:
</p>

<pre caption="Creating a Swap signature">
# <i>mkswap /dev/sda2</i>
</pre>

<p>
To activate the swap partition, use <c>swapon</c>:
</p>

<pre caption="Activating the swap partition">
# <i>swapon /dev/sda2</i>
</pre>

<p>
Create and activate the swap with the commands mentioned above.
</p>

</body>
</subsection>
</section>
<section>
<title>Mounting</title>
<body>

<p>
Now that your partitions are initialized and are housing a filesystem, it is
time to mount those partitions. Use the <c>mount</c> command. Don't forget to
create the necessary mount directories for every partition you created. As an
example we mount the root and boot partition:
</p>

<pre caption="Mounting partitions">
# <i>mount /dev/sda3 /mnt/gentoo</i>
# <i>mkdir /mnt/gentoo/boot</i>
# <i>mount /dev/sda1 /mnt/gentoo/boot</i>
</pre>

<note>
If you want your <path>/tmp</path> to reside on a separate partition, be sure to
change its permissions after mounting: <c>chmod 1777 /mnt/gentoo/tmp</c>. This
also holds for <path>/var/tmp</path>.
</note>

<p>
We will also have to mount the proc filesystem (a virtual interface with the 
kernel) on <path>/proc</path>. But first we will need to place our files on the partitions.
</p>

<p>
Continue with <uri link="?part=1&amp;chap=5">Installing the Gentoo
Installation Files</uri>.
</p>

</body>
</section>
</sections>



1.1                  xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-kernel.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-kernel.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-kernel.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: hb-install-mips-kernel.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-kernel.xml,v 1.1 2006/02/12 13:54:32 nightmorph Exp $ -->

<sections>

<version>1.15</version>
<date>2006-01-06</date>

<section>
<title>Timezone</title>
<body>

<p>
You first need to select your timezone so that your system knows where it is
located. Look for your timezone in <path>/usr/share/zoneinfo</path>, then copy
it to <path>/etc/localtime</path>. Please avoid the
<path>/usr/share/zoneinfo/Etc/GMT*</path> timezones as their names do not
indicate the expected zones. For instance, <path>GMT-8</path> is in fact GMT+8.
</p>

<pre caption="Setting the timezone information to GMT">
# <i>cp /usr/share/zoneinfo/GMT /etc/localtime</i>
</pre>

</body>
</section>
<section>
<title>Installing the Sources</title>
<subsection>
<title>Choosing a Kernel</title>
<body>

<p>
The core around which all distributions are built is the Linux kernel. It is the
layer between the user programs and your system hardware. Gentoo provides its
users several possible kernel sources. A full listing with description is
available at the <uri link="/doc/en/gentoo-kernel.xml">Gentoo Kernel
Guide</uri>. 
</p>

<p>
MIPS-based systems can choose from <c>mips-sources</c> (the default kernel
source for the MIPS architecture) and <c>mips-prepatch-sources</c> (prerelease
kernel tree).
</p>

<p>
Choose your kernel source and install it using <c>emerge</c>.  Of course
substitute with your choice of sources, this is merely an example.  The
<c>USE="-doc"</c> is necessary to avoid installing xorg-x11 or other
dependencies at this point. <c>USE="symlink"</c> is not necessary for a new
install, but ensures proper creation of the <path>/usr/src/linux</path>
symlink.
</p>

<note>
Special patches are needed to make a kernel work on Cobalt servers.  The
<c>cobalt</c> USE flag must be defined in order to grab the necessary patches
and apply them.
</note>

<pre caption="Installing a kernel source">
<comment>(For SGI machines)</comment>
# <i>USE="-doc symlink" emerge mips-sources</i>

<comment>(For Cobalt machines)</comment>
# <i>mkdir -p /etc/portage</i>
# <i>echo "sys-kernel/mips-sources cobalt" &gt;&gt; /etc/portage/package.use</i>
# <i>USE="-doc symlink" emerge mips-sources</i>
</pre>

<p>
When you take a look in <path>/usr/src</path> you should see a symlink called
<path>linux</path> pointing to your kernel source. In this case, the installed
kernel source points to <c>mips-sources-2.4.24</c>. Your version may be
different, so keep this in mind.
</p>

<pre caption="Viewing the kernel source symlink">
# <i>ls -l /usr/src/linux</i>
lrwxrwxrwx    1 root     root           12 Oct 13 11:04 /usr/src/linux -&gt; linux-2.4.24
</pre>

<p>
Now it is time to configure and compile your kernel source. 
</p>

</body>
</subsection>
</section>
<section>
<title>Kernel Compilation &amp; Installation</title>
<subsection>
<title>Introduction</title>
<body>

<p>
Previously, we went through the manual configuration of how to set up the kernel
sources.  Instead, we have uploaded a number of sample configurations which you
can base your configuration upon.  Simply click on the closest option that
matches your system and kernel version.  You may also find other configuration
samples at the URLs mentioned below.
</p>

<table>
  <tr>
    <th>System</th>
    <th>Kernel Version</th>
  </tr>
  <tr>
    <ti>SGI IP22 (Indy, Indigo 2, Challenge S)</ti>
    <ti>
      <uri link="http://www.longlandclan.hopto.org/~stuartl/mips-linux/sgi/ip22/config/2.4.29-mipscvs-20050130.gz">2.4.29</uri>
    </ti>
  </tr>
  <tr>
    <ti>Cobalt Qube/Raq 2800</ti>
    <ti>
      <uri link="http://dev.gentoo.org/~kumba/mips/cobalt/kernel/cobalt-2605.config">2.6.5</uri>
      <uri link="http://dev.gentoo.org/~kumba/mips/cobalt/kernel/cobalt-2606.config">2.6.6</uri>
      <uri link="http://dev.gentoo.org/~kumba/mips/cobalt/kernel/cobalt-config-2609">2.6.9</uri>
    </ti>
  </tr>
</table>

<ul>
  <li>
    IP22 (Indy, Indigo2, Challenge S) Configurations:
    <uri link="http://www.longlandclan.hopto.org/~stuartl/mips-linux/sgi/ip22/config">
      http://www.longlandclan.hopto.org/~stuartl/mips-linux/sgi/ip22/config
    </uri>
  </li>
  <li>
    Cobalt Server Configurations:
    <uri link="http://dev.gentoo.org/~kumba/mips">
      http://dev.gentoo.org/~kumba/mips
    </uri>
  </li>
</ul>

<note>
More kernel configuration examples can be found on the Gentoo/MIPS Hardware
Support Database, which is located at
<uri>http://stuartl.longlandclan.hopto.org/gentoo/mips</uri>.
</note>

<p>
Once you have found a configuration, download it into your kernel source
directory, and rename it to <path>.config</path>.  From there, you can run
<c>make oldconfig</c> to bring everything up to date, and allow you to customise
the configuration before compiling.
</p>

<pre caption="Configuring the kernel">
# <i>cd /usr/src/linux</i>
# <i>cp /path/to/example-config .config</i>
# <i>make oldconfig</i>
<comment>(Just press ENTER at each prompt to accept the defaults... we'll customise later)</comment>
# <i>make menuconfig</i>
</pre>

</body>
</subsection>
<subsection id="compiling">
<title>Compiling and Installing</title>
<body>

<p>
Now that your kernel is configured, it is time to compile and install it. Exit 
the configuration and start the compilation process:
</p>

<pre caption="Compiling the kernel">
<comment>(For 2.4 kernel)</comment>
# <i>make dep &amp;&amp; make vmlinux modules modules_install</i>

<comment>(For 2.6 kernel)</comment>
# <i>make &amp;&amp; make modules_install</i>
</pre>

<p>
When the kernel has finished compiling, copy the kernel image to
<path>/boot</path>. 
</p>

<note>
On Cobalt servers, the bootloader will expect to see a compressed kernel image.
Remember to <c>gzip -9</c> the file once it is in <path>/boot</path>. In the
following example, replace <path>&lt;kernel-version&gt;</path> with your kernel
version.
</note>

<pre caption="Installing the kernel">
# <i>cp vmlinux /boot/&lt;kernel-version&lt;</i>
<comment>(Cobalt Servers -- Compressing the kernel image)</comment>
# <i>gzip -9v /boot/&lt;kernel-version&lt;</i>
</pre>

<!--
Moot point, now that we use arcboot on SGI, and CoLo on Cobalts
<p>
If your system doesn't boot ELF kernels, compile the
kernel using <c>make vmlinux.ecoff</c> instead of <c>make vmlinux</c>. The
kernel image will be saved as <path>arch/mips/boot/vmlinux.ecoff</path> instead
of <path>vmlinux</path>.
</p>
-->
</body>
</subsection>
</section>
<section id="kernel_modules">
<title>Installing Separate Kernel Modules</title>
<subsection>
<title>Configuring the Modules</title>
<body>

<p>
You should list the modules you want automatically loaded in one of the relevant
files listed below.  You can add extra options to the modules too if you want.
</p>

<ul>
  <li><path>/etc/modules.autoload.d/kernel-2.4</path> - Kernel 2.4 only</li>
  <li><path>/etc/modules.autoload.d/kernel-2.6</path> - Kernel 2.6 only</li>
  <li><path>/etc/modules.autoload</path> - All Kernels</li>
</ul>

<p>
Therefore, if you have a kernel module that you want to load -- which is common
to both 2.4 and 2.6, then place it in <path>/etc/modules.autoload</path>.
Otherwise it can be placed in the appropriate file.
</p>

<p>
To view all available modules, run the following <c>find</c> command. Don't
forget to substitute "&lt;kernel version&gt;" with the version of the kernel you
just compiled:
</p>

<pre caption="Viewing all available modules">
# <i>find /lib/modules/&lt;kernel version&gt;/ -type f -iname '*.o' -or -iname '*.ko'</i>
</pre>

<p>
For instance, to automatically load the <c>3c59x.o</c> module, edit the
appropriate file and enter the module name in it.
</p>

<pre caption="Editing /etc/modules.autoload.d/kernel-2.4">
# <i>nano -w /etc/modules.autoload.d/kernel-2.4</i>
</pre>

<pre caption="/etc/modules.autoload.d/kernel-2.4 or kernel-2.6">
3c59x
</pre>

<p>
This can be also done in a one-liner:
</p>

<pre caption="Adding a module -- the one-liner method">
# <i>echo '3c59x' >> /etc/modules.autoload.d/kernel-2.4</i>
<comment>(or kernel-2.6, or /etc/modules.autoload...)</comment>
</pre>

<p>
Continue the installation with <uri link="?part=1&amp;chap=8">Configuring 
your System</uri>.
</p>

</body>
</subsection>
</section>
</sections>



1.1                  xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-medium.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-medium.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-medium.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: hb-install-mips-medium.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-medium.xml,v 1.1 2006/02/12 13:54:32 nightmorph Exp $ -->

<sections>

<version>1.11</version>
<date>2005-11-11</date>

<section>
<title>Hardware Requirements</title>
<subsection>
<title>Introduction</title>
<body>

<p>
Before we start, we first list what hardware requirements you need to
successfully install Gentoo on your box. 
</p>

</body>
</subsection>
<subsection>
<title>Hardware Requirements</title>
<body>

<table>
<tr>
  <th>Memory</th>
  <ti>64 MB</ti>
</tr>
<tr>
  <th>Diskspace</th>
  <ti>1.5 GB (excluding swap space)</ti>
</tr>
<tr>
  <th>Swap space</th>
  <ti>At least 256 MB</ti>
</tr>
</table>

<p>
You should also check the <uri link="/doc/en/mips-requirements.xml">MIPS 
Hardware Requirements</uri> document available from our website.
</p>

</body>
</subsection>
</section>

<section>
<title>Installation Notes</title>
<subsection>
<title>A note about Processor Architectures</title>
<body>

<p>
On many architectures, the processor has gone through several generations, each
newer generation builds on the foundation of the previous one.  MIPS is no
exception.  There are several generations of CPU covered under the MIPS
architecture.  In order to choose your netboot image stage tarball and
<c>CFLAGS</c> appropriately, you need to be aware of which family your system's
CPU belongs in.  These families are referred to as the <b>I</b>nstruction
<b>S</b>et <b>A</b>rchitecture.
</p>

<table>
  <tr>
    <th>MIPS ISA</th>
    <th>32/64-bit</th>
    <th>CPUs Covered</th>
  </tr>
  <tr>
    <ti>MIPS 1</ti>
    <ti>32-bit</ti>
    <ti>
      <uri link="http://www.linux-mips.org/wiki/index.php/R2000">R2000</uri>, 
      <uri link="http://www.linux-mips.org/wiki/index.php/R2000">R3000</uri>
    </ti>
  </tr>
  <tr>
    <ti>MIPS 2</ti>
    <ti>32-bit</ti>
    <ti>
      <uri link="http://www.linux-mips.org/wiki/index.php/R6000">R6000</uri>
    </ti>
  </tr>
  <tr>
    <ti>MIPS 3</ti>
    <ti>64-bit</ti>
    <ti>
      <uri link="http://www.linux-mips.org/wiki/index.php/R4000">R4000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R4000">R4400</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R4000">R4600</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R4000">R4700</uri>
    </ti>
  </tr>
  <tr>
    <ti>MIPS 4</ti>
    <ti>64-bit</ti>
    <ti>
      <uri link="http://www.linux-mips.org/wiki/index.php/R5000">R5000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R5000">RM5000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/RM7000">RM7000</uri>
      <uri link="http://www.linux-mips.org/wiki/index.php/R8000">R8000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R10000">R10000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R10000">R12000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R10000">R14000</uri>,
      <uri link="http://www.linux-mips.org/wiki/index.php/R10000">R16000</uri>
    </ti>
  </tr>
  <tr>
    <ti>MIPS 5</ti>
    <ti>64-bit</ti>
    <ti>
      None As Yet
    </ti>
  </tr>
</table>

<p>
Also, another important concept to grasp is the concept of <b>endianness</b>.
Endianness refers to the way that a CPU reads words from main memory.  A word
can be read as either <e>big</e> endian (most significant bit first), or
<e>little</e> endian (least significant bit first).  Intel x86 machines are
generally Little endian, whilst Apple and Sparc machines are Big Endian.  On
MIPS, they can be either.  To separate them apart, we append <c>el</c> to the
architecture name to denote little endian.
</p>

<table>
  <tr>
    <th>Architecture</th>
    <th>32/64-bit</th>
    <th>Endianness</th>
    <th>Machines covered</th>
  </tr>
  <tr>
    <ti><c>mips</c></ti>
    <ti>32-bit</ti>
    <ti>Big Endian</ti>
    <ti>Silicon Graphics</ti>
  </tr>
  <tr>
    <ti><c>mipsel</c></ti>
    <ti>32-bit</ti>
    <ti>Little Endian</ti>
    <ti>DECStations, Cobalt Servers, PlayStation 2</ti>
  </tr>
  <tr>
    <ti><c>mips64</c></ti>
    <ti>64-bit</ti>
    <ti>Big Endian</ti>
    <ti>Silicon Graphics</ti>
  </tr>
  <tr>
    <ti><c>mips64el</c></ti>
    <ti>64-bit</ti>
    <ti>Little Endian</ti>
    <ti>Cobalt Servers, PlayStation 2</ti>
  </tr>
</table>

<p>
For those willing to learn more about ISAs, the following websites may be
of assistance.
</p>

<ul>
  <li>
    <uri link="http://www.linux-mips.org/wiki/index.php/Instruction_Set_Architecture">
      Linux/MIPS Website: MIPS ISA
    </uri>
  </li>
  <li>
    <uri link="http://www.linux-mips.org/wiki/index.php/Endianess">
      Linux/MIPS Website: Endianness  
    </uri>
  </li>
  <li>
    <uri link="http://www.linux-mips.org/wiki/index.php/Processors">
      Linux/MIPS Website: Processors
    </uri>
  </li>
  <li>
    <uri link="http://en.wikipedia.org/wiki/Instruction_set">
      Wikipedia: Instruction Set
    </uri>
  </li>
</ul>

</body>
</subsection>
<subsection>
<title>The Stage3 Tarball</title>
<body>

<p>
A stage3 tarball is an archive containing a minimal Gentoo environment, suitable
to continue the Gentoo installation using the instructions in this manual.
Previously, the Gentoo Handbook described the installation using one of three 
stage tarballs. While Gentoo still offers stage1 and stage2 tarballs, the 
official installation method uses the stage3 tarball. If you are interested in
performing a Gentoo installation using a stage1 or stage2 tarball, please read
the Gentoo FAQ on <uri link="/doc/en/faq.xml#stage12">How do I Install Gentoo
Using a Stage1 or Stage2 Tarball?</uri>
</p>

</body>
</subsection>
</section>

<section>
<title>Netbooting Overview</title>
<subsection>
<body>

<p>
In this section, we'll cover what you need in order to successfully network boot
a Silicon Graphics workstation or Cobalt Server appliance.  This is just a brief
guide, it is not intended to be thorough, for more information, I recommend
reading the <uri link="/doc/en/diskless-howto.xml">Diskless
HOWTO</uri>.
</p>

<p>
What You Need: Depending on the machine, there is a certain amount of
hardware that you'll need in order to successfully netboot and install Linux.
</p>

<ul>
  <li>
    In General:
    <ul>
      <li>DHCP/BOOTP server (ISC DHCPd recommended)</li>
      <li>Patience -- and lots of it</li>
    </ul>
  </li>
  <li>
    For Silicon Graphics workstations:
    <ul>
      <li>TFTP server (tftp-hpa recommended)</li>
      <li>
        If you want/need to use serial console:
        <ul>
          <li>MiniDIN8 --&gt; RS-232 serial cable</li>
          <li>Null-modem cable</li>
          <li>VT100 or ANSI compatable terminal capable of 9600 baud</li>
        </ul>
      </li>
    </ul>
  </li>
  <li>
    For Cobalt Servers (NOT the original Qube):
    <ul>
      <li>NFS server</li>
      <li>Null-modem cable</li>
      <li>VT100 or ANSI compatable terminal capable of 115200 baud</li>
    </ul>
  </li>
</ul>

<note>
SGI machines use a MiniDIN 8 connector for the serial ports.  Apparently Apple
modem cables work just fine as serial cables, but with Apple machines being
equipped with USB &amp; internal modems, these are getting harder to
find.  A number of sites describe how to make these cables (Google is your
friend).  The following site describes making such a cable.  It's in German,
but has a reasonably good wiring diagram.
<uri link="http://www.arbeitsplatzvernichtung-durch-outsourcing.de/marty44/sgihard.html">
  http://www.arbeitsplatzvernichtung-durch-outsourcing.de/marty44/sgihard.html
</uri>
</note>

<note>
For the terminal, this could be a real VT100/ANSI terminal, or it could be a PC
running terminal emulation software (such as HyperTerminal, Minicom, seyon,
Telex, xc, screen -- whatever your preference).  It doesn't matter what platform
this machine runs -- just so long as it has one RS-232 serial port you can use,
and appropriate software.
</note>

<note>
Note that this guide does NOT cover the original Qube.  The original Qube server
appliance lacks a serial port in its default configuration, and therefore it is
not possible to install Gentoo onto it without the aid of a screwdriver and a
surrogate machine to do the installation.
The following site has a guide for installing Gentoo on these machines.
<uri link="http://www.metzner.org/projects/qube/">
  http://www.metzner.org/projects/qube/
</uri>
</note>
</body>
</subsection>
<subsection>
<title>Setting up TFTP and DHCP -- a brief guide</title>
<body>

<p>
Okay, so you've got your bits and pieces together, now to set everything up.  As
I mentioned earlier -- this is not a complete guide, this is a bare-bones config
that will just get things rolling.  You can either use this when starting a
setup from scratch, or use the suggestions to amend your existing setup to
support netbooting.
</p>

<p>
It is worth noting that the servers used need not be running Gentoo Linux, you
could quite reasonably use FreeBSD or any Unix-like platform.  However, this
guide will assume you are running Gentoo Linux.  You also may run TFTP/NFS on a
separate machine to the DHCP server if desired.
</p>

<p>
First Step -- configuring DHCP.  In order for the ISC DHCP daemon to respond
to BOOTP requests (as required by the SGI &amp; Cobalt BOOTROM) you need to
first enable dynamic BOOTP on the address range in use; then set up an entry for
each client with pointers to the boot image.
</p>

<pre caption="Installing ISCs DHCP">
# <i>emerge dhcp</i>
</pre>

<p>
Once installed you need to create the <path>/etc/dhcp/dhcpd.conf</path>.  Here's
a bare-bones config to get you started.
</p>

<pre caption="Bare Bones dhcpd.conf">
<comment># Tell dhcpd to disable dynamic DNS.</comment>
<comment># dhcpd will refuse to start without this.</comment>
ddns-update-style none;

<comment># Create a subnet:</comment>
subnet <i>192.168.10.0</i> netmask <i>255.255.255.0</i> {
  <comment># Address pool for our booting clients.  Don't forget the 'dynamic-bootp' bit!</comment>
  pool {
    range dynamic-bootp <i>192.168.10.1 192.168.10.254</i>;
  }

  <comment># DNS servers and default gateway -- substitute as appropriate</comment>
  option domain-name-servers <i>203.1.72.96</i>, <i>202.47.56.17</i>;
  option routers <i>192.168.10.1</i>;

  <comment># Tell the DHCP server it's authoritative for this subnet.</comment>
  authoritative;

  <comment># Allow BOOTP to be used on this subnet.</comment>
  allow bootp;
}
</pre>

<p>
With that setup, one can then add any number of clients within the subnet
clause.  We will cover what you need to put in later in this guide.
</p>

<p>
Next Step -- Setting up TFTP server.  For the purposes of this guide, I'll
restrict this to the tftp-hpa TFTP daemon.  I use this myself on SGI machines,
Cobalt servers and PXE clients alike without any hassle.  Installation and
configuration is fairly straightforward:
</p>

<pre caption="Installing tftp-hpa">
# <i>emerge net-ftp/tftp-hpa</i>
</pre>

<p>
Now, I personally like to move my <path>/tftpboot</path> directory into
<path>/home</path> where I have more space.  This is totally optional, and can
be configured through the <path>/etc/conf.d/in.tftpd</path> file.  For the
purposes of this guide, I'll assume you've left it in the default place.
</p>

<p>
Now that everything is configured, we're ready to move onto the fun bit --
tayloring our config to suit the machine we wish to netboot.
</p>

</body>
</subsection>
</section>
<section>
<title>Netbooting on SGI Workstations</title>
<subsection>
<title>Downloading a Netboot image</title>
<body>

<p>
Depending on the system you're installing for, there are several possible images
available for download.  These are all labelled according to the system type and
CPU they are compiled for.  The machine types are as follows:
</p>

<table>
  <tr>
    <th>Codename</th>
    <th>Machines</th>
  </tr>
  <tr>
    <ti>IP22</ti>
    <ti>Indy, *Indigo 2, **Challenge S</ti>
  </tr>
  <tr>
    <ti>IP26</ti>
    <ti>*Indigo 2 Power</ti>
  </tr>
  <tr>
    <ti>IP27</ti>
    <ti>Origin 200, Origin 2000</ti>
  </tr>
  <tr>
    <ti>IP28</ti>
    <ti>*Indigo 2 Impact</ti>
  </tr>
  <tr>
    <ti>IP30</ti>
    <ti>Octane</ti>
  </tr>
  <tr>
    <ti>IP32</ti>
    <ti>O2</ti>
  </tr>
</table>

<note>
* It is a common mistake to mix up the IRIS Indigo (IP12 w/ R3000 CPU or IP20 w/
R4000 CPU, neither of which run Linux), the Indigo 2 (IP22, which runs
Linux fine), the R8000-based Indigo 2 Power (which doesn't run Linux at all) and
the R10000-based Indigo 2 Impact (IP28, which is highly experimental).
Please bear in mind that these are different machines.
</note>

<note>
** On the Challenge S, the UTP network port is hung off a WD33C95 SCSI
card, which is currently unsupported on Linux.  Because of this limitation,
you'll need to use an AUI--&gt;UTP transceiver connected to the AUI port.
</note>

<p>
Also in the filename, r4k refers to R4000-series processors, r5k for R5000,
rm5k for the RM5200 and r10k for R10000.  You will find the images available at
<uri link="http://dev.gentoo.org/~kumba/mips/netboot">
http://dev.gentoo.org/~kumba/mips/netboot.
</uri>
</p>
</body>
</subsection>

<subsection>
<title>DHCP Configuration for an SGI Client</title>
<body>

<p>
Once you have downloaded the file, simply place it in your
<path>/tftpboot</path> directory.  Then edit your
<path>/etc/dhcp/dhcpd.conf</path> and add the entry for your SGI client.
</p>

<note>
You may need to create the <path>/tftpboot</path> directory if it isn't
there already.
</note>

<pre caption="dhcpd.conf snippet for SGI Workstation">
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
  <comment># ... usual stuff here ...</comment>

  <comment># SGI Workstation... change 'sgi' to your SGI machine's hostname.</comment>
  host <i>sgi</i> {
  
    <comment># MAC Address of SGI Machine.  Normally this is written on the back</comment>
    <comment># or base of the machine.</comment>
    hardware ethernet <i>08:00:69:08:db:77</i>;

    <comment># TFTP Server to download from (by default, same as DHCP server)</comment>
    next-server <i>192.168.10.1</i>;

    <comment># IP address to give to the SGI machine</comment>
    fixed-address <i>192.168.10.3</i>;

    <comment># Filename for the PROM to download and boot</comment>
    filename "<i>/gentoo-r4k.img</i>";
  }
}
</pre>
</body>
</subsection>

<subsection>
<title>Kernel Options</title>
<body>
<p>
We're almost done, but there's a couple of little tweaks still to be done.  Pull
up a console with root privileges, and enter the following commands.
</p>

<pre caption="Some fixes to SGI machines to have TFTP work properly">
<comment>(Disable "Path Maximum Transfer Unit", otherwise SGI Prom won't find the kernel)</comment>
# <i>echo 1 &gt; /proc/sys/net/ipv4/ip_no_pmtu_disc</i>

<comment>(Set the port range usable by the SGI PROM)</comment>
# <i>echo "2048 32767" &gt; /proc/sys/net/ipv4/ip_local_port_range</i>
</pre>

<p>
This should be sufficient to allow the Linux server to play nice with SGI's
PROM.
</p>

</body>
</subsection>
<subsection>
<title>Start Your Daemons...</title>
<body>
<p>
At this point, you should be ready to start the daemons.  Enter the following:
</p>

<pre caption="Starting the DHCP and TFTP daemons">
# <i>/etc/init.d/dhcp start</i>
# <i>/etc/init.d/in.tftpd start</i>
</pre>

<p>
If nothing went wrong in that last step you should be all set to power on the
workstation and proceed with the guide.  If the DHCP server isn't firing up for
whatever reason, try running 'dhcpd' on the command line and see what it tells
you -- if all is well, it should just fork into the background, otherwise you'll
see 'exiting.' just below its complaint.
</p>

<p>
An easy way to verify if the tftp daemon is running is to type the following
command -- if you see something like the output mentioned below -- everything is
fine.
</p>

<pre caption="Checking TFTPd is running">
# <i>netstat -al | grep ^udp</i>
udp        0      0 *:bootpc                *:*
udp        0      0 *:631                   *:*
udp        0      0 *:xdmcp                 *:*
udp        0      0 *:tftp                  *:* <comment>&lt;-- (look for this line)</comment>
</pre>

</body>
</subsection>
<subsection>
<title>Netbooting the SGI machine</title>
<body>

<p>
Okay, everything is set, DHCP is running as is TFTP.  Now it is time to fire up
the SGI machine.  Power the unit on -- when you see "Running power-on
diagnostics" on the screen, either click "Stop For Maintenance" or press ESCAPE.
You'll be presented with a menu like the following.  Enter the commands as shown
below.
</p>

<pre caption="SGI PROM Maintenance Menu">
        Running power-on diagnostics

System Maintenance Menu

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? <i>5</i>
Command Monitor. Type "exit" to return to the menu.
&gt;&gt; <i>bootp(): root=/dev/ram0</i>
</pre>

<p>
>From this point, the machine should start downloading the image, then, roughly
20 seconds later, start booting Linux.  If all is well, you should be dropped at
the Busybox <c>ash</c> shell as shown below, where you can
move on to <uri link="?part=1&amp;chap=3">Configuring Your Network</uri>.
</p>

<pre caption="When things are going right...">
init started:  BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL

 Gentoo/MIPS Netboot for Silicon Graphics Machines
 Build Date: April 26th, 2004

 * To configure networking, do the following:

 * For Static IP:
 * /bin/net-setup &lt;IP Address&gt; &lt;Gateway Address&gt; [telnet]

 * For Dynamic IP:
 * /bin/net-setup dhcp [telnet]

 * If you would like a telnetd daemon loaded as well, pass "telnet"
 * As the final argument to /bin/net-setup.

Please press Enter to activate this console.
</pre>

</body>
</subsection>
<subsection>
<title>Troubleshooting.</title>
<body>

<p>
If the machine is being stubborn and refusing to download its image, it can be
one of two things, (1) you've made a blunder somewhere, or (2) it needs a little
gentle persuasion. (No, put that sledge hammer down!)  Here's a list of things
you can check:
</p>

<ul>
  <li>
    dhcpd is giving the SGI Machine an IP Address.  You should see some
    messages about a BOOTP request in the system logs.  <c>tcpdump</c> is also
    useful here.
  </li>
  <li>
    Permissions are set properly in your tftp folder (typically 
    <path>/tftpboot</path> -- should be world readable)
  </li>
  <li>
    Check system logs to see what the tftp server is reporting (errors
    perhaps)
  </li>
<!--
  I really think this tip can go...
  
  <li>
    Pray to a Tux plushie (this may or may not work, and is not an officially
    supported troubleshooting technique)
  </li>-->
</ul>

<p>
If you've checked everything on the server, and you're getting timeouts, etc on
the SGI machine, try typing this into the console.
</p>

<pre caption="Coaxing the SGI PROM to work">
&gt;&gt; <i>resetenv</i>
&gt;&gt; <i>unsetenv netaddr</i>
&gt;&gt; <i>unsetenv dlserver</i>
&gt;&gt; <i>init</i>
&gt;&gt; <i>bootp(): root=/dev/ram0</i>
</pre>

</body>
</subsection>
</section>

<section>
<title>Netbooting on Cobalt Servers</title>
<subsection>
<body>

</body>
</subsection>

<subsection>
<title>Overview of the netboot procedure</title>
<body>

<p>
Unlike the SGI machines, Cobalt servers use NFS to transfer their kernel for
booting.  You boot the machine by holding down the left &amp; right arrow
buttons whilst powering the unit on.  The machine will then attempt to obtain an
IP number via BOOTP, mount the <path>/nfsroot</path> directory from the server via
NFS, then try to download and boot the file <path>vmlinux_raq-2800.gz</path>
which it assumes to be a standard ELF binary.
</p>

<p>
Unfortunately, the Cobalt BOOTROM does not give us any say in this procedure,
so the file HAS to reside in <path>/nfsroot</path> directory, and must be less
than 675kB in size.  In this guide, we'll set up 
<uri link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> to allow us to
boot larger kernels than this limit.  CoLo also supports embedded ramdisks,
therefore ridding the need of a full root filesystem sitting in
<path>/nfsroot</path>.
</p>

</body>
</subsection>

<subsection>
<title>Downloading a Netboot image</title>
<body>

<p>
Inside
<uri link="http://dev.gentoo.org/~kumba/mips/cobalt/netboot/">
http://dev.gentoo.org/~kumba/mips/cobalt/netboot/</uri>
you'll find the necessary boot images for getting a Cobalt up
and running.  The files you need will have the name
<path>cobalt-netboot-YYYYMMDD.img.gz</path> -- select the most recent one and
place it in your <path>/nfsroot</path> directory.  For convenience, rename the
file to <path>gentoo-cobalt.img.gz</path> -- I'll assume that you have done
this.
</p>

<p>
Once that is done, head over to
<uri link="http://www.colonel-panic.org/cobalt-mips/">
http://www.colonel-panic.org/cobalt-mips/</uri> and
download the latest release of the CoLo bootloader.  Untar this somewhere
convenient.  Inside the <path>colo-1.XX/binaries</path> directory created,
you should find under a file named <path>colo-chain.elf</path>.  Gzip this
file up and place it in <path>/nfsroot</path> calling it
<path>vmlinux_raq-2800.gz</path>. Also, in some cases, you will need to create a
symbolic link called <path>boot</path> that points back to
<path>/nfsroot</path>. You can do this in one hit using these commands:
</p>

<note>
Please note, the RaQ1 and Qube 2700 look for <path>vmlinux.gz</path> rather than
<path>vmlinux_raq-2800.gz</path>.
</note>

<pre caption="Putting CoLo in the nfsroot">
# <i>tar -xzvf colo-1.XX.tar.gz</i>
# <i>cd colo-1.XX/binaries</i>

<comment>(For Qube 2800, RaQ2, etc)</comment>
# <i>gzip -9vc colo-chain.elf &gt; /nfsroot/vmlinux_raq-2800.gz</i>

<comment>(For RaQ1, Qube 2700)</comment>
# <i>gzip -9vc colo-chain.elf &gt; /nfsroot/vmlinux.gz</i>
# <i>cd /nfsroot</i>
# <i>ln . boot</i>
</pre>

<note>
If the latest CoLo release fails to boot, you may wish to try an earlier
release. Version 1.16 and earlier are known to work.
</note>

</body>
</subsection>

<subsection>
<title>NFS Server configuration</title>
<body>

<p>
Since this machine uses NFS to download its image, you need to export
<path>/nfsroot</path> on your server.  If you have not already done so, you'll
need to install the net-fs/nfs-utils package.
</p>
<pre caption="Installing nfs-utils">
# <i>emerge net-fs/nfs-utils</i>
</pre>

<p>
Once that is done, place the following in your <path>/etc/exports</path> file.
You may set tighter restrictions if you wish.
</p>

<pre caption="Exporting the /nfsroot directory">
/nfsroot      *(ro,sync)
</pre>

<p>
Now, once that is done, you may start the NFS server:
</p>

<pre caption="Starting the NFS server">
# <i>/etc/init.d/nfs start</i>
</pre>

<p>
If the NFS server was already running at the time, you can tell it to take
another look at its <c>exports</c> file using <c>exportfs</c>.
</p>

<pre caption="Exporting a new filesystem">
# <i>exportfs -av</i>
</pre>

</body>
</subsection>

<subsection>
<title>DHCP Configuration for a Cobalt machine</title>
<body>

<p>
Now, the DHCP side of things is relatively straightforward.  Add the following
to your <path>/etc/dhcp/dhcpd.conf</path> file.
</p>

<pre caption="dhcpd.conf snippet for Cobalt server">
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
  <comment># ... usual stuff here ...</comment>

  <comment># Configuration for a Cobalt Server</comment>
  <comment># Set the hostname here:</comment>
  host <i>qube</i> {
    <comment># Path to the nfsroot directory.</comment>
    <comment># This is mainly for when using the TFTP boot option on CoLo</comment>
    option root-path "/nfsroot";

    <comment># Cobalt server's ethernet MAC address</comment>
    hardware ethernet <i>00:10:e0:00:86:3d</i>;

    <comment># Server to download image from</comment>
    next-server <i>192.168.10.1</i>;

    <comment># IP address of cobalt server</comment>
    fixed-address <i>192.168.10.2</i>;

    <comment># Image to download</comment>
    <comment># Again, this has more to do with CoLo</comment>
    filename "<i>gentoo-cobalt.img.gz</i>";
  }
}
</pre>

</body>
</subsection>

<subsection>
<title>Start Your Daemons...</title>
<body>

<p>
At this point, you should be ready to start the daemons.  Enter the following:
</p>

<pre caption="Starting the DHCP and NFS daemons">
# <i>/etc/init.d/dhcp start</i>
# <i>/etc/init.d/nfs start</i>
</pre>

<p>
If nothing went wrong in that last step you should be all set to power on the
workstation and proceed with the guide.  If the DHCP server isn't firing up for
whatever reason, try running 'dhcpd' on the command line and see what it tells
you -- if all is well, it should just fork into the background, otherwise you'll
see 'exiting.' just below its complaint.
</p>

</body>
</subsection>

<subsection>
<title>Netbooting the Cobalt machine</title>
<body>

<p>
Okay, everything is set, DHCP is running as is NFS.  Now it is time to fire up
the Cobalt machine.  Hook up your null modem cable, and set the serial terminal
to use 115200 baud, 8 bits, no parity, 1 stop bit, VT100 emulation.  Once that
is done, hold down the left &amp; right arrow buttons whilst powering the unit
on.
</p>

<p>
If all is well, the back panel should display "Net Booting", you should
see some network activity, closely followed by CoLo kicking in.  On the rear
panel, scroll down the menu until you see "Boot Shell" then press ENTER.  On the
serial console, you should be dropped to a prompt as shown below.
</p>

<note>
It has been reported that simply selecting the NFS boot option does all of this
for you under modern versions of CoLo. If selecting this option does not work,
then read on.
</note>

<pre caption="CoLo booting to a prompt">
[ "CoLo" v1.13 ]
stage2: 87fb0000-88000000
pci: unit type &lt;Qube2&gt;
tulip: {00:10:e0:00:86:3d}
ide: resetting
boot: running boot menu
&gt;
</pre>

<p>
First step, tell the machine to fetch an address via DHCP.  Type <c>dhcp</c> at
the prompt.
</p>

<pre caption="Fetching an address via DHCP">
&gt; <i>dhcp</i>
net: interface up
dhcp: DISCOVER
dhcp: OFFER 10.0.0.1 &lt;-- 192.168.10.254
dhcp: REQUEST
arp: sent request for 192.168.10.254
udp: no matching socket 192.168.5.1:67 --&gt; 10.0.0.1:68
arp: resolved 192.168.10.254
udp: no matching socket 192.168.5.1:67 --&gt; 10.0.0.1:68
dhcp: DISCOVER
dhcp: OFFER 10.0.0.1 &lt;-- 192.168.10.254
dhcp: REQUEST
udp: no matching socket 192.168.5.1:67 --&gt; 10.0.0.1:68
dhcp: ACK
net: interface down
net: interface up
  address     10.0.0.1
  netmask     255.255.255.0
  gateway     10.0.0.254
  name server 192.168.5.1
</pre>

<p>
NOTE: If you have a Windows network you may see messages along the lines of
<c>udp: no matching socket</c>.  These are in response to network broadcasts on
ports that CoLo doesn't recognise.  As annoying as they are, they are perfectly
harmless.
</p>

<pre caption="'no matching socket' error messages">
udp: no matching socket 10.0.0.254:138 --&gt; 10.0.0.255:138
udp: no matching socket 10.0.0.254:138 --&gt; 10.0.0.255:138
udp: no matching socket 10.0.0.253:1062 --&gt; 10.0.0.255:137
udp: no matching socket 10.0.0.253:1062 --&gt; 10.0.0.255:137
</pre>

<p>
Okay, the next step is to tell the Cobalt server to download its kernel.
</p>

<pre caption="Downloading the kernel">
&gt; <i>nfs 10.0.0.254 /nfsroot gentoo.img.gz</i>
arp: sent request for 10.0.0.254
arp: resolved 10.0.0.254
udp: no matching socket 10.0.0.253:1062 --&gt; 10.0.0.255:137
nfs: mounted "/nfsroot"
nfs: lookup "gentoo.img.gz"
nfs: mode &lt;0100644&gt;
4651KB loaded (1240KB/sec)
0048ada0 4763040t
</pre>

<p>
And that's it... it has now downloaded its kernel, we now can tell it to start
booting.
</p>

<pre caption="Booting the kernel">
&gt; <i>execute</i>
elf: 80080000 &lt;-- 00001000 6586368t + 192624t
elf: entry 80328040
net: interface down
CPU revision is: 000028a0
FPU revision is: 000028a0
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB 2-way, linesize 32 bytes.
Linux version 2.4.26-mipscvs-20040415 (root@khazad-dum) (gcc version 3.3.3...
Determined physical RAM map:
 memory: 08000000 @ 00000000 (usable)
Initial ramdisk at: 0x80392000 (3366912 bytes)
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,115200 root=/dev/ram0
Calibrating delay loop... 249.85 BogoMIPS
Memory: 122512k/131072k available (2708k kernel code, 8560k reserved, 3424k dat)
</pre>

<p>
If all is well, you should be dropped at
the Busybox <c>ash</c> shell as shown below, where you can go onto
<uri link="?part=1&amp;chap=3">Configuring Your Network</uri>.
</p>

<pre caption="When things are going right...">
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 280k freed
init started:  BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL

 Gentoo/MIPS Netboot for Cobalt Microserver Machines
 Build Date: April 26th, 2004

 * To configure networking, do the following:

 * For Static IP:
 * /bin/net-setup &lt;IP Address&gt; &lt;Gateway Address&gt; [telnet]

 * For Dynamic IP:
 * /bin/net-setup dhcp [telnet]

 * If you would like a telnetd daemon loaded as well, pass "telnet"
 * As the final argument to /bin/net-setup.

Please press Enter to activate this console.
</pre>

</body>
</subsection>

<subsection>
<title>Troubleshooting.</title>
<body>

<p>
If the machine is being stubborn and refusing to download its image, it can be
one of two things, (1) you've made a blunder somewhere, or (2) it needs a little
gentle persuasion. (No, put that sledge hammer down!)  Here's a list of things
you can check:
</p>

<ul>
  <li>
    dhcpd is giving the Cobalt Machine an IP Address.  You should see some
    messages about a BOOTP request in the system logs.  <c>tcpdump</c> is also
    useful here.
  </li>
  <li>
    Permissions are set properly in your <path>/nfsroot</path> folder.  (should
    be world readable)
  </li>
  <li>
    Make sure the NFS server is running and exporting the <path>/nfsroot</path>
    directory.  Check this using <c>exportfs -v</c> on the server.
  </li>
</ul>
</body>
</subsection>
</section>
<!--

  Commented Out Until Further Notice

<section>
<title>Gentoo/MIPS LiveCD</title>
<subsection>
<title>Overview</title>
<body>

<p>
On Silicon Graphics machines, it is possible to boot from a CD in order to
install operating systems.  (This is how one installs IRIX for instance)
Recently, images for such bootable CDs to install Gentoo have been made
possible.  These CDs are designed to work in the same way.
</p>

<p>
At the moment the Gentoo/MIPS Live CD will only work on the SGI Indy,
Indigo 2 and O2 workstations equipped with R4000 and R5000-series CPUs, however
other platforms may be possible in future.
</p>

<p>
You can find the Live CD images for download on your favourite Gentoo Mirror
under the <path>experimental/mips/livecd</path> directory.
</p>

<warn>
These CDs are highly experimental at this time.  They may or may not work at
this time.  You can report success or failures either on
<uri link="http://bugs.gentoo.org">Bugzilla</uri>,
<uri link="http://forums.gentoo.org/viewtopic.php?t=242518">this forum
thread</uri> or in the <c>#gentoo-mips</c>
<uri link="http://www.gentoo.org/main/en/irc.xml">IRC channel</uri>.  We would
love to hear from you.
</warn>

</body>

</subsection>

<subsection>
<title>Burning a Live CD</title>
<body>

<p>
An important thing to note, the SGI PROM does not understand the ISO9660 format,
nor does it know anything about the El Torito boot standard.  These CD images
are constructed as a SGI disklabel with the boot image in the volume header like
a hard drive.  Therefore, care must be taken when burning the CD image.
</p>

<p>
Below is an example command that assumes 24x burning speed on an IDE burner.  If
you have a SCSI burner for instance, you may want to adjust the <c>dev</c>
statement as appropriate.  Likewise with the <c>speed</c> option - if you
strike troubles, you might want to try dropping the speed.
</p>

<pre caption="Burning using cdrecord">
# <i>bzip2 -d mips-livecd-prototype-rc2-20041027.img.bz2</i>
# <i>cdrecord -vv -pad speed=24 dev=ATAPI:0,0,0 -tao mips-livecd-prototype-rc2-20041027.img</i>
</pre>

<note>
It may be possible to burn these CDs under Windows, assuming your burning
program just blindly burns the image as is.  However, no one has succeeded in
making a working CD this way to date.
</note>

<note>
If you don't know what to put as your <c>dev</c> argument, run <c>cdrecord
-scanbus</c> as root - this will tell you where your burner is located.
</note>

</body>
</subsection>
</section>
-->
</sections>



1.1                  xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-stage.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-stage.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-stage.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: hb-install-mips-stage.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/2006.0/hb-install-mips-stage.xml,v 1.1 2006/02/12 13:54:32 nightmorph Exp $ -->

<sections>

<version>2.5</version>
<date>2005-11-22</date>

<section>
<title>Installing a Stage Tarball</title>
<subsection>
<title>Setting the Date/Time Right</title>
<body>

<p>
Before you continue you need to check your date/time and update it. A
misconfigured clock may lead to strange results in the future!
</p>

<p>
To verify the current date/time, run <c>date</c>:
</p>

<pre caption="Verifying the date/time">
# <i>date</i>
Fri Mar 29 16:21:18 CEST 2005
</pre>

<p>
If the date/time displayed is wrong, update it using the <c>date
MMDDhhmmYYYY</c> syntax (<b>M</b>onth, <b>D</b>ay, <b>h</b>our, <b>m</b>inute
and <b>Y</b>ear). For instance, to set the date to March 29th, 16:21 in the
year 2005:
</p>

<pre caption="Setting the date/time">
# <i>date 032916212005</i>
</pre>

</body>
</subsection>
<subsection>
<title>Making your Choice</title>
<body>

<p>
The next step you need to perform is to install the <e>stage</e> tarball of
your choice onto your system. 
<!--You have the option of downloading the required
tarball from the Internet or, if you are booted from one of the Gentoo
Universal Installation CDs, copy it over from the CD itself. If you have a 
Universal CD and the stage you want to use is on the CD, downloading it from 
the Internet is just a waste of bandwidth as the stage files are the same. In 
most cases, the command <c>uname -m</c> can be used to help you decide which 
stage file to download. -->
</p>

<!--
<ul>
<li><uri link="#doc_chap2">Default: Using a Stage from the Internet</uri></li>
<li>
  <uri link="#doc_chap3">Alternative: Using a Stage from the Installation CD</uri>
</li>
</ul>-->

</body>
</subsection>
</section>
<section>
<title>Using a Stage from the Internet</title>
<subsection>
<title>Downloading the Stage Tarball</title>
<body>

<p>
Go to the Gentoo mountpoint at which you mounted your filesystems
(most likely <path>/gentoo</path>):
</p>

<pre caption="Going to the Gentoo mountpoint">
# <i>cd /gentoo</i>
</pre>

<p>
The table below specifies exactly which stages you need for your system.
Stages may be downloaded
off the <uri link="/main/en/mirrors.xml">official Gentoo mirrors</uri> under the
<c>releases/mips/current</c> directory.
</p>

<table>
<tr>
  <th>Endianness</th>
  <th>CPU</th>
  <th>Location</th>
</tr>
<tr>
  <ti>
    Big Endian<br />
    <e>(SGI Users)</e>
  </ti>
  <ti>
    R4000<br />
    R4400<br />
    R4600
  </ti>
  <ti><c>mips3/stage#-mips3-RELEASE.tar.bz2</c></ti>
</tr>
<tr>
  <ti>
    Big Endian<br />
    <e>(SGI Users)</e>
  </ti>
  <ti>
    R5000<br />
    RM5200<br />
    RM7000<br />
    R10000<br />
    R12000<br />
    R14000
  </ti>
  <ti><c>mips4/stage#-mips4-RELEASE.tar.bz2</c></ti>
</tr>
<tr>
  <ti>
    Little Endian<br />
    <e>(Cobalt Users)</e>
  </ti>
  <ti>
    RM5230<br />
    RM5231
  </ti>
  <ti><c>cobalt/stage#-mipsel4-RELEASE.tar.bz2</c></ti>
</tr>
</table>

<p>
If you need to go through a proxy, export the <c>http_proxy</c> and
<c>ftp_proxy</c> variables:
</p>

<pre caption="Setting proxy information for wget">
# <i>export http_proxy="http://proxy.server.com:port"</i>
# <i>export ftp_proxy="http://proxy.server.com:port"</i>
</pre>

<p>
The Gentoo/MIPS netboot images provide <c>wget</c> as a means of downloading
files.  Due to space constraints, it is not possible to provide more capable
browsers on SGI netboot images. LiveCD users may use <c>elinks</c>.
</p>

<pre caption="Fetching the tarball via wget">
# <i>wget -c http://distfiles.gentoo.org/releases/mips/mips4/stage3-mips4-2005.1.tar.bz2</i>
</pre>

<p>
If you want to check the integrity of the downloaded stage tarball, use
<c>md5sum</c> and compare the output with the MD5 checksum provided on the
mirror. For instance, to check the validity of the mips4 stage tarball:
</p>

<pre caption="Example checking integrity of a stage tarball">
# <i>md5sum -c stage3-mips4-2005.1.tar.bz2.md5</i>
stage3-mips4-2005.1.tar.bz2: OK
</pre>

</body>
</subsection>
<subsection>
<title>Unpacking the Stage Tarball</title>
<body>

<p>
Now unpack your downloaded stage onto your system. We use GNU's <c>tar</c> to
proceed as it is the easiest method:
</p>

<pre caption="Unpacking the stage">
# <i>tar -xjpf stage?-*.tar.bz2</i>
</pre>

<p>
Make sure that you use the same options (<c>-xjpf</c>). The <c>x</c> stands for
<e>Extract</e>, the <c>j</c> for <e>Decompress with bzip2</e>, the <c>p</c> for
<e>Preserve permissions</e> and the <c>f</c> to denote that we want to extract
a file, not standard input.
</p>

<p>
Now that the stage is installed, continue with <uri
link="#installing_portage">Installing Portage</uri>.
</p>

</body>
</subsection>
</section>
<!--
<section>
<title>Alternative: Using a Stage from the Installation CD</title>
<subsection>
<title>Extracting the Stage Tarball</title>
<body>

<p>
The stages on the CD reside in the <path>/mnt/cdrom/stages</path> directory. To
see a listing of available stages, use <c>ls</c>:
</p>

<pre caption="List all available stages">
# <i>ls /mnt/cdrom/stages</i>
</pre>

<p>
If the system replies with an error, you may need to mount the CD-ROM first:
</p>

<pre caption="Mounting the CD-ROM">
# <i>ls /mnt/cdrom/stages</i>
ls: /mnt/cdrom/stages: No such file or directory
# <i>mount /dev/cdroms/cdrom0 /mnt/cdrom</i>
# <i>ls /mnt/cdrom/stages</i>
</pre>

<p>
Now go into your Gentoo mountpoint (usually <path>/mnt/gentoo</path>):
</p>

<pre caption="Changing directory to /mnt/gentoo">
# <i>cd /mnt/gentoo</i>
</pre>

<p>
We will now extract the stage tarball of your choice. We will do this with the
GNU <c>tar</c> tool. Make sure you use the same options (<c>-xvjpf</c>)! Again,
the <c>v</c> argument is optional and not supported in some <c>tar</c> versions.
In the next example, we extract the stage tarball 
<path>stage3-&lt;subarch&gt;-2005.1.tar.bz2</path>.
Be sure to substitute the tarball filename with your stage.
</p>

<pre caption="Extracting the stage tarball">
# <i>tar -xvjpf /mnt/cdrom/stages/stage3-&lt;subarch&gt;-2005.1.tar.bz2</i>
</pre>

<!- - 2005.1: stage3 for athlon xp, pentium3 and pentium4 are b0rked - ->
<warn>
The <path>stage3-athlon-xp-2005.1.tar.bz2</path>,
<path>stage3-pentium3-2005.1.tar.bz2</path> and
<path>stage3-pentium4-2005.1.tar.bz2</path> files have a serious permission
error. After extracting any of these, run <c>chmod 0755 /mnt/gentoo</c> to fix
the error <e>before</e> continuing with the installation.
</warn>

<p>
Now that the stage is installed, continue with <uri
link="#installing_portage">Installing Portage</uri>.
</p>

</body>
</subsection>
</section>-->
<section id="installing_portage">
<title>Installing Portage</title>
<subsection>
<title>Unpacking a Portage Snapshot</title>
<body>

<p>
You now have to install a Portage snapshot, a collection of files that inform
Portage what software titles you can install, which profiles are available, etc.
</p>

</body>
</subsection>
<subsection id="installing_from_Internet">
<title>Download and Install a Portage Snapshot</title>
<body>

<p>
Go to the mountpoint where you mounted your filesystem (most likely
<path>/gentoo</path>):
</p>

<pre caption="Going to the Gentoo mountpoint">
# <i>cd /gentoo</i>
</pre>

<p>
Download a portage snapshot from a <uri
link="/main/en/mirrors.xml">local mirror</uri>.
You'll find them in the <path>snapshots/</path> directory.  Transfer it to the
target system in the same manner that you did for the stage tarball.
</p>

<pre caption="Extracting the Portage snapshot">
# <i>tar -xjf portage-*.tar.bz2 -C /gentoo/usr</i>
</pre>

</body>
</subsection>
</section>

<section id="compile_options">
<title>Configuring the Compile Options</title>
<subsection>
<title>Introduction</title>
<body>

<p>
To optimize Gentoo, you can set a couple of variables which impact Portage 
behaviour. All those variables can be set as environment variables (using
<c>export</c>) but that isn't permanent. To keep your settings, Portage provides
you with <path>/etc/make.conf</path>, a configuration file for Portage. It is
this file we will edit now. 
</p>

<note>
A commented listing of all possible variables can be found in
<path>/gentoo/etc/make.conf.example</path>. For a successful Gentoo 
installation you'll only need to set the variables which are mentioned beneath.
</note>

<p>
Fire up a text editor so we can alter the optimization variables we will discuss
hereafter.  Two editors are provided, <c>vi</c> (part of Busybox) and
<c>nano</c>.  We will assume you're using <c>nano</c>.
</p>

<pre caption="Opening /etc/make.conf">
# <i>nano -w /gentoo/etc/make.conf</i>
</pre>

<p>
As you probably noticed, the <path>make.conf.example</path> file is
structured in a generic way: commented lines start with "#", other lines define
variables using the <c>VARIABLE="content"</c> syntax. The <path>make.conf</path>
file uses the same syntax. Several of those variables are discussed next. 
</p>

</body>
</subsection>
<!--<subsection>
<title>CHOST</title>
<body>

<warn>
Although it might be tempting for non-stage1 users, they should <e>not</e>
change the <c>CHOST</c> setting in <path>make.conf</path>. Doing so might render
their system unusable. Again: only change this variable if you use a
<e>stage1</e> installation.
</warn>

<p>
The <c>CHOST</c> variable defines what architecture <c>gcc</c> has to
compile programs for, as well as the <c>libc</c> (<c>glibc</c> or <c>µClibc</c>) used
for linking.
</p>

<table>
<tr>
  <th>Endianness</th>
  <th>Userland/ABI</th>
  <th>CHOST Setting</th>
</tr>
<tr>
  <ti>Big Endian <e>(SGI Users)</e></ti>
  <ti><c>glibc</c> <c>o32</c></ti>
  <ti>mips-unknown-linux-gnu</ti>
</tr>
<tr>
  <ti>Big Endian <e>(SGI Users)</e></ti>
  <ti><c>µClibc</c> <c>o32</c></ti>
  <ti>mips-unknown-linux-uclibc (1)</ti>
</tr>
<tr>
  <ti>Big Endian <e>(SGI Users)</e></ti>
  <ti><c>glibc</c> <c>n32</c> &amp; <c>n64</c></ti>
  <ti>mips64-unknown-linux-gnu (2)</ti>
</tr>
<tr>
  <ti>Little Endian <e>(Cobalt Users)</e></ti>
  <ti><c>glibc</c> <c>o32</c></ti>
  <ti>mipsel-unknown-linux-gnu</ti>
</tr>
<tr>
  <ti>Little Endian <e>(Cobalt Users)</e></ti>
  <ti><c>µClibc</c> <c>o32</c></ti>
  <ti>mipsel-unknown-linux-uclibc (1)</ti>
</tr>
<tr>
  <ti>Little Endian <e>(Cobalt Users)</e></ti>
  <ti><c>glibc</c> <c>n32</c> &amp; <c>n64</c></ti>
  <ti>mips64el-unknown-linux-gnu (2)</ti>
</tr>
</table>

<warn>
(1) µClibc stages are the realm of the
<uri link="/proj/en/base/embedded/">Gentoo Embedded</uri>
team, and are therefore not officially supported by the
Gentoo/MIPS team.  This <c>CHOST</c> setting is only mentioned here for
completeness.
</warn>

<warn>
(2) Currently we do not provide <c>n64</c> stages, and only provide <c>n32</c>
stages on the Big Endian MIPS4 architecture.  These are highly experimental
stages and are known to be totally broken in places.  Users are thus 
<e>highly</e> recommended to avoid these like the plague.
The only reason one would need the <c>mips64(el)</c> <c>CHOST</c>, is to use a
64-bit (<c>n32</c> or <c>n64</c>) userland.  This <c>CHOST</c> setting is only
mentioned here for completeness.
</warn>

</body>
</subsection>-->
<subsection>
<title>CFLAGS and CXXFLAGS</title>
<body>

<p>
The <c>CFLAGS</c> and <c>CXXFLAGS</c> variables define the optimization flags 
for the <c>gcc</c> C and C++ compiler respectively. Although we define those
generally here, you will only have maximum performance if you optimize these
flags for each program separately. The reason for this is because every program
is different.
</p>

<p>
In <path>make.conf</path> you should define the optimization flags you think
will make your system the most responsive <e>generally</e>. Don't place
experimental settings in this variable; too much optimization can make 
programs behave bad (crash, or even worse, malfunction).
</p>

<p>
We will not explain all possible optimization options. If you want to know
them all, read the <uri link="http://gcc.gnu.org/onlinedocs/">GNU
Online Manual(s)</uri> or the <c>gcc</c> info page (<c>info gcc</c> -- only
works on a working Linux system). The <path>make.conf.example</path> file 
itself also contains lots of examples and information; don't forget to read it 
too. 
</p>

<p>
A first setting is the <c>-march=</c> flag, which specifies the name of the
target architecture. Possible options are described in the
<path>make.conf.example</path> file (as comments).  Examples include ISA levels
(<c>mips1</c> ... <c>mips4</c>) and CPU models (<c>r4400</c>, <c>r4600</c> ...
etc).  For pure ISA level architectures, one can simply specify <c>-mips3</c>
rather than <c>-march=mips3</c>.
</p>

<pre caption="The GCC -march and -mips# settings">
<comment>(For an R4600 system...)</comment>
-march=r4600

<comment>(Any MIPS4-class CPU...)</comment>
-march=mips4

<comment>(Or just specify the ISA level directly...)</comment>
-mips4
</pre>

<p>
A second one is the <c>-O</c> flag (that is a capital O, not a zero),
which specifies the <c>gcc</c> optimization
class flag. Possible classes are <c>s</c> (for size-optimized),
<c>0</c> (zero - for no optimizations), <c>1</c>, <c>2</c> or <c>3</c> for more
speed-optimization flags (every class has the same flags as the one before, plus
some extras). For instance, for a class-2 optimization:
</p>

<pre caption="The GCC O setting">
-O2
</pre>

<p>
A very important setting in the MIPS world, is the <c>-mabi=</c> flag.  MIPS has
3 different ABIs; <c>32</c> (pure 32-bit, aka <c>o32</c>), <c>64</c> (full
64-bit, aka <c>n64</c>) and <c>n32</c>
(a mix of 32-bit data structures with 64-bit instructions).  This
flag selects which of these you wish to use.  Note you need libraries for the
ABI you select.  In layman's terms, this means, for example, you can't use
<c>-mabi=64</c> on a 32-bit userland (or even a <c>n32</c> userland).
</p>

<p>
Another popular optimization flag is <c>-pipe</c> (use pipes rather than
temporary files for communication between the various stages of compilation).
</p>

<p>
Mind you that using <c>-fomit-frame-pointer</c> (which doesn't keep the frame 
pointer in a register for functions that don't need one) might have serious
repercussions on the debugging of applications!
</p>

<p>
When you define the <c>CFLAGS</c> and <c>CXXFLAGS</c>, you should combine
several optimization flags, like in the following example:
</p>

<pre caption="Defining the CFLAGS and CXXFLAGS variable">
CFLAGS="-mabi=32 -mips4 -pipe -O2"
CXXFLAGS="${CFLAGS}"                  <comment># Use the same settings for both variables</comment>
</pre>

</body>
</subsection>
<subsection>
<title>MAKEOPTS</title>
<body>

<p>
With <c>MAKEOPTS</c> you define how many parallel compilations should occur when
you install a package. A good choice is the number of CPUs in your system plus 
one, but this guideline isn't always perfect.
</p>

<pre caption="MAKEOPTS for a regular, 1-CPU system">
MAKEOPTS="-j2"
</pre>

</body>
</subsection>
<subsection>
<title>Ready, Set, Go!</title>
<body>

<p>
Update your <path>/gentoo/etc/make.conf</path> to your own preference and
save (<c>nano</c> users would hit <c>Ctrl-X</c>). You are now ready to continue
with <uri link="?part=1&amp;chap=6">Installing the Gentoo Base System</uri>.
</p>

</body>
</subsection>
</section>
</sections>



-- 
gentoo-doc-cvs@g.o mailing list