Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 86054 - gentoo handbook instructions for cobalt(mips) errors
Summary: gentoo handbook instructions for cobalt(mips) errors
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Stuart Longland (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 85762
  Show dependency tree
 
Reported: 2005-03-20 13:48 UTC by Dave Andruczyk
Modified: 2005-03-30 00:06 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Updates to the Netbooting & Bootloader sections (bug_86054_fix.diff,5.64 KB, patch)
2005-03-20 16:34 UTC, Stuart Longland (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Andruczyk 2005-03-20 13:48:48 UTC
On the mips install handbook there are several errors specific to the cobalt port...

The default instructions relating to the NFSroot setup, fail to mention the creation of a symlink needed for the cobalt to boot.

a "ln -sf . boot" inside of the /nfsroot folder on the nfs hosting machine creates the appropriate path.  when netbooting the cobalt is searching for "/boot/cobalt_raq-2800.gz" and without the boot symlink it can't find the file and panics.

The handbook recommends the latest version of colo , which at this time is 1.17. This version FAILED on my cobalt (A Gateway Microserver, RAQ2 equivalent supposedly),  but version 1.16 worked.

Later in the handbook, is a little confusions about setting up colo, as the default unmasked colo ebuild is versions 1.11,  but the manual suggests:

Code Listing 9: Menu-based configuration

#:CoLo:#

lcd "Mounting hda1"
mount hda1
menu "Which Kernel?" 50 Working working New new
lcd "Loading Linux" {menu-option}
load /vmlinux.gz.{menu-option}
lcd "Booting..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot

"menu" isn't a valid command in colo-1.11,  it IS however in colo-1.13 which is currently masked but works OK on my system.

Another tidbit of confusion is where the handbook states to run "gzip -9vc colo-chain.elf >/boot/vmlinux.gz"  And then says to copy the kernel across as vmlinux-x.y.z.  The default.colo menu seems to imply that the kernel needs to be compressed, but the docs didn't say to do that, nor do the names used for the kernel and the colo examples match (they NEED TO for it to boot), so some cleanup is in order there as well..

The handbook also states to mount the cobalt's partitions under /mnt/gentoo, on the default nfsroot image, there IS NO /mnt/gentoo on that image, on my setup the ly writable area I could find was /dev/shm, so I ended up making /dev/shm/mnt/gentoo and mounting things there to get the install done.

All in all I did manege to get gentoo up on the cobalt.
Comment 1 Dave Andruczyk 2005-03-20 13:54:01 UTC
NOTE: found another error, the handbooks says to mount the filesystems under /mnt/gentoo,   it should be "/gentoo" instead.  ignore my other notes about the RO/RW problem.  I never even noticed the "gentoo directory" on the netboot the first time..

Comment 2 Stuart Longland (RETIRED) gentoo-dev 2005-03-20 16:34:06 UTC
Created attachment 54001 [details, diff]
Updates to the Netbooting & Bootloader sections

Hi Dave, Replying inline ;-)

> The default instructions relating to the NFSroot setup, fail to mention the 
> creation of a symlink needed for the cobalt to boot.
> 
> a "ln -sf . boot" inside of the /nfsroot folder on the nfs hosting machine
> creates the appropriate path.  when netbooting the cobalt is searching for
> "/boot/cobalt_raq-2800.gz" and without the boot symlink it can't find the
file
> and panics.

Thanks for that -- it seems I missed that when I created the first version of
the document.  This has been fixed. :-)

> The handbook recommends the latest version of colo , which at this time is
> 1.17. This version FAILED on my cobalt (A Gateway Microserver, RAQ2
equivalent
> supposedly),	but version 1.16 worked.

At the time of writing, v1.13/1.14 was the latest version of CoLo -- there were
no known issues with these versions.  I've added a note suggesting people try
earlier versions if they strike problems.

(BTW: The RaQ 2 is the rackmounted cousin of the Qube 2.  The Gateway
Microserver is simply an OEM-branded version of the Qube 2.)

