/[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.10 - (hide annotations) (download) (as text)
Mon Feb 14 14:59:19 2005 UTC (9 years, 10 months ago) by swift
Branch: MAIN
Changes since 1.9: +328 -26 lines
File MIME type: application/xml
#81072 - MIPS overhaul

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     <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
6    
7 swift 1.10 <!-- $Header: /var/cvsroot/gentoo-doc/en/handbook/hb-install-mips-bootloader.xml,v 1.7 2005/02/14 13:49:37 stuartl Exp $ -->
8 swift 1.1
9     <sections>
10 swift 1.6
11 swift 1.10 <version>1.6</version>
12     <date>2005-02-14</date>
13 swift 1.6
14 swift 1.10 <section id="sgi">
15     <title>Silicon Graphics Machines -- Setting Up Arcboot</title>
16 swift 1.1 <subsection>
17 swift 1.10 <title>Installing arcboot</title>
18 swift 1.1 <body>
19    
20     <p>
21 swift 1.10 Previously in this guide, we showed you how to make a kernel, then copy it to
22     the volume header using <c>dvhtool</c>. There were two main flaws with this
23     system:
24 swift 1.1 </p>
25    
26 swift 1.10 <ul>
27     <li>This is not supported on all SGI systems</li>
28     <li>It requires a significantly larger volume header</li>
29     </ul>
30    
31 swift 1.1 <p>
32 swift 1.10 In order to boot the machine, a bootloader, <c>arcboot</c> was developed for
33     this purpose. Instead of putting the kernel directly into the volume header, we
34     leave it in <path>/boot</path> (which resides on a EXT2/3 partition), and tell
35     <c>arcboot</c> (which sits in the volume header in place of the kernel) where to
36     find it. So our first step, is to emerge some tools that we'll use later...
37 swift 1.1 </p>
38    
39 swift 1.10 <pre caption="Installing the required tools">
40     # <i>emerge dvhtool arcboot</i>
41 swift 1.1 </pre>
42    
43     <p>
44 swift 1.10 That should have installed two tools, <c>arcboot</c> which sits in the volume
45     header and loads kernels for us, and <c>dvhtool</c> which helps us put
46     <c>arcboot</c> into the volume header.
47     </p>
48     <p>
49     The magic binary we want, hides in <path>/usr/lib/arcboot</path> -- on IP22
50     systems (Indy, Indigo 2, Challenge S), it'll be called
51     <path>arcboot.ip22</path>. Other systems should be similar. We
52     first copy this file into the volume header.
53 swift 1.1 </p>
54    
55 swift 1.10 <pre caption="Installing arcboot into the volume header">
56     # <i>dvhtool --unix-to-vh /usr/lib/arcboot/arcboot.ip?? arcboot</i>
57 swift 1.1 </pre>
58    
59     <p>
60 swift 1.10 We then verify the presence of the file in the volume header.
61 swift 1.1 </p>
62    
63 swift 1.10 <pre caption="Checking if arcboot made it okay">
64 swift 1.1 # <i>dvhtool --print-volume-directory</i>
65 swift 1.10 ----- directory entries -----
66     Entry #0, name "linux", start 4, bytes 3262570
67     Entry #1, name "newlinux", start 6377, bytes 7619627
68     Entry #3, name "arcboot", start 21260, bytes 51448
69     #
70     </pre>
71    
72     <note>
73     You'll notice that in my case, I've got two old kernels sitting around there,
74     <path>linux</path> and <path>newlinux</path>. This is a hangover from before we
75     started using <c>arcboot</c>. Their presence doesn't matter -- just so long as
76     <c>arcboot</c> is present, everything is fine.
77     </note>
78    
79     </body>
80     </subsection>
81    
82     <subsection>
83     <title>Configuring arcboot</title>
84    
85     <body>
86    
87     <p>
88     If you've ever set up the Linux Loader (<c>lilo</c>) before, you'll find that
89     <c>arcboot</c> employs a similar syntax in its configuration file. Bear in mind
90     though; <c>arcboot</c> expects to find its configuration file existing on an
91     EXT2/3 partition as <path>/etc/arcboot.conf</path>. The easiest way around this
92     is to make sure <path>/boot</path> is an EXT2/3 partition and that there's a
93     file called <path>arcboot.conf</path> inside the <path>/boot/etc</path>
94     directory. An example config can be found in
95     <path>/etc/arcboot.conf.sample</path>
96     </p>
97    
98     <pre caption="Putting arcboot.conf in its place">
99     <comment>(Create the /boot/etc directory)</comment>
100     # <i>mkdir /boot/etc</i>
101    
102     <comment>(Put our configuration into the target directory)</comment>
103     # <i>cp /etc/arcboot.conf.sample /boot/etc/arcboot.conf</i>
104    
105     <comment>(Create a symlink back to /etc)</comment>
106     # <i>ln -s /boot/etc/arcboot.conf /etc/arcboot.conf</i>
107    
108     <comment>(... and a symlink in /boot pointing to itself)</comment>
109     # <i>(cd /boot; ln -s . boot)</i>
110     </pre>
111    
112     <p>
113     You can then edit <path>/etc/arcboot.conf</path> to your own preference.
114     Personally, I prefer to set up two kernel images: <path>new</path>, a freshly built
115     image that may or may not work; and <path>working</path>, a proven trustworthy
116     kernel image. My <path>arcboot.conf</path> looks a bit like this.
117     </p>
118    
119     <pre caption="Example arcboot.conf">
120     <comment># arcboot.conf</comment>
121     <comment>#</comment>
122     <comment># copyright 2002 Guido Guenther &lt;agx@sigxcpu.org&gt;</comment>
123     <comment>#</comment>
124     label=working
125     image=/vmlinux
126     append="root=/dev/sda3"
127    
128     <comment># backup version</comment>
129     label=new
130     image=/vmlinux-new
131     append="root=/dev/sda3"
132     </pre>
133    
134     <p>
135     Once that is set up, there's then just some little tweaks that you need to do
136     within the SGI PROM to make this magic work. This is covered in, not the next
137     section (that's for Cobalt servers) but the following section
138     <uri link="#reboot">Rebooting the System</uri>.
139     </p>
140    
141     </body>
142     </subsection>
143     </section>
144    
145     <section id="cobalt">
146     <title>Cobalt MicroServers -- Setting Up CoLo</title>
147     <subsection>
148     <title>Installing CoLo</title>
149     <body>
150    
151     <p>
152     On Cobalt servers, these machines have a much less capable firmware installed on
153     chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and has a
154     number of serious limitations.
155     </p>
156    
157     <ul>
158     <li>
159     There's a 675kB limit on kernels. The current size of Linux 2.4 makes it
160     damn near impossible to make a kernel this size. Linux 2.6 is totally out
161     of the question.
162     </li>
163     <li>
164     64-bit kernels are not supported by the stock firmware (although these are
165     highly experimental on Cobalt machines at this time)
166     </li>
167     <li>
168     The shell is basic at best
169     </li>
170     </ul>
171    
172     <p>
173     To overcome these limitations, an alternative firmware, called
174     <uri link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> (Cobalt
175     Loader) was developed. This is a BOOTROM image that can either be flashed into
176     the chip inside the Cobalt server, or loaded from the existing firmware.
177     </p>
178    
179     <note>
180     This guide will take you through setting up CoLo so that it is loaded by the
181     stock firmware. This is the only truly safe, and recommended way to set up CoLo.
182     </note>
183    
184     <warn>
185     You may, if you wish, flash it into the server, and totally
186     replace the original firmware -- however, you are entirely on your own in that
187     endeavour. Should anything go wrong, you will need to physically remove the
188     BOOTROM and reprogram it yourself with the stock firmware. If you are not
189     sure how to do this -- then <e>DO NOT</e> flash your machine. We take no
190     responsibility for whatever happens if you ignore this advice.
191     </warn>
192    
193     <p>
194     Okay, with the warnings over now, we'll get on with installing CoLo. First,
195     start by emerging the package.
196     </p>
197    
198     <pre caption="Emerging colo">
199     # <i>emerge colo</i>
200     </pre>
201    
202     <p>
203     With that installed (I hope you read those messages ;-) you should be able to
204     look inside the <path>/usr/lib/colo</path> directory to find two files,
205     <path>colo-chain.elf</path>: the "kernel" for the stock firmware to load, and
206     <path>colo-rom-image.bin</path>: a ROM image for flashing into the BOOTROM. We
207     start by mounting /boot and dumping a compressed copy of
208     <path>colo-chain.elf</path> in <path>/boot</path> where the system expects it.
209     </p>
210    
211     <pre caption="Putting CoLo in its place">
212     # <i>gzip -9vc /usr/lib/colo/colo-chain.elf &gt; /boot/vmlinux.gz</i>
213     </pre>
214    
215     </body>
216     </subsection>
217    
218     <subsection>
219     <title>Configuring CoLo</title>
220    
221     <body>
222    
223     <p>
224     Now, when the system first boots up, it'll load CoLo which will spit up a menu
225     on the back LCD. The first option (and default that is assumed after roughly 5
226     seconds) is to boot to the hard disk. The system would then attempt to mount
227     the first Linux partition it finds, and run the script
228     <path>default.colo</path>. The syntax is fully documented in the CoLo
229     documentation (have a peek at
230     <path>/usr/share/doc/colo-X.YY/README.shell.gz</path> -- where X.YY is the
231     version installed), and is very simple.
232     </p>
233    
234     <pre caption="A basic default.colo">
235     <comment>#:CoLo:#</comment>
236     mount hda1
237     load /vmlinux-working.gz
238     execute root=/dev/hda3 ro console=ttyS0,115200
239     </pre>
240    
241     <note>
242     CoLo will refuse to load a script that does not begin with the <c>#:CoLo:#</c>
243     line. Think of it as the equivalent of saying <c>#!/bin/sh</c> in shell
244     scripts.
245     </note>
246    
247     <p>
248     It is also possible to ask a question, such as which kernel &amp; configuration
249     you'd like to boot, with a default timeout. This is the configuration I use on
250     my Cobalt server:
251     </p>
252    
253     <pre caption="Menu-based configuration">
254     <comment>#:CoLo:#</comment>
255    
256     lcd "Mounting hda1"
257     mount hda1
258     menu "Which Kernel?" 50 Working working New new
259     lcd "Loading Linux" {menu-option}
260     load /vmlinux.gz.{menu-option}
261     lcd "Booting..."
262     execute root=/dev/hda5 ro console=ttyS0,115200
263     boot
264     </pre>
265    
266     <p>
267     The above script asks the user which kernel he/she would like to boot (either
268     New or Working), then loads <path>vmlinux.gz.new</path> or
269     <path>vmlinux.gz.working</path> depending on the selection. If a selection is
270     not made within 5 seconds (50/10ths of a second) it boots the first option.
271     </p>
272     </body>
273    
274     </subsection>
275     </section>
276    
277     <section>
278     <title>Setting up for Serial Console</title>
279    
280     <subsection>
281     <body>
282    
283     <p>
284     Okay, the Linux installation as it stands now, would boot fine, but assumes
285     you're going to be logged in at a physical terminal. On Cobalt machines, this
286     is particularly bad -- there's no such thing as a physical terminal.
287     </p>
288    
289     <note>
290     Those who do have the luxury of a supported framebuffer may skip this section if
291     they wish.
292     </note>
293    
294     <p>
295     First, pull up an editor and hack away at <path>/etc/inittab</path>. Further
296     down in the file, you'll see something like this:
297     </p>
298    
299     <pre caption="inittab Configuration">
300     <comment># SERIAL CONSOLE</comment>
301     <comment>#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102</comment>
302    
303     <comment># TERMINALS</comment>
304     c1:12345:respawn:/sbin/agetty 38400 tty1 linux
305     c2:12345:respawn:/sbin/agetty 38400 tty2 linux
306     c3:12345:respawn:/sbin/agetty 38400 tty3 linux
307     c4:12345:respawn:/sbin/agetty 38400 tty4 linux
308     c5:12345:respawn:/sbin/agetty 38400 tty5 linux
309     c6:12345:respawn:/sbin/agetty 38400 tty6 linux
310    
311     <comment># What to do at the "Three Finger Salute".</comment>
312     ca:12345:ctrlaltdel:/sbin/shutdown -r now
313 swift 1.1 </pre>
314    
315     <p>
316 swift 1.10 First, uncomment the <c>c0</c> line. By default, it's set to use a terminal
317     baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200
318     to match the baud rate decided by the BOOT ROM. This is how that section looks
319     on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend
320     commenting out the local terminal lines (<c>c1</c> through to <c>c6</c>)
321     as these have a habit of misbehaving when they can't open
322     <path>/dev/ttyX</path>.
323 swift 1.1 </p>
324    
325 swift 1.10 <pre caption="Example snippet from inittab">
326     <comment># SERIAL CONSOLE</comment>
327     c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102
328    
329     <comment># TERMINALS -- These are useless on a headless qube</comment>
330     <comment>#c1:12345:respawn:/sbin/agetty 38400 tty1 linux</comment>
331     <comment>#c2:12345:respawn:/sbin/agetty 38400 tty2 linux</comment>
332     <comment>#c3:12345:respawn:/sbin/agetty 38400 tty3 linux</comment>
333     <comment>#c4:12345:respawn:/sbin/agetty 38400 tty4 linux</comment>
334     <comment>#c5:12345:respawn:/sbin/agetty 38400 tty5 linux</comment>
335     <comment>#c6:12345:respawn:/sbin/agetty 38400 tty6 linux</comment>
336     </pre>
337    
338 swift 1.1 <p>
339 swift 1.10 Now, lastly... we have to tell the system, that the local serial port can be
340     trusted as a secure terminal. The file we need to poke at is
341     <path>/etc/securetty</path>. It contains a list of terminals that the system
342     trusts. We simply stick in two more lines, permitting the serial line to be
343     used for <c>root</c> logins.
344 swift 1.2 </p>
345    
346 swift 1.10 <pre caption="Enabling root logins on serial console">
347     <comment>(/dev/ttyS0 -- the traditional name for the first serial port)</comment>
348     # <i>echo 'ttyS0' >> /etc/securetty</i>
349    
350     <comment>(Lately, Linux also calls this /dev/tts/0 -- so we add this
351     too)</comment>
352     # <i>echo 'tts/0' >> /etc/securetty</i>
353     </pre>
354    
355 swift 1.2 </body>
356     </subsection>
357     </section>
358 swift 1.10
359 cam 1.3 <section id="reboot">
360 swift 1.2 <title>Rebooting the System</title>
361     <subsection>
362     <body>
363    
364     <p>
365     Exit the chrooted environment and unmount all mounted partitions. Then type in
366     that one magical command you have been waiting for: <c>reboot</c>.
367     </p>
368    
369     <pre caption="Exiting the chroot, unmounting all partitions and rebooting">
370     # <i>exit</i>
371 swift 1.4 cdimage ~# <i>cd</i>
372 swift 1.2 cdimage ~# <i>umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo</i>
373     cdimage ~# <i>reboot</i>
374     </pre>
375    
376 swift 1.10 <note>
377     <e>Cobalt Users:</e> The rest of this section covers the setting up of the SGI
378     PROM so that it boots <c>arcboot</c> off disk and loads Linux. This is not
379     applicable to the setup of Cobalt servers. In fact, all your work is done --
380     there is no configuration needed for the first boot up, you can skip to the next
381     section: <uri link="?part=1&amp;chap=11">Finalising your Gentoo
382     Installation</uri>
383     </note>
384    
385 swift 1.2 </body>
386     </subsection>
387     </section>
388     <section>
389 swift 1.10 <title>Tweaking the SGI PROM</title>
390 swift 1.2 <subsection>
391     <body>
392    
393     <p>
394     When you are rebooted, go to the <e>System Maintenance Menu</e> and select
395     <e>Enter Command Monitor</e> (<c>5</c>). If you want to test your new Gentoo
396     installation, you can just run <c>boot -f &lt;kernel name&gt;</c>. To have your
397     system permanently boot into the Gentoo installation, you need to set some
398 swift 1.10 variables in the SGI PROM:
399 swift 1.2 </p>
400    
401     <pre caption="Configuring the PROM to Boot Gentoo">
402     1) Start System
403     2) Install System Software
404     3) Run Diagnostics
405     4) Recover System
406     5) Enter Command Monitor
407    
408     Option? <i>5</i>
409     Command Monitor. Type "exit" to return to the menu.
410    
411     <comment>(&lt;root device&gt; = Gentoo's root partition, e.g. /dev/sda3)</comment>
412     &gt;&gt; <i>setenv OSLoadPartition &lt;root device&gt;</i>
413    
414     <comment>(To list the available kernels, type "ls")</comment>
415     &gt;&gt; <i>setenv OSLoader &lt;kernel name&gt;</i>
416     &gt;&gt; <i>setenv OSLoadFilename &lt;kernel name&gt;</i>
417    
418     <comment>(Declare the kernel parameters you want to pass)</comment>
419     &gt;&gt; <i>setenv OSLoadOptions &lt;kernel parameters&gt;</i>
420    
421     <comment>(Provide the location of the Volume Header)</comment>
422     &gt;&gt; <i>setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)</i>
423    
424     <comment>(Automatically boot Gentoo)</comment>
425     &gt;&gt; <i>setenv AutoLoad Yes</i>
426    
427     <comment>(Set the timezone)</comment>
428     &gt;&gt; <i>setenv TimeZone EST5EDT</i>
429    
430     <comment>(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))</comment>
431     &gt;&gt; <i>setenv console d1</i>
432     </pre>
433    
434     <p>
435     Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and finish
436     up with <uri link="?part=1&amp;chap=11">Finalizing your Gentoo
437     Installation</uri>.
438 swift 1.1 </p>
439    
440     </body>
441     </subsection>
442     </section>
443     </sections>

  ViewVC Help
Powered by ViewVC 1.1.20