Cobalt RaQ/Qube Systems -- Testing Needed

[Kumba]

Okay, a few people have been inquiring about this for quite some time, and I have good news that the RaQ2 and Qube2 Cobalt models can run Gentoo.

One of the primary hurdles that needed overcoming was the network driver (it was a bit flaky in modern kernels). It'd randomly timeout/shutdown/etc.. after some measure of network activity. Turns out this issue was not the tulip driver itself (As I had thought), but rather the Galileo PCI chip (and its driver). There's a patch that fixes it now (credit goes to Peter Horton), and I was finally able to get some gentoo stages that had been sitting on my RaQ2 off and uploaded.

There's still the issue of the kernel size limitation, so 2.6 kernels are out of the question for now. There's a bootloader being coded, but it requires re-flashing the cobalt-rom, not something everyone is keen on doing, I'm sure.

Anyways, the main things:

• First, there is no installation guide for these systems. I haven't decided if I'm going to write a separate install guide for Cobalt systems, or re-arrange the existing Gentoo/MIPS Install guide to fit cobalt-specific things in it, so if you plan on trying this, make sure you know how to install gentoo manually. This is not a n00b-friendly procedure, and it is thusly advised that anyone not familiar with installing gentoo on a semi-unsupported system to stay far away.
• There is no gentoo netboot yet. Cobalt netboots are a bit different than the SGI versions. The SGI ones can simply have the initrd embedded within the kernel, whereas the cobalt ones need the initrd fetched and mounted via NFS. I haven't tried this yet, and have no idea when I'll get around to doing so.
• No guarantees. This machine's support is experimental right now. A few people have manually installed gentoo on these systems, but probably not without dealing with hurdles. Hopefully the stages I have will help in this endeavour.

Now, the fun parts:

• Stages are available here:
  http://dev.gentoo.org/~kumba/mips/cobalt/stages/200401/
• Kernel:
  Cobalt systems will use mips-sources, however the kernel needs several patches in order to work properly. I'll be adding these patches to mips-sources-2.4.21, 2.4.22, and 2.4.23 shortly. In the meantime, those curious as to what these patches are and what they do, look here and scan the README file:
  http://dev.gentoo.org/~kumba/mips/cobalt/patches/
  
  I've also uploaded a config for a mips-sources-2.4.22 kernel, as well as a kernel already compiled (with a modules tarball). This kernel has all the patches mentioned above applied. You can find this here:
  http://dev.gentoo.org/~kumba/mips/cobalt/kernel/
  (Unpack the tarball in /, as it'll dump everything into lib/modules/2.4.22-20031015).
• LCD Panel:
  I'll be adding utilities for writing text to the front LCD panels and reading button input shortly. These utilities will be available in sys-apps/lcdutils in the Portage tree. Please note that in order to merge this package on a cobalt, you will need to symlink /etc/make.profile to /usr/portage/profiles/cobalt-mips-1.4. (The profiles will be undergoing a name change soon, I'll re-post more info when this happens). If you aren't using this profile, the package will error out on you (I rigged it to do so).
• Gentoo make.conf:
  For convience, I've also uploaded a sample /etc/make.conf to my dev site as well. These machines are little-endian, not big-endian like their larger SGI cousins. Keep this in mind.
  http://dev.gentoo.org/~kumba/mips/cobal ... /make.conf

