/[gentoo]/xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml
Gentoo

Contents of /xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.16 - (hide annotations) (download) (as text)
Wed Aug 30 22:52:28 2006 UTC (7 years, 7 months ago) by nightmorph
Branch: MAIN
Changes since 1.15: +35 -19 lines
File MIME type: application/xml
2006.1 networked docs are in. portage handbook still untouched per separate bugs. thanks to all the hard work, guys. blame me if something is wrong (and please fix quickly) :)

1 swift 1.1 <?xml version='1.0' encoding='UTF-8'?>
2     <!DOCTYPE sections SYSTEM "/dtd/book.dtd">
3    
4     <!-- The content of this document is licensed under the CC-BY-SA license -->
5 neysx 1.14 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
6 swift 1.1
7 nightmorph 1.16 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml,v 1.15 2006/06/12 10:18:17 neysx Exp $ -->
8 swift 1.1
9     <sections>
10 swift 1.6
11 nightmorph 1.16 <version>7.0</version>
12     <date>2006-08-30</date>
13 swift 1.6
14 swift 1.10 <section id="sgi">
15 nightmorph 1.16 <title>Silicon Graphics Machines -- Setting Up arcload</title>
16 fox2mike 1.13 <subsection>
17     <title>Which one?</title>
18     <body>
19    
20     <p>
21 nightmorph 1.16 On SGI machines, we use the <c>arcload</c> boot loader. In previous releases,
22     we also provided <c>arcboot</c>, however it has been officially declared
23     obsolete, in favour of <c>arcload</c>.
24 fox2mike 1.13 </p>
25    
26 nightmorph 1.16 <!-- Slated for possible removal
27 fox2mike 1.13 <table>
28     <tr>
29     <th> </th>
30     <th>arcboot</th>
31     </tr>
32     <tr>
33     <th>+</th>
34     <ti>
35     It can load off EXT2 and EXT3 partitions, so no need to store them in the
36     volume header
37     </ti>
38     </tr>
39     <tr>
40     <th>-</th>
41     <ti>
42 neysx 1.15 It doesn't work on Octane/Octane2, Origin 200/2000 or Indigo2 Impact
43     (R10000)
44 fox2mike 1.13 </ti>
45     </tr>
46     </table>
47    
48     <table>
49     <tr>
50     <th> </th>
51     <th>arcload</th>
52     </tr>
53     <tr>
54     <th>+</th>
55     <ti>
56 neysx 1.15 It boots ALL Linux-compatible SGI systems
57 fox2mike 1.13 </ti>
58     </tr>
59     <tr>
60     <th>-</th>
61     <ti>
62     Currently, It cannot read EXT2/EXT3 partitions, and so needs the kernels
63     and config file to be placed in the volume header
64     </ti>
65     </tr>
66     </table>
67 nightmorph 1.16 -->
68 fox2mike 1.13
69     <note>
70 neysx 1.15 The SGI volume header filenames are limited to 8 characters, and there may be
71     no more than 16 files contained in a single volume header.
72 fox2mike 1.13 </note>
73    
74     </body>
75     </subsection>
76    
77 nightmorph 1.16 <!--<subsection>
78 swift 1.10 <title>Installing arcboot</title>
79 swift 1.1 <body>
80    
81 nightmorph 1.16 <warn>
82     <c>arcboot</c> is deprecated and will be removed in future.
83     </warn>
84    
85 swift 1.1 <p>
86 swift 1.10 Previously in this guide, we showed you how to make a kernel, then copy it to
87 neysx 1.15 the volume header using <c>dvhtool</c>. There were two main flaws with this
88 swift 1.10 system:
89 swift 1.1 </p>
90    
91 swift 1.10 <ul>
92     <li>This is not supported on all SGI systems</li>
93     <li>It requires a significantly larger volume header</li>
94     </ul>
95    
96 swift 1.1 <p>
97 swift 1.10 In order to boot the machine, a bootloader, <c>arcboot</c> was developed for
98 neysx 1.15 this purpose. Instead of putting the kernel directly into the volume header, we
99 swift 1.10 leave it in <path>/boot</path> (which resides on a EXT2/3 partition), and tell
100 neysx 1.15 <c>arcboot</c> (which sits in the volume header in place of the kernel) where
101     to find it. So our first step, is to emerge some tools that we'll use later...
102 swift 1.1 </p>
103    
104 swift 1.10 <pre caption="Installing the required tools">
105     # <i>emerge dvhtool arcboot</i>
106 swift 1.1 </pre>
107    
108     <p>
109 swift 1.10 That should have installed two tools, <c>arcboot</c> which sits in the volume
110     header and loads kernels for us, and <c>dvhtool</c> which helps us put
111     <c>arcboot</c> into the volume header.
112     </p>
113 fox2mike 1.13
114 swift 1.10 <p>
115 neysx 1.15 The <c>arcboot</c> binary lurks in <path>/usr/lib/arcboot</path>. The name of
116 fox2mike 1.13 the binary depends on the machine it's compiled for.
117 swift 1.1 </p>
118    
119 fox2mike 1.13 <ul>
120     <li>
121     <c>arcboot.ip22</c>: The binary for Indy, Indigo2 (R4k) and Challenge S
122     systems
123     </li>
124     <li>
125     <c>arcboot.ip32</c>: The binary for O2 systems
126     </li>
127     </ul>
128    
129 swift 1.10 <pre caption="Installing arcboot into the volume header">
130 nightmorph 1.16 # <i>dvhtool - -unix-to-vh /usr/lib/arcboot/arcboot.ip?? arcboot</i>
131 swift 1.1 </pre>
132    
133     <p>
134 swift 1.10 We then verify the presence of the file in the volume header.
135 swift 1.1 </p>
136    
137 swift 1.10 <pre caption="Checking if arcboot made it okay">
138 nightmorph 1.16 # <i>dvhtool - -print-volume-directory</i>
139     - - - - - directory entries - - - - -
140 swift 1.10 Entry #0, name "linux", start 4, bytes 3262570
141     Entry #1, name "newlinux", start 6377, bytes 7619627
142     Entry #3, name "arcboot", start 21260, bytes 51448
143     #
144     </pre>
145    
146     <note>
147 fox2mike 1.13 You'll notice that in the example above, there are two old kernels sitting
148 neysx 1.15 around, <path>linux</path> and <path>newlinux</path>. This is a hangover from
149 nightmorph 1.16 before we started using <c>arcboot</c>. Their presence doesn't matter - - just
150 fox2mike 1.13 so long as <c>arcboot</c> is present, everything is fine.
151 swift 1.10 </note>
152    
153     <p>
154     If you've ever set up the Linux Loader (<c>lilo</c>) before, you'll find that
155 neysx 1.15 <c>arcboot</c> employs a similar syntax in its configuration file. Bear in mind
156 swift 1.10 though; <c>arcboot</c> expects to find its configuration file existing on an
157 neysx 1.15 EXT2/3 partition as <path>/etc/arcboot.conf</path>. The easiest way around this
158 swift 1.10 is to make sure <path>/boot</path> is an EXT2/3 partition and that there's a
159     file called <path>arcboot.conf</path> inside the <path>/boot/etc</path>
160 neysx 1.15 directory. An example config can be found in
161 fox2mike 1.13 <path>/etc/arcboot.conf.sample</path>.
162 swift 1.10 </p>
163    
164 fox2mike 1.13 <note>
165 neysx 1.15 Adjust the paths accordingly if you don't have a separate <path>/boot</path>
166     partition.
167 fox2mike 1.13 </note>
168    
169 swift 1.10 <pre caption="Putting arcboot.conf in its place">
170     <comment>(Create the /boot/etc directory)</comment>
171     # <i>mkdir /boot/etc</i>
172    
173     <comment>(Put our configuration into the target directory)</comment>
174     # <i>cp /etc/arcboot.conf.sample /boot/etc/arcboot.conf</i>
175    
176     <comment>(Create a symlink back to /etc)</comment>
177     # <i>ln -s /boot/etc/arcboot.conf /etc/arcboot.conf</i>
178    
179     <comment>(... and a symlink in /boot pointing to itself)</comment>
180     # <i>(cd /boot; ln -s . boot)</i>
181     </pre>
182    
183     <p>
184 neysx 1.15 You can then edit <path>/etc/arcboot.conf</path> to your own preference. One
185     possible layout, is to set up two kernel images: <path>new</path>, a freshly
186     built image that may or may not work; and <path>working</path>, a proven
187     trustworthy kernel image. The <path>arcboot.conf</path> for that setup looks a
188     bit like this.
189 swift 1.10 </p>
190    
191     <pre caption="Example arcboot.conf">
192     <comment># arcboot.conf</comment>
193     <comment>#</comment>
194     <comment># copyright 2002 Guido Guenther &lt;agx@sigxcpu.org&gt;</comment>
195     <comment>#</comment>
196 fox2mike 1.13 <comment># known working version</comment>
197 swift 1.10 label=working
198     image=/vmlinux
199     append="root=/dev/sda3"
200    
201 fox2mike 1.13 <comment># fresh "untested" version</comment>
202 swift 1.10 label=new
203     image=/vmlinux-new
204     append="root=/dev/sda3"
205     </pre>
206    
207     <p>
208     Once that is set up, there's then just some little tweaks that you need to do
209 neysx 1.15 within the SGI PROM to make this magic work. This is covered in, not the next
210     section (that's for Cobalt servers) but the following section <uri
211     link="#reboot">Rebooting the System</uri>.
212 swift 1.10 </p>
213    
214     </body>
215     </subsection>
216 nightmorph 1.16 -->
217 fox2mike 1.13 <subsection>
218     <title>Installing arcload</title>
219     <body>
220    
221     <p>
222     <c>arcload</c> was written for machines that require 64-bit kernels, and
223     therefore can't use <c>arcboot</c> (which can't easily be compiled as a 64-bit
224 neysx 1.15 binary). It also works around peculiarities that arise when loading kernels
225     directly from the volume header. So, now you know what this is about, we can
226     proceed with the installation:
227 fox2mike 1.13 </p>
228    
229     <pre caption="Merging arcload and dvhtool">
230     # <i>emerge arcload dvhtool</i>
231     </pre>
232    
233     <p>
234     Once this has finished, you should find the <c>arcload</c> binary in
235 neysx 1.15 <path>/usr/lib/arcload</path>. Now, two files exist:
236 fox2mike 1.13 </p>
237    
238     <ul>
239     <li>
240 neysx 1.15 <c>sashARCS</c>: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S and
241     O2 systems
242 fox2mike 1.13 </li>
243     <li>
244     <c>sash64</c>: The 64-bit binary for Octane/Octane2, Origin 200/2000 and
245     Indigo2 Impact systems
246     </li>
247     </ul>
248    
249     <p>
250     Use <c>dvhtool</c> to install the appropriate binary for your system into the
251     volume header:
252     </p>
253    
254     <pre caption="Placing arcload in the volume header">
255     <comment>(Indy/Indigo2/Challenge S/O2 users)</comment>
256     # <i>dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS</i>
257    
258     <comment>(Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users)</comment>
259     # <i>dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64</i>
260     </pre>
261    
262     <note>
263     You don't have to use the name <c>sashARCS</c> or <c>sash64</c>, unless you are
264 neysx 1.15 installing to the volume header of a bootable CD. For normal boot from
265 fox2mike 1.13 hard-disk, you may name them something else if you wish.
266     </note>
267    
268     <p>
269     Now just use <c>dvhtool</c> to verify they are in the volume header.
270     </p>
271    
272     <pre caption="Checking arcload is present in the volume header">
273     # <i>dvhtool --print-volume-directory</i>
274     ----- directory entries -----
275     Entry #0, name "sash64", start 4, bytes 55859
276     #
277     </pre>
278    
279     <p>
280 neysx 1.15 Now, the <c>arc.cf</c> file has a C-like syntax. For the full detail on how one
281     configures it, see the <uri
282     link="http://www.linux-mips.org/wiki/Arcload">arcload page on the Linux/MIPS
283     wiki</uri>. In short, you define a number of options, which you enable and
284     disable at boot time using the <c>OSLoadFilename</c> variable.
285 fox2mike 1.13 </p>
286    
287     <pre caption="An example arc.cf">
288     <comment># ARCLoad Configuration</comment>
289    
290     <comment># Some default settings...</comment>
291     append "root=/dev/sda3";
292     append "ro";
293     append "console=ttyS0,9600";
294    
295 neysx 1.15 <comment># Our main definition. ip28 may be changed if you wish.</comment>
296 fox2mike 1.13 ip28 {
297     <comment># Definition for a "working" kernel</comment>
298     <comment># Select this by setting OSLoadFilename="ip28(working)"</comment>
299     working {
300     description "SGI Indigo2 Impact R10000\n\r";
301     image system "/working";
302     }
303    
304     <comment># Definition for a "new" kernel</comment>
305     <comment># Select this by setting OSLoadFilename="ip28(new)"</comment>
306     new {
307     description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
308     image system "/new";
309     }
310    
311     <comment># For debugging a kernel</comment>
312     <comment># Select this by setting OSLoadFilename="ip28(working,debug)"</comment>
313     <comment># or OSLoadFilename="ip28(new,debug)"</comment>
314     debug {
315     description "Debug console";
316     append "init=/bin/bash";
317     }
318     }
319     </pre>
320    
321     <p>
322     This is then placed in the volume header with <c>sash64</c> (or
323 neysx 1.15 <c>sashARCS</c>) as shown below. Kernels also get placed in the volume header.
324 fox2mike 1.13 </p>
325    
326 nightmorph 1.16 <note>
327     With <c>arcload</c> 0.5, it is possible to load these files from an EXT3
328     partition, rather than loading these into the volume header. If you are
329     using the newer release, you may skip copying these to the volume
330     header, and instead, place them in your <c>/boot</c> partition.
331     </note>
332    
333 fox2mike 1.13 <pre caption="Placing arc.cf and kernel in the volume header">
334     # <i>dvhtool --unix-to-vh arc.cf arc.cf</i>
335     # <i>dvhtool --unix-to-vh /usr/src/linux/vmlinux new</i>
336     </pre>
337    
338     <p>
339 neysx 1.15 With this done, now all that's left is to set some options in the PROM. See the
340 fox2mike 1.13 section on <uri link="#reboot">Rebooting the System</uri>.
341     </p>
342    
343     </body>
344     </subsection>
345    
346 swift 1.10 </section>
347    
348     <section id="cobalt">
349     <title>Cobalt MicroServers -- Setting Up CoLo</title>
350     <subsection>
351     <title>Installing CoLo</title>
352     <body>
353    
354     <p>
355 neysx 1.15 On Cobalt servers, these machines have a much less capable firmware installed
356     on chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and
357     has a number of serious limitations.
358 swift 1.10 </p>
359    
360     <ul>
361     <li>
362 neysx 1.15 There's a 675kB (approximate) limit on kernels. The current size of Linux
363     2.4 makes it damn near impossible to make a kernel this size. Linux 2.6 is
364 fox2mike 1.13 totally out of the question.
365 swift 1.10 </li>
366     <li>
367     64-bit kernels are not supported by the stock firmware (although these are
368     highly experimental on Cobalt machines at this time)
369     </li>
370     <li>
371     The shell is basic at best
372     </li>
373     </ul>
374    
375     <p>
376 neysx 1.15 To overcome these limitations, an alternative firmware, called <uri
377     link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> (Cobalt Loader) was
378     developed. This is a BOOTROM image that can either be flashed into the chip
379     inside the Cobalt server, or loaded from the existing firmware.
380 swift 1.10 </p>
381    
382     <note>
383     This guide will take you through setting up CoLo so that it is loaded by the
384 neysx 1.15 stock firmware. This is the only truly safe, and recommended way to set up
385     CoLo.
386 swift 1.10 </note>
387    
388     <warn>
389 neysx 1.15 You may, if you wish, flash it into the server, and totally replace the
390     original firmware -- however, you are entirely on your own in that endeavour.
391     Should anything go wrong, you will need to physically remove the BOOTROM and
392     reprogram it yourself with the stock firmware. If you are not sure how to do
393     this -- then <e>DO NOT</e> flash your machine. We take no responsibility for
394     whatever happens if you ignore this advice.
395 swift 1.10 </warn>
396    
397     <p>
398 neysx 1.15 Okay, with the warnings over now, we'll get on with installing CoLo. First,
399 swift 1.10 start by emerging the package.
400     </p>
401    
402     <pre caption="Emerging colo">
403     # <i>emerge colo</i>
404     </pre>
405    
406     <p>
407     With that installed (I hope you read those messages ;-) you should be able to
408     look inside the <path>/usr/lib/colo</path> directory to find two files,
409     <path>colo-chain.elf</path>: the "kernel" for the stock firmware to load, and
410 neysx 1.15 <path>colo-rom-image.bin</path>: a ROM image for flashing into the BOOTROM. We
411 swift 1.10 start by mounting /boot and dumping a compressed copy of
412     <path>colo-chain.elf</path> in <path>/boot</path> where the system expects it.
413     </p>
414    
415     <pre caption="Putting CoLo in its place">
416     # <i>gzip -9vc /usr/lib/colo/colo-chain.elf &gt; /boot/vmlinux.gz</i>
417     </pre>
418    
419     </body>
420     </subsection>
421    
422     <subsection>
423     <title>Configuring CoLo</title>
424    
425     <body>
426    
427     <p>
428     Now, when the system first boots up, it'll load CoLo which will spit up a menu
429 neysx 1.15 on the back LCD. The first option (and default that is assumed after roughly 5
430     seconds) is to boot to the hard disk. The system would then attempt to mount
431 swift 1.10 the first Linux partition it finds, and run the script
432 neysx 1.15 <path>default.colo</path>. The syntax is fully documented in the CoLo
433 swift 1.10 documentation (have a peek at
434     <path>/usr/share/doc/colo-X.YY/README.shell.gz</path> -- where X.YY is the
435     version installed), and is very simple.
436     </p>
437    
438 swift 1.11 <note>
439     Just a tip: when installing kernels, I usually create two kernel images,
440     <path>kernel.gz.working</path> -- a known working kernel, and
441 neysx 1.15 <path>kernel.gz.new</path> -- a kernel that's just been compiled. You can
442     either use symlinks to point to the curent "new" and "working" kernels, or just
443     rename the kernel images.
444 swift 1.11 </note>
445    
446 swift 1.10 <pre caption="A basic default.colo">
447     <comment>#:CoLo:#</comment>
448     mount hda1
449 swift 1.11 load /kernel.gz.working
450 swift 1.10 execute root=/dev/hda3 ro console=ttyS0,115200
451     </pre>
452    
453     <note>
454     CoLo will refuse to load a script that does not begin with the <c>#:CoLo:#</c>
455 neysx 1.15 line. Think of it as the equivalent of saying <c>#!/bin/sh</c> in shell
456 swift 1.10 scripts.
457     </note>
458    
459     <p>
460     It is also possible to ask a question, such as which kernel &amp; configuration
461 neysx 1.15 you'd like to boot, with a default timeout. This configuration does exactly
462 fox2mike 1.13 this, asks the user which kernel they wish to use, and executes the chosen
463 neysx 1.15 image. <path>vmlinux.gz.new</path> and <path>vmlinux.gz.working</path> may be
464 fox2mike 1.13 actual kernel images, or just symlinks pointing to the kernel images on that
465 neysx 1.15 disk. The <c>50</c> argument to <c>select</c> specifies that it should proceed
466 fox2mike 1.13 with the first option ("Working") after 50/10 seconds.
467 swift 1.10 </p>
468    
469     <pre caption="Menu-based configuration">
470     <comment>#:CoLo:#</comment>
471    
472     lcd "Mounting hda1"
473     mount hda1
474 fox2mike 1.13 select "Which Kernel?" 50 Working New
475    
476     goto {menu-option}
477     var image-name vmlinux.gz.working
478     goto 3f
479     @var image-name vmlinux.gz.working
480     goto 2f
481     @var image-name vmlinux.gz.new
482    
483     @lcd "Loading Linux" {image-name}
484     load /{image-name}
485 swift 1.10 lcd "Booting..."
486     execute root=/dev/hda5 ro console=ttyS0,115200
487     boot
488     </pre>
489    
490     <p>
491 fox2mike 1.13 See the documentation in <path>/usr/share/doc/colo-VERSION</path> for more
492     details.
493 swift 1.10 </p>
494 fox2mike 1.13
495 swift 1.10 </body>
496    
497     </subsection>
498     </section>
499    
500     <section>
501     <title>Setting up for Serial Console</title>
502    
503     <subsection>
504     <body>
505    
506     <p>
507     Okay, the Linux installation as it stands now, would boot fine, but assumes
508 neysx 1.15 you're going to be logged in at a physical terminal. On Cobalt machines, this
509 swift 1.10 is particularly bad -- there's no such thing as a physical terminal.
510     </p>
511    
512     <note>
513 neysx 1.15 Those who do have the luxury of a supported video chipset may skip this section
514     if they wish.
515 swift 1.10 </note>
516    
517     <p>
518 neysx 1.15 First, pull up an editor and hack away at <path>/etc/inittab</path>. Further
519 swift 1.10 down in the file, you'll see something like this:
520     </p>
521    
522     <pre caption="inittab Configuration">
523     <comment># SERIAL CONSOLE</comment>
524     <comment>#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102</comment>
525    
526     <comment># TERMINALS</comment>
527     c1:12345:respawn:/sbin/agetty 38400 tty1 linux
528     c2:12345:respawn:/sbin/agetty 38400 tty2 linux
529     c3:12345:respawn:/sbin/agetty 38400 tty3 linux
530     c4:12345:respawn:/sbin/agetty 38400 tty4 linux
531     c5:12345:respawn:/sbin/agetty 38400 tty5 linux
532     c6:12345:respawn:/sbin/agetty 38400 tty6 linux
533    
534     <comment># What to do at the "Three Finger Salute".</comment>
535     ca:12345:ctrlaltdel:/sbin/shutdown -r now
536 swift 1.1 </pre>
537    
538     <p>
539 neysx 1.15 First, uncomment the <c>c0</c> line. By default, it's set to use a terminal
540     baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200
541     to match the baud rate decided by the BOOT ROM. This is how that section looks
542     on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend
543     commenting out the local terminal lines (<c>c1</c> through to <c>c6</c>) as
544     these have a habit of misbehaving when they can't open <path>/dev/ttyX</path>.
545 swift 1.1 </p>
546    
547 swift 1.10 <pre caption="Example snippet from inittab">
548     <comment># SERIAL CONSOLE</comment>
549     c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102
550    
551     <comment># TERMINALS -- These are useless on a headless qube</comment>
552     <comment>#c1:12345:respawn:/sbin/agetty 38400 tty1 linux</comment>
553     <comment>#c2:12345:respawn:/sbin/agetty 38400 tty2 linux</comment>
554     <comment>#c3:12345:respawn:/sbin/agetty 38400 tty3 linux</comment>
555     <comment>#c4:12345:respawn:/sbin/agetty 38400 tty4 linux</comment>
556     <comment>#c5:12345:respawn:/sbin/agetty 38400 tty5 linux</comment>
557     <comment>#c6:12345:respawn:/sbin/agetty 38400 tty6 linux</comment>
558     </pre>
559    
560 swift 1.1 <p>
561 swift 1.10 Now, lastly... we have to tell the system, that the local serial port can be
562 neysx 1.15 trusted as a secure terminal. The file we need to poke at is
563     <path>/etc/securetty</path>. It contains a list of terminals that the system
564     trusts. We simply stick in two more lines, permitting the serial line to be
565 swift 1.10 used for <c>root</c> logins.
566 swift 1.2 </p>
567    
568 swift 1.10 <pre caption="Enabling root logins on serial console">
569     <comment>(/dev/ttyS0 -- the traditional name for the first serial port)</comment>
570     # <i>echo 'ttyS0' >> /etc/securetty</i>
571    
572     <comment>(Lately, Linux also calls this /dev/tts/0 -- so we add this
573     too)</comment>
574     # <i>echo 'tts/0' >> /etc/securetty</i>
575     </pre>
576    
577 swift 1.2 </body>
578     </subsection>
579     </section>
580 swift 1.10
581 cam 1.3 <section id="reboot">
582 swift 1.2 <title>Rebooting the System</title>
583     <subsection>
584     <body>
585    
586     <p>
587 neysx 1.15 Exit the chrooted environment and unmount all mounted partitions. Then type in
588 swift 1.2 that one magical command you have been waiting for: <c>reboot</c>.
589     </p>
590    
591     <pre caption="Exiting the chroot, unmounting all partitions and rebooting">
592     # <i>exit</i>
593 swift 1.4 cdimage ~# <i>cd</i>
594 neysx 1.12 cdimage ~# <i>umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo</i>
595 swift 1.2 cdimage ~# <i>reboot</i>
596     </pre>
597    
598 swift 1.10 <note>
599     <e>Cobalt Users:</e> The rest of this section covers the setting up of the SGI
600 nightmorph 1.16 PROM so that it boots <!--<c>arcboot</c>/--><c>arcload</c> off disk and loads
601     Linux.
602 neysx 1.15 This is not applicable to the setup of Cobalt servers. In fact, all your work
603 fox2mike 1.13 is done -- there is no configuration needed for the first boot up, you can skip
604     to the next section: <uri link="?part=1&amp;chap=11">Finalising your Gentoo
605 swift 1.10 Installation</uri>
606     </note>
607    
608 swift 1.2 </body>
609     </subsection>
610     </section>
611     <section>
612 swift 1.10 <title>Tweaking the SGI PROM</title>
613 swift 1.2 <subsection>
614 fox2mike 1.13 <title>Setting generic PROM settings</title>
615 swift 1.2 <body>
616    
617     <p>
618 fox2mike 1.13 Now that you've installed the bootloader, you're ready to reboot the machine.
619     </p>
620    
621     <pre caption="Rebooting">
622     <comment>(Exit the chroot environment)</comment>
623     # <i>exit</i>
624    
625     <comment>(Unmount the drives)</comment>
626     # <i>umount /gentoo/boot</i>
627     # <i>umount /gentoo</i>
628    
629     <comment>(Reboot)</comment>
630     # <i>reboot</i>
631     </pre>
632    
633     <p>
634 neysx 1.15 When you are rebooted, go to the <e>System Maintenance Menu</e> and select
635 fox2mike 1.13 <e>Enter Command Monitor</e> (<c>5</c>) like you did when you netbooted the
636     machine.
637 swift 1.2 </p>
638    
639     <pre caption="Configuring the PROM to Boot Gentoo">
640     1) Start System
641     2) Install System Software
642     3) Run Diagnostics
643     4) Recover System
644     5) Enter Command Monitor
645    
646     Option? <i>5</i>
647 neysx 1.15 Command Monitor. Type "exit" to return to the menu.
648 swift 1.2
649 nightmorph 1.16 <comment>(Set some options for arcload)</comment>
650 fox2mike 1.13
651     <comment>(Provide the location of the Volume Header)</comment>
652     &gt;&gt; <i>setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)</i>
653    
654     <comment>(Automatically boot Gentoo)</comment>
655     &gt;&gt; <i>setenv AutoLoad Yes</i>
656    
657     <comment>(Set the timezone)</comment>
658     &gt;&gt; <i>setenv TimeZone EST5EDT</i>
659    
660     <comment>(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))</comment>
661     &gt;&gt; <i>setenv console d1</i>
662    
663 nightmorph 1.16 <comment>(Setting the serial console baud rate. This is optional, 9600 is the )
664 neysx 1.15 (default setting, although one may use rates up to 38400 if that is desired. )</comment>
665 fox2mike 1.13 &gt;&gt; <i>setenv dbaud 9600</i>
666     </pre>
667    
668     <p>
669     Now, the next settings depend on how you are booting the system.
670     </p>
671    
672     </body>
673     </subsection>
674    
675     <subsection>
676     <title>Settings for direct volume-header booting</title>
677     <body>
678    
679     <p>
680 neysx 1.15 This is covered here for completeness. It's recommended that users look into
681 nightmorph 1.16 installing <c>arcload</c> instead.
682 fox2mike 1.13 </p>
683    
684     <note>
685     This only works on the Indy, Indigo2 (R4k) and Challenge S.
686     </note>
687    
688     <pre caption="PROM settings for booting off the volume header">
689 swift 1.2 <comment>(&lt;root device&gt; = Gentoo's root partition, e.g. /dev/sda3)</comment>
690     &gt;&gt; <i>setenv OSLoadPartition &lt;root device&gt;</i>
691    
692     <comment>(To list the available kernels, type "ls")</comment>
693     &gt;&gt; <i>setenv OSLoader &lt;kernel name&gt;</i>
694     &gt;&gt; <i>setenv OSLoadFilename &lt;kernel name&gt;</i>
695    
696     <comment>(Declare the kernel parameters you want to pass)</comment>
697     &gt;&gt; <i>setenv OSLoadOptions &lt;kernel parameters&gt;</i>
698 fox2mike 1.13 </pre>
699    
700     <p>
701     If you wish to try a kernel without messing with kernel parameters, you may do
702     so using the <c>boot -f</c> PROM command:
703     </p>
704 swift 1.2
705 fox2mike 1.13 <pre caption="Booting without changing environment variables">
706     <comment>(Booting a kernel, "new", with additional options)</comment>
707     # <i>boot -f new root=/dev/sda3 ro</i>
708     </pre>
709    
710     </body>
711     </subsection>
712    
713     <subsection>
714     <title>Settings for arcload</title>
715     <body>
716    
717     <p>
718 neysx 1.15 <c>arcload</c> uses the <c>OSLoadFilename</c> option to specify which options
719     to set from <path>arc.cf</path>. The configuration file is essentially a
720     script, with the top-level blocks defining boot images for different systems,
721     and inside that, optional settings. Thus, setting
722     <c>OSLoadFilename=mysys(serial)</c> pulls in the settings for the <c>mysys</c>
723     block, then sets further options overridden in <c>serial</c>.
724 fox2mike 1.13 </p>
725    
726     <p>
727     In the example file above, we have one system block defined, <c>ip28</c> with
728 neysx 1.15 <c>working</c>, <c>new</c> and <c>debug</c> options available. We define our
729 fox2mike 1.13 PROM variables as so:
730     </p>
731    
732     <pre caption="PROM settings for using arcload">
733     <comment>(Select arcload as the bootloader:- sash64 or sashARCS)</comment>
734     &gt;&gt; setenv OSLoader sash64
735    
736     <comment>(Use the "working" kernel image, defined in "ip28" section of arc.cf)</comment>
737     &gt;&gt; setenv OSLoadFilename ip28(working)
738     </pre>
739    
740     </body>
741     </subsection>
742    
743 nightmorph 1.16 <!-- Slated for removal
744 fox2mike 1.13 <subsection>
745     <title>Settings for arcboot</title>
746     <body>
747    
748     <p>
749     <c>arcboot</c> loads its configuration file and kernels from your
750     <path>/boot</path> partition, which needs to be formatted either EXT2 or EXT3.
751 neysx 1.15 Thus <c>OSLoadPartition</c> needs to point to that partition. <c>OSLoader</c>
752 fox2mike 1.13 should point to the <c>arcboot</c> binary in the volume header, and
753     <c>OSLoadFilename</c> is the image name being used.
754     </p>
755    
756     <pre caption="PROM settings for using arcboot">
757 nightmorph 1.16 <comment>(Read configuration and kernels from SCSI ID# 1, partition 0 - - sda1)</comment>
758 fox2mike 1.13 &gt;&gt; <i>setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)</i>
759    
760     <comment>(Use arcboot as the bootloader)</comment>
761 nightmorph 1.16 &gt;&gt; <i>setenv OSLoader arcboot</i>
762 swift 1.2
763 fox2mike 1.13 <comment>(Which boot image in arcboot.conf to load)</comment>
764     &gt;&gt; <i>setenv OSLoadFilename working</i>
765     </pre>
766 swift 1.2
767 fox2mike 1.13 <p>
768     When testing kernels via <c>arcboot</c> you can specify an alternate image like
769     so (where <c>new</c> is the alternate image):
770     </p>
771 swift 1.2
772 fox2mike 1.13 <pre caption="Specifying an alternate image">
773     # <i>boot new</i>
774 swift 1.2 </pre>
775    
776 fox2mike 1.13 </body>
777 nightmorph 1.16 </subsection> -->
778 fox2mike 1.13
779     <subsection>
780     <title>All Done</title>
781     <body>
782    
783 swift 1.2 <p>
784 neysx 1.15 Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and finish
785     up with <uri link="?part=1&amp;chap=11">Finalizing your Gentoo
786 swift 1.2 Installation</uri>.
787 swift 1.1 </p>
788    
789     </body>
790     </subsection>
791     </section>
792     </sections>

  ViewVC Help
Powered by ViewVC 1.1.20