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

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 <!-- $Header: /var/cvsroot/gentoo-doc/en/handbook/hb-install-mips-bootloader.xml,v 1.7 2005/02/14 13:49:37 stuartl Exp $ -->
8
9 <sections>
10
11 <version>1.6</version>
12 <date>2005-02-14</date>
13
14 <section id="sgi">
15 <title>Silicon Graphics Machines -- Setting Up Arcboot</title>
16 <subsection>
17 <title>Installing arcboot</title>
18 <body>
19
20 <p>
21 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 </p>
25
26 <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 <p>
32 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 </p>
38
39 <pre caption="Installing the required tools">
40 # <i>emerge dvhtool arcboot</i>
41 </pre>
42
43 <p>
44 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 </p>
54
55 <pre caption="Installing arcboot into the volume header">
56 # <i>dvhtool --unix-to-vh /usr/lib/arcboot/arcboot.ip?? arcboot</i>
57 </pre>
58
59 <p>
60 We then verify the presence of the file in the volume header.
61 </p>
62
63 <pre caption="Checking if arcboot made it okay">
64 # <i>dvhtool --print-volume-directory</i>
65 ----- 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 </pre>
314
315 <p>
316 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 </p>
324
325 <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 <p>
339 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 </p>
345
346 <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 </body>
356 </subsection>
357 </section>
358
359 <section id="reboot">
360 <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 cdimage ~# <i>cd</i>
372 cdimage ~# <i>umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo</i>
373 cdimage ~# <i>reboot</i>
374 </pre>
375
376 <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 </body>
386 </subsection>
387 </section>
388 <section>
389 <title>Tweaking the SGI PROM</title>
390 <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 variables in the SGI PROM:
399 </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 </p>
439
440 </body>
441 </subsection>
442 </section>
443 </sections>

  ViewVC Help
Powered by ViewVC 1.1.20