/[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.15 - (hide annotations) (download) (as text)
Mon Jun 12 10:18:17 2006 UTC (8 years, 1 month ago) by neysx
Branch: MAIN
Changes since 1.14: +102 -102 lines
File MIME type: application/xml
#135295 Improved coding style. **No Content Change**

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

  ViewVC Help
Powered by ViewVC 1.1.20