Those interested in assisting on getting this machine to work better, let me know, either here, via email, or on IRC (irc.freenode.net, #gentoo-mips). Given time, this should help make these kinds of machines more useful (Newer kernels, newer tools == fun!).


--Kumba



uname -a:

Code: Select all

Linux udun 2.4.22-mipscvs-20031015 #3 Sat Jan 31 22:52:19 EST 2004 mips Nevada V10.0  FPU V10.0 MIPS Cobalt GNU/Linux

dmesg:

Code: Select all

CPU revision is: 000028a0
FPU revision is: 000028a0
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB 2-way, linesize 32 bytes.
Linux version 2.4.22-mipscvs-20031015 (root@isengard) (gcc version 3.3.2) #3 Sat Jan 31 22:52:19 EST 2004
Determined physical RAM map:
 memory: 09000000 @ 00000000 (usable)
On node 0 totalpages: 36864
zone(0): 36864 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,115200 root=/dev/hda5
Calibrating delay loop... 249.03 BogoMIPS
Memory: 143708k/147456k available (1303k kernel code, 3748k reserved, 96k data, 76k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Cobalt Board ID: 6
Activating ISA DMA hang workarounds.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
Cobalt LCD Driver v2.10
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xc800000 (irq = 7) is a ST16650V2
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.10f
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
PCI: Enabling device 00:07.0 (0045 -> 0047)
tulip0: Old format EEPROM on 'Cobalt Microserver' board.  Using substitute media control info.
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #1 config 1000 status 7809 advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xb2000000, 00:10:E0:00:26:DC, IRQ 4.
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci00:09.1
    ide0: BM-DMA at 0xcc00-0xcc07, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdc:pio, hdd:pio
hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive
hdb: WDC WD200BB-75AUA1, ATA DISK drive
blk: queue 80215680, I/O limit 4095Mb (mask 0xffffffff)
blk: queue 802157c0, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 6306048 sectors (3229 MB) w/418KiB Cache, CHS=6256/16/63, UDMA(33)
hdb: attached ide-disk driver.
hdb: host protected area => 1
hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(33)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 >
 /dev/ide/host0/bus0/target1/lun0: p1 p2 p3
Initializing Cryptographic API
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 76k freed
Adding Swap: 524276k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,5), internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,66), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.

/proc/cpuinfo:

Code: Select all

system type             : MIPS Cobalt
processor               : 0
cpu model               : Nevada V10.0  FPU V10.0
BogoMIPS                : 249.03
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 48
extra interrupt vector  : yes
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

[Redhatter]

This is good news...I'll suffer with apt/dpkg no longer. (Yes, it has its good points, but it has its bad ones too). I might look into dropping an alternate hard drive in, and installing Gentoo on the Qube I have here.