> Later in the handbook, is a little confusions about setting up colo, as the
> default unmasked colo ebuild is versions 1.11,  but the manual suggests...

I provided two possible configurations, a simple one, and the menu-driven one. 
The menu-driven one will only work in CoLo v1.12 and v1.13.  I'll put up a new
version for CoLo 1.14 and later when it's available via Portage.

CoLo 1.13 will probably be marked stable in the near future -- and we're
looking at including v1.16 in ~mips.

> Another tidbit of confusion is where the handbook states to run "gzip -9vc
> colo-chain.elf >/boot/vmlinux.gz"  And then says to copy the kernel across as

> vmlinux-x.y.z.  The default.colo menu seems to imply that the kernel needs to

> be compressed, but the docs didn't say to do that, nor do the names used for
> the kernel and the colo examples match (they NEED TO for it to boot), so some

> cleanup is in order there as well..

No worries, I've altered the CoLo examples to use 'kernel.gz.working' and
'kernel.gz.new' to be consistent with the kernel section, with a tip to symlink
or rename the kernels to one of those two names.

I've also made a note in the kernel section that kernels need to be compressed
on Cobalt servers.

> The handbook also states to mount the cobalt's partitions under /mnt/gentoo,
> on the default nfsroot image, there IS NO /mnt/gentoo on that image, on my
> setup the ly writable area I could find was /dev/shm, so I ended up making
> /dev/shm/mnt/gentoo and mounting things there to get the install done.

Yeah... the x86 and other installation media use /mnt/gentoo as the mountpoint.
 However a lot of us MIPS developers are used to putting mountpoints in / not
/mnt, and hence the habit stuck when the netboot images were created.  This
will get fixed in the next version of the netboot image.

You can view the latest updates at the following address:
http://www.longlandclan.hopto.org/~stuartl/gentoo/docs/index.php/gentoo-doc/en/handbook/handbook-mips.xml


Hopefully one of the official documentation developers will commit the attached
patch shortly.	If you've got any queries -- I'm on the #gentoo-mips IRC
channel, feel free to pester me there.	(just bear in mind the timezone -- I'm
running GMT+10 ;-)
Comment 3 Dave Andruczyk 2005-03-20 17:34:03 UTC
Ok thanks for the fast fixes.  I checked it over and remembered a couple things  I forgot to mention:

1: the handbook shows a fairly long procedure for netbooting,  for me with colo-1.16 it provides a simple menu on the cobalt's LCD, choices being bood from the disk, NFS or TFTP,  if you just scroll down and select NFS the boot happens,  no need to enter in all those commands at the colo bootshell.
I assume this functionality wasn't in colo at the original time of doc writing

2.  in the kernel and bootloader sections, you might want to make things "line up" name wise.  in the kernel section ,you might want to change the section regarding copying the kernel to /boot ,adding the notes about compressing it is required for cobalt, and your ".working", ".new" naming scheme and add a note sayingto check in the bootloader section for more info.  Same thing in the bootloader section,  emphasize that the kernel MUST be compressed with gzip, otherwise some unsuspecting new user might just rename the kernel they just built with a .gz extension and wonder why it doesn't work.
 

Comment 4 Stuart Longland (RETIRED) gentoo-dev 2005-03-29 15:08:35 UTC
Could someone with CVS access please apply the attached patch?  It needs to be applied before the attachment in bug #85762 otherwise things will get h0rked up rather badly.  (In fact, I doubt the patch will apply)

Either that, or could we go through the recruitment process, that way I can apply the patches myself.
Comment 5 Sven Vermeulen (RETIRED) gentoo-dev 2005-03-29 23:31:26 UTC
I'll get it committed... hold on...
Comment 6 Sven Vermeulen (RETIRED) gentoo-dev 2005-03-29 23:56:40 UTC
They're committed. You can close the bug if that's all.
Comment 7 Stuart Longland (RETIRED) gentoo-dev 2005-03-30 00:06:26 UTC
Thanks. :-)