/[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.17 - (hide annotations) (download) (as text)
Wed Feb 7 15:12:43 2007 UTC (7 years, 5 months ago) by neysx
Branch: MAIN
Changes since 1.16: +27 -229 lines
File MIME type: application/xml
#165769 arcload Installation Instruction Update

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.17 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml,v 1.16 2006/08/30 22:52:28 nightmorph Exp $ -->
8 swift 1.1
9     <sections>
10 swift 1.6
11 neysx 1.17 <version>7.1</version>
12     <date>2007-02-08</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 neysx 1.17 obsolete, in favour of <c>arcload</c>.
24 fox2mike 1.13 </p>
25    
26     <note>
27 neysx 1.15 The SGI volume header filenames are limited to 8 characters, and there may be
28     no more than 16 files contained in a single volume header.
29 fox2mike 1.13 </note>
30    
31     </body>
32     </subsection>
33    
34     <subsection>
35     <title>Installing arcload</title>
36     <body>
37    
38     <p>
39     <c>arcload</c> was written for machines that require 64-bit kernels, and
40     therefore can't use <c>arcboot</c> (which can't easily be compiled as a 64-bit
41 neysx 1.15 binary). It also works around peculiarities that arise when loading kernels
42     directly from the volume header. So, now you know what this is about, we can
43     proceed with the installation:
44 fox2mike 1.13 </p>
45    
46     <pre caption="Merging arcload and dvhtool">
47     # <i>emerge arcload dvhtool</i>
48     </pre>
49    
50     <p>
51     Once this has finished, you should find the <c>arcload</c> binary in
52 neysx 1.15 <path>/usr/lib/arcload</path>. Now, two files exist:
53 fox2mike 1.13 </p>
54    
55     <ul>
56     <li>
57 neysx 1.15 <c>sashARCS</c>: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S and
58     O2 systems
59 fox2mike 1.13 </li>
60     <li>
61     <c>sash64</c>: The 64-bit binary for Octane/Octane2, Origin 200/2000 and
62     Indigo2 Impact systems
63     </li>
64     </ul>
65    
66     <p>
67     Use <c>dvhtool</c> to install the appropriate binary for your system into the
68     volume header:
69     </p>
70    
71     <pre caption="Placing arcload in the volume header">
72     <comment>(Indy/Indigo2/Challenge S/O2 users)</comment>
73     # <i>dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS</i>
74    
75     <comment>(Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users)</comment>
76     # <i>dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64</i>
77     </pre>
78    
79     <note>
80     You don't have to use the name <c>sashARCS</c> or <c>sash64</c>, unless you are
81 neysx 1.15 installing to the volume header of a bootable CD. For normal boot from
82 fox2mike 1.13 hard-disk, you may name them something else if you wish.
83     </note>
84    
85     <p>
86     Now just use <c>dvhtool</c> to verify they are in the volume header.
87     </p>
88    
89     <pre caption="Checking arcload is present in the volume header">
90     # <i>dvhtool --print-volume-directory</i>
91     ----- directory entries -----
92     Entry #0, name "sash64", start 4, bytes 55859
93     #
94     </pre>
95    
96     <p>
97 neysx 1.15 Now, the <c>arc.cf</c> file has a C-like syntax. For the full detail on how one
98     configures it, see the <uri
99     link="http://www.linux-mips.org/wiki/Arcload">arcload page on the Linux/MIPS
100     wiki</uri>. In short, you define a number of options, which you enable and
101     disable at boot time using the <c>OSLoadFilename</c> variable.
102 fox2mike 1.13 </p>
103    
104     <pre caption="An example arc.cf">
105     <comment># ARCLoad Configuration</comment>
106    
107     <comment># Some default settings...</comment>
108     append "root=/dev/sda3";
109     append "ro";
110     append "console=ttyS0,9600";
111    
112 neysx 1.15 <comment># Our main definition. ip28 may be changed if you wish.</comment>
113 fox2mike 1.13 ip28 {
114     <comment># Definition for a "working" kernel</comment>
115     <comment># Select this by setting OSLoadFilename="ip28(working)"</comment>
116     working {
117     description "SGI Indigo2 Impact R10000\n\r";
118     image system "/working";
119     }
120    
121     <comment># Definition for a "new" kernel</comment>
122     <comment># Select this by setting OSLoadFilename="ip28(new)"</comment>
123     new {
124     description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
125     image system "/new";
126     }
127    
128     <comment># For debugging a kernel</comment>
129     <comment># Select this by setting OSLoadFilename="ip28(working,debug)"</comment>
130     <comment># or OSLoadFilename="ip28(new,debug)"</comment>
131     debug {
132     description "Debug console";
133     append "init=/bin/bash";
134     }
135     }
136     </pre>
137    
138     <p>
139 neysx 1.17 Starting with <c>arcload-0.5</c>, <path>arc.cf</path> and kernels may
140     reside either in the volume header, or on an EXT2/3 partition. If you wish to
141     utilise this newer feature, you may instead place the files in your
142     <path>/boot</path> partition (or <path>/</path> if your boot partition is not
143     separate).
144 fox2mike 1.13 </p>
145    
146     <pre caption="Placing arc.cf and kernel in the volume header">
147     # <i>dvhtool --unix-to-vh arc.cf arc.cf</i>
148     # <i>dvhtool --unix-to-vh /usr/src/linux/vmlinux new</i>
149     </pre>
150    
151     <p>
152 neysx 1.15 With this done, now all that's left is to set some options in the PROM. See the
153 fox2mike 1.13 section on <uri link="#reboot">Rebooting the System</uri>.
154     </p>
155    
156     </body>
157     </subsection>
158    
159 swift 1.10 </section>
160    
161     <section id="cobalt">
162     <title>Cobalt MicroServers -- Setting Up CoLo</title>
163     <subsection>
164     <title>Installing CoLo</title>
165     <body>
166    
167     <p>
168 neysx 1.15 On Cobalt servers, these machines have a much less capable firmware installed
169     on chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and
170     has a number of serious limitations.
171 swift 1.10 </p>
172    
173     <ul>
174     <li>
175 neysx 1.15 There's a 675kB (approximate) limit on kernels. The current size of Linux
176     2.4 makes it damn near impossible to make a kernel this size. Linux 2.6 is
177 fox2mike 1.13 totally out of the question.
178 swift 1.10 </li>
179     <li>
180     64-bit kernels are not supported by the stock firmware (although these are
181     highly experimental on Cobalt machines at this time)
182     </li>
183     <li>
184     The shell is basic at best
185     </li>
186     </ul>
187    
188     <p>
189 neysx 1.15 To overcome these limitations, an alternative firmware, called <uri
190     link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> (Cobalt Loader) was
191     developed. This is a BOOTROM image that can either be flashed into the chip
192     inside the Cobalt server, or loaded from the existing firmware.
193 swift 1.10 </p>
194    
195     <note>
196     This guide will take you through setting up CoLo so that it is loaded by the
197 neysx 1.15 stock firmware. This is the only truly safe, and recommended way to set up
198     CoLo.
199 swift 1.10 </note>
200    
201     <warn>
202 neysx 1.15 You may, if you wish, flash it into the server, and totally replace the
203     original firmware -- however, you are entirely on your own in that endeavour.
204     Should anything go wrong, you will need to physically remove the BOOTROM and
205     reprogram it yourself with the stock firmware. If you are not sure how to do
206     this -- then <e>DO NOT</e> flash your machine. We take no responsibility for
207     whatever happens if you ignore this advice.
208 swift 1.10 </warn>
209    
210     <p>
211 neysx 1.15 Okay, with the warnings over now, we'll get on with installing CoLo. First,
212 swift 1.10 start by emerging the package.
213     </p>
214    
215     <pre caption="Emerging colo">
216     # <i>emerge colo</i>
217     </pre>
218    
219     <p>
220     With that installed (I hope you read those messages ;-) you should be able to
221     look inside the <path>/usr/lib/colo</path> directory to find two files,
222     <path>colo-chain.elf</path>: the "kernel" for the stock firmware to load, and
223 neysx 1.15 <path>colo-rom-image.bin</path>: a ROM image for flashing into the BOOTROM. We
224 swift 1.10 start by mounting /boot and dumping a compressed copy of
225     <path>colo-chain.elf</path> in <path>/boot</path> where the system expects it.
226     </p>
227    
228     <pre caption="Putting CoLo in its place">
229     # <i>gzip -9vc /usr/lib/colo/colo-chain.elf &gt; /boot/vmlinux.gz</i>
230     </pre>
231    
232     </body>
233     </subsection>
234    
235     <subsection>
236     <title>Configuring CoLo</title>
237    
238     <body>
239    
240     <p>
241     Now, when the system first boots up, it'll load CoLo which will spit up a menu
242 neysx 1.15 on the back LCD. The first option (and default that is assumed after roughly 5
243     seconds) is to boot to the hard disk. The system would then attempt to mount
244 swift 1.10 the first Linux partition it finds, and run the script
245 neysx 1.15 <path>default.colo</path>. The syntax is fully documented in the CoLo
246 swift 1.10 documentation (have a peek at
247     <path>/usr/share/doc/colo-X.YY/README.shell.gz</path> -- where X.YY is the
248     version installed), and is very simple.
249     </p>
250    
251 swift 1.11 <note>
252     Just a tip: when installing kernels, I usually create two kernel images,
253     <path>kernel.gz.working</path> -- a known working kernel, and
254 neysx 1.15 <path>kernel.gz.new</path> -- a kernel that's just been compiled. You can
255     either use symlinks to point to the curent "new" and "working" kernels, or just
256     rename the kernel images.
257 swift 1.11 </note>
258    
259 swift 1.10 <pre caption="A basic default.colo">
260     <comment>#:CoLo:#</comment>
261     mount hda1
262 swift 1.11 load /kernel.gz.working
263 swift 1.10 execute root=/dev/hda3 ro console=ttyS0,115200
264     </pre>
265    
266     <note>
267     CoLo will refuse to load a script that does not begin with the <c>#:CoLo:#</c>
268 neysx 1.15 line. Think of it as the equivalent of saying <c>#!/bin/sh</c> in shell
269 swift 1.10 scripts.
270     </note>
271    
272     <p>
273     It is also possible to ask a question, such as which kernel &amp; configuration
274 neysx 1.15 you'd like to boot, with a default timeout. This configuration does exactly
275 fox2mike 1.13 this, asks the user which kernel they wish to use, and executes the chosen
276 neysx 1.15 image. <path>vmlinux.gz.new</path> and <path>vmlinux.gz.working</path> may be
277 fox2mike 1.13 actual kernel images, or just symlinks pointing to the kernel images on that
278 neysx 1.15 disk. The <c>50</c> argument to <c>select</c> specifies that it should proceed
279 fox2mike 1.13 with the first option ("Working") after 50/10 seconds.
280 swift 1.10 </p>
281    
282     <pre caption="Menu-based configuration">
283     <comment>#:CoLo:#</comment>
284    
285     lcd "Mounting hda1"
286     mount hda1
287 fox2mike 1.13 select "Which Kernel?" 50 Working New
288    
289     goto {menu-option}
290     var image-name vmlinux.gz.working
291     goto 3f
292     @var image-name vmlinux.gz.working
293     goto 2f
294     @var image-name vmlinux.gz.new
295    
296     @lcd "Loading Linux" {image-name}
297     load /{image-name}
298 swift 1.10 lcd "Booting..."
299     execute root=/dev/hda5 ro console=ttyS0,115200
300     boot
301     </pre>
302    
303     <p>
304 fox2mike 1.13 See the documentation in <path>/usr/share/doc/colo-VERSION</path> for more
305     details.
306 swift 1.10 </p>
307 fox2mike 1.13
308 swift 1.10 </body>
309    
310     </subsection>
311     </section>
312    
313     <section>
314     <title>Setting up for Serial Console</title>
315    
316     <subsection>
317     <body>
318    
319     <p>
320     Okay, the Linux installation as it stands now, would boot fine, but assumes
321 neysx 1.15 you're going to be logged in at a physical terminal. On Cobalt machines, this
322 swift 1.10 is particularly bad -- there's no such thing as a physical terminal.
323     </p>
324    
325     <note>
326 neysx 1.15 Those who do have the luxury of a supported video chipset may skip this section
327     if they wish.
328 swift 1.10 </note>
329    
330     <p>
331 neysx 1.15 First, pull up an editor and hack away at <path>/etc/inittab</path>. Further
332 swift 1.10 down in the file, you'll see something like this:
333     </p>
334    
335     <pre caption="inittab Configuration">
336     <comment># SERIAL CONSOLE</comment>
337     <comment>#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102</comment>
338    
339     <comment># TERMINALS</comment>
340     c1:12345:respawn:/sbin/agetty 38400 tty1 linux
341     c2:12345:respawn:/sbin/agetty 38400 tty2 linux
342     c3:12345:respawn:/sbin/agetty 38400 tty3 linux
343     c4:12345:respawn:/sbin/agetty 38400 tty4 linux
344     c5:12345:respawn:/sbin/agetty 38400 tty5 linux
345     c6:12345:respawn:/sbin/agetty 38400 tty6 linux
346    
347     <comment># What to do at the "Three Finger Salute".</comment>
348     ca:12345:ctrlaltdel:/sbin/shutdown -r now
349 swift 1.1 </pre>
350    
351     <p>
352 neysx 1.15 First, uncomment the <c>c0</c> line. By default, it's set to use a terminal
353     baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200
354     to match the baud rate decided by the BOOT ROM. This is how that section looks
355     on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend
356     commenting out the local terminal lines (<c>c1</c> through to <c>c6</c>) as
357     these have a habit of misbehaving when they can't open <path>/dev/ttyX</path>.
358 swift 1.1 </p>
359    
360 swift 1.10 <pre caption="Example snippet from inittab">
361     <comment># SERIAL CONSOLE</comment>
362     c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102
363    
364     <comment># TERMINALS -- These are useless on a headless qube</comment>
365     <comment>#c1:12345:respawn:/sbin/agetty 38400 tty1 linux</comment>
366     <comment>#c2:12345:respawn:/sbin/agetty 38400 tty2 linux</comment>
367     <comment>#c3:12345:respawn:/sbin/agetty 38400 tty3 linux</comment>
368     <comment>#c4:12345:respawn:/sbin/agetty 38400 tty4 linux</comment>
369     <comment>#c5:12345:respawn:/sbin/agetty 38400 tty5 linux</comment>
370     <comment>#c6:12345:respawn:/sbin/agetty 38400 tty6 linux</comment>
371     </pre>
372    
373 swift 1.1 <p>
374 swift 1.10 Now, lastly... we have to tell the system, that the local serial port can be
375 neysx 1.15 trusted as a secure terminal. The file we need to poke at is
376     <path>/etc/securetty</path>. It contains a list of terminals that the system
377     trusts. We simply stick in two more lines, permitting the serial line to be
378 swift 1.10 used for <c>root</c> logins.
379 swift 1.2 </p>
380    
381 swift 1.10 <pre caption="Enabling root logins on serial console">
382     <comment>(/dev/ttyS0 -- the traditional name for the first serial port)</comment>
383     # <i>echo 'ttyS0' >> /etc/securetty</i>
384    
385     <comment>(Lately, Linux also calls this /dev/tts/0 -- so we add this
386     too)</comment>
387     # <i>echo 'tts/0' >> /etc/securetty</i>
388     </pre>
389    
390 swift 1.2 </body>
391     </subsection>
392     </section>
393 swift 1.10
394 cam 1.3 <section id="reboot">
395 swift 1.2 <title>Rebooting the System</title>
396     <subsection>
397     <body>
398    
399     <p>
400 neysx 1.15 Exit the chrooted environment and unmount all mounted partitions. Then type in
401 swift 1.2 that one magical command you have been waiting for: <c>reboot</c>.
402     </p>
403    
404     <pre caption="Exiting the chroot, unmounting all partitions and rebooting">
405     # <i>exit</i>
406 swift 1.4 cdimage ~# <i>cd</i>
407 neysx 1.12 cdimage ~# <i>umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo</i>
408 swift 1.2 cdimage ~# <i>reboot</i>
409     </pre>
410    
411 swift 1.10 <note>
412     <e>Cobalt Users:</e> The rest of this section covers the setting up of the SGI
413 neysx 1.17 PROM so that it boots <c>arcload</c> off disk and loads
414 nightmorph 1.16 Linux.
415 neysx 1.15 This is not applicable to the setup of Cobalt servers. In fact, all your work
416 fox2mike 1.13 is done -- there is no configuration needed for the first boot up, you can skip
417     to the next section: <uri link="?part=1&amp;chap=11">Finalising your Gentoo
418 swift 1.10 Installation</uri>
419     </note>
420    
421 swift 1.2 </body>
422     </subsection>
423     </section>
424     <section>
425 swift 1.10 <title>Tweaking the SGI PROM</title>
426 swift 1.2 <subsection>
427 fox2mike 1.13 <title>Setting generic PROM settings</title>
428 swift 1.2 <body>
429    
430     <p>
431 fox2mike 1.13 Now that you've installed the bootloader, you're ready to reboot the machine.
432     </p>
433    
434     <pre caption="Rebooting">
435     <comment>(Exit the chroot environment)</comment>
436     # <i>exit</i>
437    
438     <comment>(Unmount the drives)</comment>
439     # <i>umount /gentoo/boot</i>
440     # <i>umount /gentoo</i>
441    
442     <comment>(Reboot)</comment>
443     # <i>reboot</i>
444     </pre>
445    
446     <p>
447 neysx 1.15 When you are rebooted, go to the <e>System Maintenance Menu</e> and select
448 fox2mike 1.13 <e>Enter Command Monitor</e> (<c>5</c>) like you did when you netbooted the
449     machine.
450 swift 1.2 </p>
451    
452     <pre caption="Configuring the PROM to Boot Gentoo">
453     1) Start System
454     2) Install System Software
455     3) Run Diagnostics
456     4) Recover System
457     5) Enter Command Monitor
458    
459     Option? <i>5</i>
460 neysx 1.15 Command Monitor. Type "exit" to return to the menu.
461 swift 1.2
462 nightmorph 1.16 <comment>(Set some options for arcload)</comment>
463 fox2mike 1.13
464     <comment>(Provide the location of the Volume Header)</comment>
465     &gt;&gt; <i>setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)</i>
466    
467     <comment>(Automatically boot Gentoo)</comment>
468     &gt;&gt; <i>setenv AutoLoad Yes</i>
469    
470     <comment>(Set the timezone)</comment>
471     &gt;&gt; <i>setenv TimeZone EST5EDT</i>
472    
473     <comment>(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))</comment>
474     &gt;&gt; <i>setenv console d1</i>
475    
476 nightmorph 1.16 <comment>(Setting the serial console baud rate. This is optional, 9600 is the )
477 neysx 1.15 (default setting, although one may use rates up to 38400 if that is desired. )</comment>
478 fox2mike 1.13 &gt;&gt; <i>setenv dbaud 9600</i>
479     </pre>
480    
481     <p>
482     Now, the next settings depend on how you are booting the system.
483     </p>
484    
485     </body>
486     </subsection>
487    
488     <subsection>
489     <title>Settings for direct volume-header booting</title>
490     <body>
491    
492     <p>
493 neysx 1.15 This is covered here for completeness. It's recommended that users look into
494 nightmorph 1.16 installing <c>arcload</c> instead.
495 fox2mike 1.13 </p>
496    
497     <note>
498     This only works on the Indy, Indigo2 (R4k) and Challenge S.
499     </note>
500    
501     <pre caption="PROM settings for booting off the volume header">
502 swift 1.2 <comment>(&lt;root device&gt; = Gentoo's root partition, e.g. /dev/sda3)</comment>
503     &gt;&gt; <i>setenv OSLoadPartition &lt;root device&gt;</i>
504    
505     <comment>(To list the available kernels, type "ls")</comment>
506     &gt;&gt; <i>setenv OSLoader &lt;kernel name&gt;</i>
507     &gt;&gt; <i>setenv OSLoadFilename &lt;kernel name&gt;</i>
508    
509     <comment>(Declare the kernel parameters you want to pass)</comment>
510     &gt;&gt; <i>setenv OSLoadOptions &lt;kernel parameters&gt;</i>
511 fox2mike 1.13 </pre>
512    
513     <p>
514     If you wish to try a kernel without messing with kernel parameters, you may do
515     so using the <c>boot -f</c> PROM command:
516     </p>
517 swift 1.2
518 fox2mike 1.13 <pre caption="Booting without changing environment variables">
519     <comment>(Booting a kernel, "new", with additional options)</comment>
520     # <i>boot -f new root=/dev/sda3 ro</i>
521     </pre>
522    
523     </body>
524     </subsection>
525    
526     <subsection>
527     <title>Settings for arcload</title>
528     <body>
529    
530     <p>
531 neysx 1.15 <c>arcload</c> uses the <c>OSLoadFilename</c> option to specify which options
532     to set from <path>arc.cf</path>. The configuration file is essentially a
533     script, with the top-level blocks defining boot images for different systems,
534     and inside that, optional settings. Thus, setting
535     <c>OSLoadFilename=mysys(serial)</c> pulls in the settings for the <c>mysys</c>
536     block, then sets further options overridden in <c>serial</c>.
537 fox2mike 1.13 </p>
538    
539     <p>
540     In the example file above, we have one system block defined, <c>ip28</c> with
541 neysx 1.15 <c>working</c>, <c>new</c> and <c>debug</c> options available. We define our
542 fox2mike 1.13 PROM variables as so:
543     </p>
544    
545     <pre caption="PROM settings for using arcload">
546     <comment>(Select arcload as the bootloader:- sash64 or sashARCS)</comment>
547 neysx 1.17 &gt;&gt; <i>setenv OSLoader sash64</i>
548 fox2mike 1.13
549     <comment>(Use the "working" kernel image, defined in "ip28" section of arc.cf)</comment>
550 neysx 1.17 &gt;&gt; <i>setenv OSLoadFilename ip28(working)</i>
551 fox2mike 1.13 </pre>
552    
553     <p>
554 neysx 1.17 Starting with <c>arcload-0.5</c>, files no longer need to be placed in the
555     volume header -- they may be placed in an EXT2/3 partition instead. To tell
556     <c>arcload</c> where to look for its configuration file and kernels, one must
557     set the <c>OSLoadPartition</c> PROM variable. The exact value here will depend
558     on where your disk resides on the SCSI bus. Use the <c>SystemPartition</c> PROM
559     variable as a guide -- only the partition number should need to change.
560 fox2mike 1.13 </p>
561    
562 neysx 1.17 <note>
563     Partitions are numbered starting at 0, not 1 as is the case in Linux.
564     </note>
565 swift 1.2
566 neysx 1.17 <pre caption="Telling arcload where to find arc.cf">
567     <comment>(If you wish to load from the volume header -- use partition 8)</comment>
568     &gt;&gt; <i>setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)</i>
569 swift 1.2
570 neysx 1.17 <comment>(Otherwise, specify the partition and filesystem type)</comment>
571     &gt;&gt; <i>setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]</i>
572 swift 1.2 </pre>
573    
574 fox2mike 1.13 </body>
575 neysx 1.17 </subsection>
576 fox2mike 1.13
577     <subsection>
578     <title>All Done</title>
579     <body>
580    
581 swift 1.2 <p>
582 neysx 1.15 Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and finish
583     up with <uri link="?part=1&amp;chap=11">Finalizing your Gentoo
584 swift 1.2 Installation</uri>.
585 swift 1.1 </p>
586    
587     </body>
588     </subsection>
589     </section>
590     </sections>

  ViewVC Help
Powered by ViewVC 1.1.20