Have you got a link to this cobalt bootloader? I'd be interested in having a look. Whilst I normally don't like flashing firmware (I've had it blow up in my face once before), in this case, being able to boot a larger kernel would be worthwhile.

Given the difference between Cobalt & SGI systems, I'd probably do a second document. On cobalt systems, there's the 620kB kernel size limit & a PROM that only understands EXT2 revision 0 to contend with -- there's no such restriction on SGI platforms (as far as I know).

With reguard to the LCD -- here's an idea.

Why not do this in an architecture independant manner so that the scripts can also make use of LCD4Linux? E.g. in rc.conf, have a configuration option:

Code: Select all

# LCD_BOOT_STATUS = "(cobalt|lcd4linux|off)"
# Display the status of the bootup (e.g. starting/stopping services, etc) on an LCD display.
# On Cobalt Qube & Raq systems, set to 'cobalt' to use the LCD panels built into these systems.
# If you have a LCD4Linux compatable LCD panel, set this to 'lcd4linux'
# To disable, set to 'off'
LCD_BOOT_STATUS = "cobalt"

[Kumba]

This is good news...I'll suffer with apt/dpkg no longer. (Yes, it has its good points, but it has its bad ones too). I might look into dropping an alternate hard drive in, and installing Gentoo on the Qube I have here.

Have you got a link to this cobalt bootloader? I'd be interested in having a look. Whilst I normally don't like flashing firmware (I've had it blow up in my face once before), in this case, being able to boot a larger kernel would be worthwhile.

It's not been released yet by its author, Peter Horton. He's got a boot loader (2 stage it looks), and a flash utilitiy. According to him, disk booting works pretty well, but network booting hasn't been implemented yet. It also eliminates the ~675KB limit on kernels, allowing for up to ~8MB kernels to be booted. He's looking for testers too, so look at this page here for an email and some more details: http://www.colonel-panic.org/cobalt-mips/

Given the difference between Cobalt & SGI systems, I'd probably do a second document. On cobalt systems, there's the 620kB kernel size limit & a PROM that only understands EXT2 revision 0 to contend with -- there's no such restriction on SGI platforms (as far as I know).

With reguard to the LCD -- here's an idea.

Why not do this in an architecture independant manner so that the scripts can also make use of LCD4Linux? E.g. in rc.conf, have a configuration option:

Code: Select all

# LCD_BOOT_STATUS = "(cobalt|lcd4linux|off)"
# Display the status of the bootup (e.g. starting/stopping services, etc) on an LCD display.
# On Cobalt Qube & Raq systems, set to 'cobalt' to use the LCD panels built into these systems.
# If you have a LCD4Linux compatable LCD panel, set this to 'lcd4linux'
# To disable, set to 'off'
LCD_BOOT_STATUS = "cobalt"

A good idea perhaps. I haven't yet figured out to best merge LCD status lines into baselayout yet. Most likely, it'll be a patch to baselayout that only gets applied if the machine uses the cobalt-mips profile (which has a variable to check against). With only 16charsx2lines on the RaQ2/Qube2 LCD panel, things will have to be thought out well to make sure any text printed will fit. Not to mention other packages which have their own /etc/init.d files.

As for LCD4linux, have you tested this with sobalt systems? The lcdutils I have are aimed at the mips-cobalt line, but I believe also work on the Qube3 as well.


--Kumba

[Redhatter]

It's not been released yet by its author, Peter Horton. He's got a boot loader (2 stage it looks), and a flash utilitiy. According to him, disk booting works pretty well, but network booting hasn't been implemented yet. It also eliminates the ~675KB limit on kernels, allowing for up to ~8MB kernels to be booted. He's looking for testers too, so look at this page here for an email and some more details: http://www.colonel-panic.org/cobalt-mips/

Ahh okay, I've just bookmarked that page -- I'll leave it a while until there's some netboot support first, as this is my primary way of loading software -- I've got it set up just nicely now, and holding down two buttons is much easier than undoing the dozens (well, actually 14, but it seems like dozens) of screws to pull out the HDD and plugging it into another box.

A good idea perhaps. I haven't yet figured out to best merge LCD status lines into baselayout yet. Most likely, it'll be a patch to baselayout that only gets applied if the machine uses the cobalt-mips profile (which has a variable to check against). With only 16charsx2lines on the RaQ2/Qube2 LCD panel, things will have to be thought out well to make sure any text printed will fit. Not to mention other packages which have their own /etc/init.d files.

As for LCD4linux, have you tested this with sobalt systems? The lcdutils I have are aimed at the mips-cobalt line, but I believe also work on the Qube3 as well.

This is a good point, as the LCD panels that you can get for LCD4Linux can vary in size. Whilst tiny, the Cobalt LCD panels make it easy by being a standard size.

The Debian init script patches just put up 'Booting...' on the top line and 'SERVICE start' on the bottom line, which is relatively simple -- and works fine so long as the service name isn't too long. This could be done inside /sbin/runscript fairly easy. Perhaps a more Gentoo-like way of doing this would be:

Code: Select all

 During execution   :      On Success      :      On Failure
,----------------.  :  ,----------------.  :  ,----------------.
|ACTION...       |  :  |ACTION...       |  :  |ACTION...       |
|SERVICE         |  :  |SERVICE       ok|  :  |SERVICE       !!|
`----------------'  :  `----------------'  :  `----------------'

This allows for service names of up to 13~14 characters.

As far as LCD4Linux on the Qube here, I haven't tried it -- I suspect it isn't supported, and the lcdutils are more suited to the panel on Cobalt systems.

[Kumba]

Ahh okay, I've just bookmarked that page -- I'll leave it a while until there's some netboot support first, as this is my primary way of loading software -- I've got it set up just nicely now, and holding down two buttons is much easier than undoing the dozens (well, actually 14, but it seems like dozens) of screws to pull out the HDD and plugging it into another box.

Yick. My RaQ2 just has two harddrives jammed in tthere (one on sun disk sled) with a small fan hooked in for some air flow. I haven't seen any pictures of the inside of a Qube, so I haven't seen how easy/difficult it is to change disks.

This is a good point, as the LCD panels that you can get for LCD4Linux can vary in size. Whilst tiny, the Cobalt LCD panels make it easy by being a standard size.

The Debian init script patches just put up 'Booting...' on the top line and 'SERVICE start' on the bottom line, which is relatively simple -- and works fine so long as the service name isn't too long. This could be done inside /sbin/runscript fairly easy. Perhaps a more Gentoo-like way of doing this would be:

Code: Select all

 During execution   :      On Success      :      On Failure
,----------------.  :  ,----------------.  :  ,----------------.
|ACTION...       |  :  |ACTION...       |  :  |ACTION...       |
|SERVICE         |  :  |SERVICE       ok|  :  |SERVICE       !!|
`----------------'  :  `----------------'  :  `----------------'

This allows for service names of up to 13~14 characters.

As far as LCD4Linux on the Qube here, I haven't tried it -- I suspect it isn't supported, and the lcdutils are more suited to the panel on Cobalt systems.

Hmm, there's an idea, to modify runscript. Have to toy with it a bit and see if I can't find a good spot to intercept all start/stop calls and print them to the LCD in some fashion.


--Kumba

[Redhatter]

I thought of that, and was about to do it, but getting a single hard drive is enough of a pain, let alone two bolted together...

The webmaster of the DSL/Cable Webserver website actually took their Qube 2 appliance apart and showed it to the world

As you can see here, two hard drives would be very crabbed, although the fan is just in the right spot to be most effective.

(Hrmm, it seems embedded images aren't working anymore :-/)

I figured modifying runscript would be the ticket though, since its called by every init script (well, almost) -- I like following the KISS rule.

[atopian]

Nice work Kumba, Ill have to tinker with it this weekend.

The one problem that has kept me from reviving my raq and qube gear with gentoo is more of a sustaining problem though.. Building a package on even an upgraded raq/qube 1/2 can be a bear, much less doing emerge -up world after a month or two. This really makes it unusable for a production environment.

The only ideal solution I've thought of so far is to maintain a .grp set based on a standard set of USE flags that most people with raqs/qubes will want. Then build them either via a cross compiler form of distcc, or a compiler farm of raqs.

Anybody else think of a more elegant solution?

[brackenhill_mob]

Kudos Kumba

Will this thread become the announcment point for updates to this project or will you open a new thread as each new version becomes available?

Philip

[Kumba]

Nice work Kumba, Ill have to tinker with it this weekend.

The one problem that has kept me from reviving my raq and qube gear with gentoo is more of a sustaining problem though.. Building a package on even an upgraded raq/qube 1/2 can be a bear, much less doing emerge -up world after a month or two. This really makes it unusable for a production environment.

The only ideal solution I've thought of so far is to maintain a .grp set based on a standard set of USE flags that most people with raqs/qubes will want. Then build them either via a cross compiler form of distcc, or a compiler farm of raqs.

Anybody else think of a more elegant solution?

I'll agree, the compiling time can be a bear. The machine isn't too slow though, a majority of packages will only take minutes to build most of the time. It's the big clunkers like glibc, gcc, perl (to name a few), which can take a good while. I'm building more modern stages based on a 20040131 portage snapshot. Once all the stages are done, I'll probably take a look at the "grp" target for catalyst (the gentoo stage/livecd building system), which can build a majority of the packages any average usr might install on these systems (what gets built depends heavily on the USE flags specified).

That's a ways off though, I'll probably work on install documentation after the stages are done.


--Kumba

[Kumba]

Kudos Kumba

Will this thread become the announcment point for updates to this project or will you open a new thread as each new version becomes available?

Philip

Announcements will most likely go in this thread unless there is sufficient need to open a new topic. When I have newer stages built, such an announcement will go here about them.


--Kumba

[EdSchouten]

Hey Kumba, have you already released that MIPS1 package? Kees and I can't run your MIPS4 package on our MIPS3 machines.

Yours,

Ed Schouten
(and Kees Meijs)

[Kumba]

Hey Kumba, have you already released that MIPS1 package? Kees and I can't run your MIPS4 package on our MIPS3 machines.

Yours,

Ed Schouten
(and Kees Meijs) ;)

Nope, haven't built it yet. Unsure when I will build it (stage1 takes almost 36 hours to build).


--Kumba

[mroch]

I'm half way through an installation on my Qube3, using the 2.4.20 kernel and patches from http://cobalt.iceblink.org/kernel/. I've flashed the ROM to allow bigger (2.4, dunno about 2.6) kernels as described at http://www.gurulabs.com/rhl-cobalt-howt ... wto.2.html.

I'm doing the installation while the server still hosts web pages in Red Hat. Can I expect the hardware to work when I restart? How about being able to reconfigure Apache inside the chroot and have it working as soon as I restart?

[Kumba]

I'm half way through an installation on my Qube3, using the 2.4.20 kernel and patches from http://cobalt.iceblink.org/kernel/. I've flashed the ROM to allow bigger (2.4, dunno about 2.6) kernels as described at http://www.gurulabs.com/rhl-cobalt-howt ... wto.2.html.

I'm doing the installation while the server still hosts web pages in Red Hat. Can I expect the hardware to work when I restart? How about being able to reconfigure Apache inside the chroot and have it working as soon as I restart?

Qube3's and up are x86 systems, and I know little about them so I can't really help you there. This topic is for the MIPS-based Raq2 and Qube2 systems. Given that the newer Qubes and RaQ's are x86, what you are doing probably isn't all that difficult, and may work. Likely there are examples of this kind of setup out on the web, so you might want to google around for them.


--Kumba

[Kumba]

Okay, this is a bit of a hack to baselayout, but it does a rather good job of printing stuff to the LCD for bootup.

It modifies /sbin/rc for initial bootup, starting off when swap is activated (putlcd can't function until devfsd is started). It then moves into /etc/init.d/modules when autoloading modules, and all remaining service start/stop calls are intercepted in /sbin/runscript.sh. Shutdown is more or less the same, all calls intercepted in runscript.sh, and a final "Rebooting" message in /sbin/rc.

This patch is more or less an ugly hack right now, but it works. I haven't tested all the possibile failures, like if devfsd failed to mount for some reason and the underlying /dev lacks an lcd device. I'll see if Azarah has any input as well on this, to see if it can be more manageable.

Anyways, this is specific for baselayout-1.8.6.13, which I believe is in the unstable profile. I don't know if it'll apply to any lesser versions. (Make sure you have sys-apps/lcdutils merged first!)
http://dev.gentoo.org/~kumba/mips/cobal ... -lcd.patch


--Kumba

[brackenhill_mob]

OK here's where I'm at - 90% success, but I need a bit of help getting to the finishing line. There are a couple of "gotcha's" which I found along the way.

I installed stage3 by putting the hard drive from my RaQ1 in my dual Pentium3 PC. There was/is a _lot_ of plugging/unplugging of drives which is a royal PIA but will be worth it when it works!

I edited things like /etc/resolve.conf, /etc/hosts etc and set up the network scripts in /etc/conf.d and /etc/runlevels/default. Given that the RaQ is useless without the networking stuff, should it not be in the tarball? Or would this have been set up if I'd done a "normal" Gentoo install? (Too long ago since I installed Gentoo that I can't remember the process)

Transferring the disk back into the RaQ, no boot. After a bit of head scratching I realised that Firefox had expanded the vmlinux.gz file during the download so it was bigger than the 660k limit. I grabbed the correct one using wget and it booted. An FTP link would be good, or a warning in the docs when they get done (BTW I'm happy to proofread/test).

Lots of error messages about /dev/vc/? and modprobe, and an error about a file descriptor for the console. Presumeably these can be ignored.

I use a null modem cable to watch the boot process with minicom. I'd forgotten to change /etc/fstab so the boot was halted but I had a nice login prompt. And it worked even if I couldn't edit anything!

Swapped drives and edited again and rebooted (having added ttyS0 to /etc/securetty - might be worth including this in the tarball).

It now boots and I can ping the box but I don't get a login prompt via minicom so I can't emerge anything (like ssh!).

So ...

1. How do I get a prompt via the null modem cable/minicom? Must be possible as I've already seen/used it

2. If 1. isn't possible (yet) how do I get ssh onto the drive so that I can emerge stuff that way?

BTW Kumba, you're a _star_ for doing this. I've wanted to ditch Debian on this box forever as I can't stand their package management system.

Philip

[mroch]

You should be able to emerge everything you need from inside the chroot on your PIII box. Make sure you remember to run "rc-update add ssh default" so it loads when you boot the RaQ back up, though...

[brackenhill_mob]

Forgive my ignorance, but how does a PIII run gcc and rc-update chroot'ed which are compiled for a MIPS chip?

I've never attempted a cross compile so this is a great learning process

And I actually need the serial login as I have an old portable which I hook up to it on site to do routine maintenance so help getting this running would be _much_ appreciated.

Philip

[mroch]

Someone please confirm me on this, but it is my understanding that emerge will get its settings from /mnt/whatever/etc/make.conf, which is just /etc/make.conf inside the chroot and is set up properly for the RaQ. GCC is a cross-compiler, so it can compile for the RaQ's MIPS on a different platform.

[brackenhill_mob]

Someone please confirm me on this, but it is my understanding that emerge will get its settings from /mnt/whatever/etc/make.conf, which is just /etc/make.conf inside the chroot and is set up properly for the RaQ. GCC is a cross-compiler, so it can compile for the RaQ's MIPS on a different platform.

Doesn't work - when you chroot, the root becomes the MIPS partition and you get an error from bash (presumably because it was compiled for the RaQ).

Philip

[brackenhill_mob]

Well I'm cooking on gas as we say here in the UK

Actually more like on a tiny camping stove but, hey, as I type this my RaQ is emerging a newer version of portage. I'd forgotten just how slow this box can be - need to get some more memory.

Having failed to get the cross compiler bit to work, I did some more poking around and discovered that /etc/init.d had many more scripts that I'd anticipated, one of which was sshd. A quick symlink in /etc/runlevels/default fixed the problem.

I still need to poke around some more to get the serial port stuff to work, but I can live with things as they are for the moment.

Thanks Kumba, I'm a very happy chappie.

Once I've got this box configured the way I want it (may take a week or so at current speeds), I'll replace my current RaQ/Debian combo with this one as the company server. I'll then try to find the time to rebuild the Debian box with Gentoo so I can check and document what is needed for people who install the stage tarball using a PC. If I manage this, I'll post the docs here.

Philip

[Kumba]

I edited things like /etc/resolve.conf, /etc/hosts etc and set up the network scripts in /etc/conf.d and /etc/runlevels/default. Given that the RaQ is useless without the networking stuff, should it not be in the tarball? Or would this have been set up if I'd done a "normal" Gentoo install? (Too long ago since I installed Gentoo that I can't remember the process)

Well, I still need to finish building the netboot for these devices first, then you'll be able to do a "normal" install. You might also try the debian netboot (requires an NFS Mount). It's a 2.4-based kernel, so it should work. I hate trying to netboot the thing with the old Cobalt bootloader cause it gives 0 clue as to what is wrong when your NFS stuff isn't setup properly. When Peter Horton finishes the network booting code in the new bootloader, it will rock. Trust me.

Transferring the disk back into the RaQ, no boot. After a bit of head scratching I realised that Firefox had expanded the vmlinux.gz file during the download so it was bigger than the 660k limit. I grabbed the correct one using wget and it booted. An FTP link would be good, or a warning in the docs when they get done (BTW I'm happy to proofread/test).

A very annoying "feature" of Mozilla. Especially the "treat the tar.gz file as a tar file and open it with the default compressor". Wish they'd make that an option that can be disabled.

Lots of error messages about /dev/vc/? and modprobe, and an error about a file descriptor for the console. Presumeably these can be ignored.
I use a null modem cable to watch the boot process with minicom. I'd forgotten to change /etc/fstab so the boot was halted but I had a nice login prompt. And it worked even if I couldn't edit anything!

Swapped drives and edited again and rebooted (having added ttyS0 to /etc/securetty - might be worth including this in the tarball).

It now boots and I can ping the box but I don't get a login prompt via minicom so I can't emerge anything (like ssh!).

So ...

1. How do I get a prompt via the null modem cable/minicom? Must be possible as I've already seen/used it

2. If 1. isn't possible (yet) how do I get ssh onto the drive so that I can emerge stuff that way?

BTW Kumba, you're a _star_ for doing this. I've wanted to ditch Debian on this box forever as I can't stand their package management system.

The /dev/vc* stuff you can ignore, that's just cause of the lack of an appropriate framebuffer. The baselayout package still isn't 100% serial-console friendly, but there is some work being done in that area.

Adding ttyS0 to /etc/secyretty -- This never worked for me. I have no clue why, but on all my machines which use serial console, adding ttyS0 to /etc/securetty does nothing, so I always have to remember to create an auxiliary user for myself, else I'm locked out of the box when I reboot out of the netboot.

With the null modem setup, 8N1 115200 are the settings you want to use. Minicom annoys me, it likes to work and not work, and I believe it has a tendency to reboot my SGI machines, probably cause it likes to reset the port and I think there's a serial issue with those machines which treats such a reset as something else and kicksback to the machine's PROM. My favourite serial client is "xc", and the version in portage has a hack added by me to allow connection speeds up to 115200, mainly so I could use xc with my RaQ2.

With regards to ssh, openssh is alsready merged in the stage3 (it's part of the system profile), so all you have to do is just edit the sshd config file, and have it startup on boot.

You should be able to emerge everything you need from inside the chroot on your PIII box. Make sure you remember to run "rc-update add ssh default" so it loads when you boot the RaQ back up, though...

As I've already explained, the work I'm doing applies only to the MIPS-based line of Cobalt Microserver equipment. This means the RaQ and RaQ2, Qube, and Qube2, as well as several offshoots like MIPS-based NASRaq, CACHERaq, and the Gateway Microserver. Anything made after the 2nd Generation of Cobalt equipment is x86 based, which is not covered by the Mips team.

Actually more like on a tiny camping stove but, hey, as I type this my RaQ is emerging a newer version of portage. I'd forgotten just how slow this box can be - need to get some more memory.

Crucial.com sells memory for these machines, at around $80 for a 128MB stick, which isn't bad. So you can max these puppies out at 256MB for about $160. I have a 128MB + 16MB stick in mine, and it works very well.

Once I've got this box configured the way I want it (may take a week or so at current speeds), I'll replace my current RaQ/Debian combo with this one as the company server. I'll then try to find the time to rebuild the Debian box with Gentoo so I can check and document what is needed for people who install the stage tarball using a PC. If I manage this, I'll post the docs here.

I hope you realize how experimental this still is, no liability available if it goes "boom" :)

On the other hand, many good things are coming for these systems. Here is a snippet:

Code: Select all

[root@udun root]# uname -a
Linux udun 2.6.3-mipscvs-20040218 #1 Sun Feb 22 22:09:02 EST 2004 mips Nevada V10.0  FPU V10.0 Cobalt RaQ2 GNU/Linux
[root@udun root]# uptime
 04:00:48 up 2 days,  4:15,  1 user,  load average: 0.00, 0.00, 0.00

Code: Select all

-=<[ Qube2/RaQ2 boot loader v1.2 ]>=-
pci: unit type "RaQ2"
> mount
ide: reset complete
ide: diagnostic complete
ide: {QUANTUM FIREBALL EX3.2A}
ide: LBA 6306048
ide: mode 4 timing
ide: partition 1
ext2: revision 0
> load /vmlinux-2603-f
002196ec 2201324t
> execute
elf: 80080000 <-- 00001000 1672464t + 0t
elf: 8021a000 <-- 0019a000 331909t + 94371t
elf: entry 80257018
Linux version 2.6.3-mipscvs-20040218 (root@khazad-dum) (gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)) #1 Sun Feb 22
 22:09:02 EST 2004
CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
Determined physical RAM map:
 memory: 09000000 @ 00000000 (usable)
On node 0 totalpages: 36864
  DMA zone: 36864 pages, LIFO batch:9
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/hda5 console=ttyS0,115200
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB 2-way, linesize 32 bytes.
PID hash table entries: 1024 (order 10: 8192 bytes)
Memory: 143208k/147456k available (1456k kernel code, 4056k reserved, 423k data, 84k init, 0k highmem)
Calibrating delay loop... 248.83 BogoMIPS
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
Can't analyze prologue code at 800b0d54
Cobalt LCD Driver v2.10
Galileo ID: 17
ikconfig 0.7 with /proc/config*
Initializing Cryptographic API
Activating ISA DMA hang workarounds.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pty: 256 Unix98 ptys configured
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12a
Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing disabled
ÿttyS0 at I/O 0xc800000 (irq = 21) is a ST16650V2
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Enabling device 0000:00:07.0 (0000 -> 0003)
tulip0: Old format EEPROM on 'Cobalt Microserver' board.  Using substitute media control info.
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #1 config 1000 status 7809 advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0x1000, 00:10:E0:00:26:DC, IRQ 19.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
    ide0: BM-DMA at 0x10a0-0x10a7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x10a8-0x10af, BIOS settings: hdc:pio, hdd:pio
hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive
hdb: WDC WD200BB-75AUA1, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, UDMA(33)
 hda: hda1 hda2 < hda5 hda6 >
hdb: max request size: 128KiB
hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(33)
 hdb: hdb1 hdb2 hdb3
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 84k freed
INIT: version 2.84 booting

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2003 Gentoo Technologies, Inc.; Distributed under the GPL

 * Mounting proc at /proc...  [ ok ]
 * Mounting sysfs at /sys...  [ ok ]
 * Mounting ramfs at /dev...  [ ok ]
 * Configuring system to use udev... *   Populating /dev with device nodes...
 *   Using /sbin/hotplug for udev management...
  [ ok ]
 * Mounting devpts at /dev/pts...  [ ok ]
 * Activating (possible) swap...Adding 524276k swap on /dev/hda6.  Priority:-1 extents:1
  [ ok ]
 * Remounting root filesystem read-only (if necessary)...  [ ok ]
 * Checking root filesystem.../dev/hda5: clean, 212104/300960 files, 494045/601642 blocks
  [ ok ]
 * Remounting root filesystem read/write...  [ ok ]
 * Setting hostname to udun...  [ ok ]
 * Calculating module dependencies...  [ ok ]
 * Checking all filesystems.../dev/hda1: clean, 49/12880 files, 28078/51376 blocks
/dev/hdb2: clean, 375044/2321984 files, 1521199/4642722 blocks
  [ ok ]
 * Mounting local filesystems...  [ ok ]
 * Activating (possibly) more swap...  [ ok ]
 * Caching service dependencies...  [ ok ]
 * Setting system clock to hardware clock [Local Time]...  [ ok ]
 * Configuring kernel parameters...  [ ok ]
 * Updating environment...  [ ok ]
 * Cleaning /var/lock, /var/run...  [ ok ]
 * Cleaning /tmp directory...  [ ok ]
 * Bringing lo up...  [ ok ]
 * Initializing random number generator...  [ ok ]
INIT: Entering runlevel: 3
 * Starting syslog-ng...  [ ok ]
 * Bringing eth0 up...  [ ok ]
 *   Setting default gateway...  [ ok ]
 * Mounting network filesystems...  [ ok ]
 * Setting clock via the ntp client 'ntpdate'...  [ ok ]
 * Starting sshd...  [ ok ]
 * Starting vcron...  [ ok ]
 * Starting local...  [ ok ]


This is udun.drachentekh.net (Linux mips 2.6.3-mipscvs-20040218) 23:48:10

udun login:

Yes, 2.6 is alive, and once Peter Horton finalizes his new bootloader for release (requires vaporizing that POS cobalt bootloader from the flash-chip), you too will be able to run 2.6 (I still need to work out how to do the ebuild for 2.6, things are changing in sys-kernel for how the various arch teams do their releases).


--Kumba

[brackenhill_mob]

With the null modem setup, 8N1 115200 are the settings you want to use.

I'm using those settings. I can see the boot process but I don't get the login prompt at the end which is what I want/need. I do get this prompt over the serial link if there is an error in the bootup, i.e. fstab is wrong, so I know that this a) works and b) is possible. Any ideas?

