Re: [gentoo-mips] Qube2 can't load CoLo

[Kumba <kumba@gentoo.org>]

Matthias Bethke wrote:
> It's been quiet on this list for a while, eh? Here's a question for Qube
> owners: 
> I've been trying to get Gentoo running on my Qube 2, and while
> things seem to work fine with minor glitches so far, I can't get the
> CoLo chainloading to work. I've netbooted the box, CoLo loads fine from
> NFS, loads my kernel, I've done all the installation of the base system,
> and now I'm trying to get the Qube to boot on its own. What does work is
> to netboot again so the CoLo image gets pulled from NFS, and then have
> CoLo load and boot my kernel from disk by hand (it runs into problems
> trying to start udev but I think I can get this fixed later, with
> init=/bin/bash it's fine so far). It doesn't however want to load CoLo
> from the boot partition:
> | Cobalt Microserver Diagnostics - 'We serve it, you surf it'
> | Built Tue May 25 15:58:41 PDT 1999
> | 

[snip]

> | BOOTLOADER ramcode: selected partition /dev/hda1
> | Decompressing done
> | Executing bootloader kernel...
> | Jump_to_Real_Kernel: disk error, trying BFD again
> | BOOTLOADER ramcode: selected partition /dev/hdc1
> | Decompressing - done
> | Executing bootloader kernel...
> | Jump_to_Real_Kernel: disk error, trying BFD again
> | get_root_dev: nr_boot_failures 0x00000002 exceeds maxtries 0x00000002 for boot_index 0x00000000
> | 
> | 
> |  *** halting ***

[snip]

> 
> It is an ext2r0 partition and vmlinux.gz is the zipped colo-chain.elf.
> I'm not sure about who writes what message in that console dump but it
> seems to me that CoLo isn't even being loaded. Otherwise I should get a
> menu on the console in case it couldn't find the kernel or something,
> right?

Even though I've not messed with my RaQ2 in ages, that is indeed an odd error 
from the old cobalt ROM.  What kind of hard drive do you have?, maybe some bunk 
data is stored in the MBR that's throwing the bootloader off?  IMHO, the old 
bootloader/ROM is a flaky, hunk of garbage anyways.  You can always try flashing 
colo directly to the ROM chip.  Just keep it on an UPS for safety, and colo 
itself should be more than stable enough to handle that.

Your udev errors, what do they entail?  I've been keeping an eye out for people 
running 2.6.17 kernels and having problems with userland.  I'm curious to know 
what glibc revision you have merged.  I've got a nagging suspicion we may be 
about to hit into an upgrade path issue that i ran into on my Octane, but have 
yet to ascertain whether it was specific to me or not.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-mips@gentoo.org mailing list