[gentoo-mips] Qube2 can't load CoLo

[gentoo-mips] Qube2 can't load CoLo

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

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
| 
|  1.LCD Test................................PASS
|  2.Controller Test.........................PASS
|  5.Bank 0:.................................64M
|  6.Bank 1:.................................64M
|  7.Bank 2:.................................64M
|  8.Bank 3:.................................64M
|  9.Serial Test.............................PASS
| 10.PCI Expansion Slot....................**Unknown Card**
| 12.IDE Test................................PASS
| 13.Ethernet Test...........................PASS
| 16.RTC Test................................PASS
| 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 ***

My hda1 looks like this:
| (none) etc # mount /boot
| (none) etc # ls -l /boot
| total 1152
| -rw-r--r-- 1 root root     353 Jan  1  2000 default.colo
| -rwxr-xr-x 1 root root 1098628 May 15  2007 kernel-2.6.17.14-mips.gz
| drwx------ 2 root root   12288 Jan  1  2000 lost+found
| -rw-r--r-- 1 root root   59614 Jan  1 01:07 vmlinux.gz
| lrwxrwxrwx 1 root root      24 May 15  2007 vmlinux.gz.working -> kernel-2.6.17.14-mips.gz

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?

cheers!
	Matthias
-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Kumba]

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

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

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]

Hi Kumba,
on Thursday, 2007-05-17 at 02:40:32, you wrote:
> 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.

Thanks for the encouragement---I had been too chicken to try it yet as
the manual said to make sure the chainloading version works first.
Actually I even have a flasher but I'd have to install Windows for it in
case it screwed my flash chip, so... :)
Anyway, I tried and it worked flawlessley in a matter of seconds. Kudos
to Colonel Panic! It's still dropping me to the boot menu to load the
kernel by hand but I think that has got to do with my default.colo file,
have to check it once my new kernel compile has finished.

> 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.

The error message says:
|  * Mounting /dev for udev ...[ oops ]
| 
| 
|  * The "mount" command failed with error:
| 
| wrong fs type, bad option, bad superblock on udev,
|        missing codepage or other error
|        In some cases useful info is found in syslog - try
|        dmesg | tail  or so
| 
|  * Since this is a critical task, startup cannot continue.
My glibc is 2.3.6-r4, it's all still the original 2007.0 install image
from redhatter. But I'm quite sure that's not the problem, this looks
pretty much like a problem I had on a HPPA box a while ago. I had
disabled support for hotplug devices in the kernel since it's a server
and I thought I didn't need it. Afterwards, udevd wouldn't start any
more, complaining about some missing netlink functionality, I don't
remember exactly what it was.
On the Qube I should have dumped the config from the netbooted
installation kernel but went with "make cobal_defconfig" first, which I
found later has no hotplug support either. So I'm pretty confident it
will work once I have the new kernel compiled (it's going through the
whole 2h procedure right now because I forgot to set the clock last time
8-]). I'll post my result when I have any.

cheers!
	Matthias
-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Andrew Gaffney]

Matthias Bethke wrote:
> The error message says:
> |  * Mounting /dev for udev ...[ oops ]
> | 
> | 
> |  * The "mount" command failed with error:
> | 
> | wrong fs type, bad option, bad superblock on udev,
> |        missing codepage or other error
> |        In some cases useful info is found in syslog - try
> |        dmesg | tail  or so

That sounds suspiciously like you forgot to enable tmpfs support in your kernel.

-- 
Andrew Gaffney                                 http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer             Catalyst/Installer + x86 release coordinator
-- 
gentoo-mips@gentoo.org mailing list

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

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Hi Andrew,
on Thursday, 2007-05-17 at 06:47:39, you wrote:
> That sounds suspiciously like you forgot to enable tmpfs support in your 
> kernel.

Indeed, that's what it was 8-] It's working just fine now, thanks!
I'm still fighting with the recent 2.6.20 as it doesn't seem to
recognize my disk, but 2.6.17 is fine as well so far. Just dm-crypt is
*very* strange:
| cryptsetup  -s256 luksFormat /dev/hda5
| 
| WARNING!
| ========
| This will overwrite data on /dev/hda5 irrevocably.
| 
| Are you sure? (Type uppercase yes): YES
| Enter LUKS passphrase:
| Verify passphrase:
| Command successful.
| ann ~ # cryptsetup luksDump /dev/hda5
| automatic header conversion from 0.99 to 0.991 triggeredLUKS header information for /dev/hda5
| 
| Version:        1
| Cipher name:    aes
| Cipher mode:    cbc-essiv:sha256
| Hash spec:      sha1
| Payload offset: 2056
| MK bits:        256
| MK digest:      0a 1d c0 9b 6a 49 38 d1 f2 44 d4 e6 7e 53 2e 06 54 5d b7 9e
| MK salt:        7b 88 7b 2a 7a 46 5c 97 72 93 3a 13 be db 61 f9
|                 9c ca fb 60 fb d3 86 d2 67 aa e9 c5 9a 3b e8 62
| MK iterations:  0
| UUID:           d3001762-dede-4634-aaf5-9005c34702b0
| 
| Key Slot 0: ENABLED
|         Iterations:             11658
|         Salt:                   c9 0c 45 1f b5 83 46 ee 4f 09 10 f9 b6 40 8e ea
|                                 76 62 e3 f3 ed dc 4f 93 f4 ac 89 91 b0 83 26 55
|         Key material offset:    8
|         AF stripes:             4000
| Key Slot 1: DISABLED
| Key Slot 2: DISABLED
| Key Slot 3: DISABLED
| Key Slot 4: DISABLED
| Key Slot 5: DISABLED
| Key Slot 6: DISABLED
| Key Slot 7: DISABLED
| ann ~ # cryptsetup luksDump /dev/hda5
| /dev/hda5 is not a LUKS partition
| Command failed.

/dev/hda5 is not mounted or anything, and the second luksDump command
came just a second after the first one. WTF?!

And BTW, HD performance leaves much to be desired---is this normal for
a 250 MHz MIPS? My 68040/40 Amiga did not much worse over its 7 MHz bus:
| ann ~ # dd if=/dev/zero bs=1M of=/dev/hda5
| dd: writing `/dev/hda5': No space left on device
| 1871+0 records in
| 1870+0 records out
| 1961132544 bytes (2.0 GB) copied, 208.289 s, 9.4 MB/s
| ann ~ # hdparm /dev/hda
| 
| /dev/hda:
| multcount    = 32 (on)
| IO_support   =  1 (32-bit)
| unmaskirq    =  1 (on)
| using_dma    =  1 (on)
| keepsettings =  0 (off)
| readonly     =  0 (off)
| readahead    = 256 (on)
| geometry     = 19846/16/63, sectors = 20005650, start = 0

I was planning to put a partly crypted drive from my HPPA box in there,
and I hoped at about twice the clock it would perform better...

cheers!
	Matthias
-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]