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.

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

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

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:

# 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"

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/

Redhatter wrote:

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:

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

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.

Kumba wrote:

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:

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._________________Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

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.

Redhatter wrote:

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:

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._________________Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

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.

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.

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?

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.

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.

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.

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.

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

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.

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.

Philip de Lisle wrote:

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.

Philip de Lisle wrote:

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.

mroch wrote:

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.

Philip de Lisle wrote:

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.

Philip de Lisle wrote:

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:

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

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?

Kumba wrote:

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

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.

Philip de Lisle wrote:

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.

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