I hope you realize how experimental this still is, no liability available if it goes "boom"

So was/is the Debian system, and it's been running for over 18 months without a problem so I think I'll risk it

Here is a snippet:

Is there a much of difference in speed with 2.6? Faster or slower?

Code: Select all

This is udun.drachentekh.net (Linux mips 2.6.3-mipscvs-20040218) 23:48:10

udun login:

How did you capture this listing up to and including the login prompt? Over the serial link? If so, what the heck am I doing wrong given that I don't get it?

Philip

[Kumba]

I'm using those settings. I can see the boot process but I don't get the login prompt at the end which is what I want/need. I do get this prompt over the serial link if there is an error in the bootup, i.e. fstab is wrong, so I know that this a) works and b) is possible. Any ideas?

Ahh, /etc/inittab is wrong. By default, the inittab in baselayout is set to launch a serial console on ttyS0 at 9600bps. You need to change this to 115200 to get that all to work.

Is there a much of difference in speed with 2.6? Faster or slower?

There's very little, if almost negligible speed difference, but I haven't yet ascertained whether this minor difference is faster or slower. You can see some benchmarks here: http://kumba.drachentekh.net/nbench-data.txt which I ran on my various machines because I believe there to be a slowdown on R5000-based SGI Indys. Oddly enough, the Cobalt systems, based on a cousin of the R5000, an RM5231, does not suffer this same slowdown.


--Kumba

[kapper.net]

hi
contrary to Philip de Lisle's experience mine with the known debian v2.4.18 kernel setup on raq2 boxes is less promising - boxes that ran for years without any trouble on the pretty old 2.0.52 kernel from cobalt do hang, corrupt filesystems and lots of other dirty things when being under "real" load - meaning either working as a mail-relay or ftp-server or whatever use I had for them

now, I'm looking at this promising gentoo-setup, but honestly I have no clue how to start - though I had some spare-raq2's to test.

so - if there's a debian on the box (at least booting) is there a way to get gentoo eg. on a second hdd and then boot of this second one (yes,I'm willing to change the master-slave-setup here)?

if I can at least net-boot a debian-install/-kernel as mentioned before fine - could some kind soul point me to the right init-scripts to get a gentoo-setup then working?

any help appreciated and yes, I'm sorry, I have no gentoo experience et all...