This may be an odd idea but personally I think it would be cool, and i'm sure its possible but I wanted some feedback before I go blow up some hardware trying.

I have a Sun Cobalt Qube 3, its mainly a soho server appliance for small networks, it handles all kinds of tasks; email server, web, dhcp, firewall, etc etc. I bought one a while ago off ebay b/c I thought the form factor was interesting and its nothing more than a linux box (running a hacked up version of redhat). I use it as my webserver and mail server and thats about it. It performs great but I'm a figity geek and want to do something new with it.

Now this is where problems are involved with the qube and other linux distros, it has no monitor, no cdrom, no floppy. You load these via the network. You boot a pc off the cobalt restore cd and hook the qube and pc up via a crossover cable and net-boot the qube and walla, it repartitions and restores.

Thats all fine if you want the cobalt os, but for my use of the qube I don't need all the fancy web gui junk and personally I'd rather just have a nice clean install of Gentoo.

The qube does have a LCD panel on teh back with a keypad which I'm sure I could rig up using lcdproc or something.

The problem is how do I boot this thing. Luckily you can do the entire Gentoo intall via ssh so that clears out a ton of problems associated with no monitor.

I'm thinking I'd need to boot up a pc with the gentoo install cd and then somehow get it configured to let the qube net-boot off that install, and then ssh in and configure the qube. I'm not sure though, not sure if it would work at all.

Well, my own project is dead b/c I lost interest in the qube and sold it so I could get some better hardware. But, I did have limited success and I got some input from some people at Sun Microsystems about it which was pretty helpful and will apply to the Raq4.

I had 2 drives in my qube, and I was using hte first drive to boot then I was going to load the 2nd drive as the gentoo system. I'd chroot over to it and finish the install there. Then yank drive 1, and make drive 2 the master. this worked, but i had errors. Most were kernel related so overall the project works. Its just a matter of messing with it. There is an experimental 2.4 kernel out for the qube as well, there is info about it in the original link i posted about the RH install.

Here is the info I got from Sun:

Quote:

Going just a step past what tony mentioned, (and for the more skillful in the ways of the Cobalts I might add.) there is a way to get the qube to "boot" off of other devices. First let me explain the way a qube boots.

There is a "static" kenrel kernel ROM that is called the "First Stage Kernel" This is the kernel that acts almost like BIOS would. It initializes all of the devices and loads a "Second Stage Kernel". The Second Stage loading process is what you would call "booting the machine" A cobalt doesn't act like a normal pc PC the sense that bios finds and loads a boot sector and a boot loader to load an os. That's the main difference. There is a variable set in CMOS called the 'bootdev' This bootdev bootdev the device, minus the leading '/dev/dev, that the First Stage kernel attempts to load the Second Stage Kernel from. By default, for Qube3's Qube3's DO NOT have RAID in them, this variable is set to 'hda1' (Yes it includes a partition number) For RAID'ed RAID'ed the variable is set to md1 md1 md0, I don't recall exactly which. The interesting thing is that you CAN set this variable to a scsi SCSI, IF the first stage kernel is compiled with that SCSI driver built into it. I think symbios symbios cards are built in, but don't quote me on that. I don't have the list of build in drivers.

The Second Stage Kernel is a gzipped vmlinux gzipped. It is NOT a bzImage or bzImage zImage. zImage you want to load a kernel on a cobalt it MUST be built as a vmlinux kernel vmlinux FIRST then gzip -9 gzip -9 used to zip the kernel with the highest compression. This produces a vmlinux.gz vmlinux gz NO BOOT SECTOR OR SETUP HEADERS! It is important that the kernel be built in that manner.

In short, if the First Stage kernel sees the device you are trying to boot from, and your kernel is built right and is in / not /boot it'll work.

Setting this variable is a bit tricky though. AND very UNSUPPORTED. Setting this variable COULD render your machine UNBOOTABLE. EVEN WITH UNBOOTABLE OS RESTORE. And Sun Cobalt Hardware warranty DOES NOT cover RMA'ing the server if RMA'ing do this and render your machine unbootable.

That unbootable said, there are 2 ways to set the variable.

1) through any shell to the machine, you can use the

# cmos -c bootdev <device>

command where <bootdev> is something like hda1 sda1 ... and so on

2) Through a serial console in boot menu mode. (See the knowledge base for instructions on getting into boot menu mode)

Once in boot menu mode, you can follow the help screens and set the bootdev variable there.

All that lovely information bootdev, I know a bit about Gentoo myself. And I an supply SOME information here about loading it on a Cobalt.

1) Gentoo operates off of a 2.4 kernel with devfs (for the Gentoo part). 2.4 kernels will NOT operate on a Qube 3 without taking a big risk and flashing CMOS with a new build. Which, if you mess up a flash, turns your Cobalt into a pretty blue paper weight.

2) A cobalt already boots an os, and the general purpose of the Gentoo Boot Cd. If you OS get a second HD and use that for the Gentoo install, you can do everything necessary HD the chroot steps onward.

3) Since a qube needs no boot chroot if you get that far in the install process, qube don't need to do the boot loader.

4) When you build the kernel for a Gentoo system on a Cobalt, you need to make sure it is built right, see instructions above, and is placed in / not /boot.

That's about all the help I can supply to you for doing this, but I hope it points you in the right direction. The information in this post is not for the faint of heart, and is very very very unsupported. But if you know what you are doing, and could fix a Cobalt if it came to that from a serial console boot menu, then you should be fine.

I think he pretty much covered it though. The ROM on cobalts will only accept a kernel under a certain size. This kind of kills using a 2.4 kernel without mucking around a bit. Flashing the rom corrects that problem.

I haven't been playing with other distros on the little blue boxes as much as Jason has been, but I may be able to field some questions.

The two biggest things to remember when mucking with a x86 cobalt box is setting the root device in the cmos, and building EVERYTHING possible as a module. Everything else is pretty much straightforward. _________________Gentoo, boldly going places only NetBSD dare venture.

Well, after a 3 day weekend's worth of tinkering, I now have a duel proc XTR humming away with gentoo on the bare system.

DISCLAIMER: This is of course completely unsupported and will void any and all warranties you may have with Sun Microsystems or Cobalt Networks. I speak for myself and represent neither Sun Microsystems or Cobalt Networks in this and any other posts relating to this topic.

Doing this could render your cobalt box into a unusable brick, I take no responsibility if this happens, you have been warned.

Its almost ready! The last thing needed is a few tweaks to the nfsroot image. Go into the /nfsroot-x86 directory, and modify etc/rc.d/rc.sysinit. Before the main_script executes, add a line running 'bash'. Grab the latest x86 generic stage1 tarball and place it in /nfsroot-x86. Also grab the latest cobalt kernel (c
urrently located in rpm form @ ftp://ftp.cobalt.sun.com/pub/products/raq550/RPMS/ ) and place it in /nfsroot-x86.

Now the nfsroot environment is ready. Remember: A ROM OF 2.9.34 OR GREATER IS NEEDED. If the cobalt box is not running 2.9.34, burn the 550 iso obtained earlier, reboot and boot the cd, and do an os restore from cd. The 550 has to have 2.9.34, so the installer will update the rom as part of the install.

Attach the serial cable from port 1 of the cobalt box to a machine. Run a serial console program (i.e. minicom). It should be set to 115200 8N1.

Now boot the cobalt box, and hold down the (S)elect key. After a possibly lengthy harddrive sync, it will prompt you from which device to boot from. Select 'boot from net' and hit (E)nter. The serial console should be showing the bootup sequence, and eventually dropping to bash shell.

The rest of the build is fairly straight forward. There are a few catches. For instance, most new cobalt platforms support software raid (md) and will boot from them by default. Especially if the box has multiple disks (i.e. in an XTR) then a software raid may want to be built. Also instead of emerging a kernel, the cobalt-kernel is needed. It should be located on that rpm downloaded earlier, simply 'rpm2cpio whatever.rpm | cpio -i --make-directories' from the / of the new gentoo system, after a stage3 system has been built/emerged/etc.

After fully emerged and ready, reboot the system but stay at the serial console. When it prompts for it, press space to drop to ROM mode. Go to the boot area, and update the boot_dev and boot_type as needed. then type reboot. It should start up the newly emerged gentoo system!_________________Gentoo, boldly going places only NetBSD dare venture.

If you already have a Linux OS installed (you should...) you can follow the Alternative Installation Guide to install inside an existing installation and not need a second linux PC nor have to deal with the whole NFS business.

If you already have a Linux OS installed (you should...) you can follow the Alternative Installation Guide to install inside an existing installation and not need a second linux PC nor have to deal with the whole NFS business.

We still have to fix the prom don't we? to allow bigger kernels and make it look for the kernel in the right place?

I'm running netbsd on my qube2 and i've got a qube3 (the one with raid) waiting to become gentoonized..._________________--//--
::qube2+qube3+hp xe3+ibm tp600::
clear target, gentoo on all.
--\\--

We still have to fix the prom don't we? to allow bigger kernels and make it look for the kernel in the right place?

Follow these instructions to upgrade the prom and then you should be able to more-or-less follow the Gentoo installation instructions. You may get some errors initially on the first couple of boots (IIRC, something needed to be done to make devfs work right, but it wasn't hard), but the problems are all fixable.

Also, 2.6.0 kernels probably don't work on the Qube 3, so you're better off sticking with the 1.4 stages.

okidoki... i'll give it at go, soon enough. (i've already upped the prom.. did that a while ago.. and since i've had problems setting up a bootp... )_________________--//--
::qube2+qube3+hp xe3+ibm tp600::
clear target, gentoo on all.
--\\--

I've been working out the Gentoo installation and I plan to write a start to finish doc for it once I've completed, that covers everything from creating a remote NFS root system, to booting from LVM. Right now, I'm just trying to get the initrd correct for LVM. I planned my installation so that I would have as little downtime on the qube as possible, so it makes for a pretty fast install (on the system itself. I used an Athlon64 machine to make binary packages nice and fast)

I'm interested in this - I'd be very interested in reading your doc when you have finished it dougm. I have an old qube 3 system who's prom I have updated ready for an upgrade, now it wont boot and I'm not sure where its looking for its kernel so I'm thinking of doing an install via NFS but havent gotten up the nerve to try yet. Its sounding like what you have done is pretty much what I want to do and any pointers would be very welcome.

Here is a few questions and statements before I attempt te install this weekend on a 3i. If all goes well I will have 2 production 4i's that will be blessed.

Quote:

you already have a Linux OS installed (you should...) you can follow the Alternative Installation Guide to install inside an existing installation and not need a second linux PC nor have to deal with the whole NFS business.

I dont see why this wouldnt work, but has anyone done it this way?

Quote:

Now the nfsroot environment is ready. Remember: A ROM OF 2.9.34 OR GREATER IS NEEDED. If the cobalt box is not running 2.9.34, burn the 550 iso obtained earlier, reboot and boot the cd, and do an os restore from cd. The 550 has to have 2.9.34, so the installer will update the rom as part of the install.

Ok, from experience you have a 50/50 chance of making a big paper weight by doing this. Then you must send it to Gerald at Frontstreets to solder in a new ROM.

Any feedback about the Redhat ROM? Thats a new one on me.

Anyways sounds fun and a great way to keep these little boxes going for a few more years.
Now that I think of it I want to install Plesk7 on Gentoo on a Cobalt. Think I shall paint it green and name it Frankenstien. I love this OS

Quote:
you already have a Linux OS installed (you should...) you can follow the Alternative Installation Guide to install inside an existing installation and not need a second linux PC nor have to deal with the whole NFS business.

I upgraded the prom and checked to see if the version had changed, it hadn't so I figured I needed to reboot for the change to take effect. That was the last time my box booted I still have options to netboot etc but it doesnt find the kernel by default. Be careful on doing this !

I'm now going to have to resort to an NFS install but am putting it off as I dont exactly understand what is going on with the prom and kernel booting.

I now have gentoo on my qube with the exception of a working kernel - I've tried the cobalt sources and compilation fails with various module errors missing " characters and other weirdness.

I've tried building from gentoo sources and have also run into problems with LVM errors causing fatal kernel errors on boot.

Before I start posting up reams of information in the hope that someone can help, has anyone got a guide to setting up a kernel for a qube 3 ? or even better has someone got a working kernel or sources that they can make available ?

I also messed around with several redhat kernels which I managed to extract from the rpm files. Unfortunately I had limited success and lots of unexplainable errors when trying to compile these kernels. It may however have been symptomatic of my hardware problems and not the code itself. You may have better success:
*the rpms seem to have been removed from the iceblink site - you may be able to find them on google however*.

Other than the basics the installation went well - I actually installed on a slave machine which happened to also be running a K6 processor and then stuck the hard drive into the Qube. This gave me full control without too much faff whilst installing. I guess you could install on any machine you like - just make sure you setup the make.conf for an AMD k6-II. To save too much hassle I stuck to an ext2 build which worked fine.

Hey everyone ... just wanted to put an update out here ... I have a fully running gentoo system on a Raq3 with no issues ... I basically pieced together everything I found here to get a working system. If any one is interested in this just let me know and I will be happy to put some form of documentation together.

Hey everyone ... just wanted to put an update out here ... I have a fully running gentoo system on a Raq3 with no issues ... I basically pieced together everything I found here to get a working system. If any one is interested in this just let me know and I will be happy to put some form of documentation together.

Please do, I'm trying to get a RaQ4 installed with Gentoo, but would prefer not to have to boot from network. If you know of a method, please share

EDIT:

resorted to nfs boot method and am currently bootstrapping, everything is working great! figured out how to set up a dhcp server to only respond to the RaQ4.

had a couple issues with the netboot not finding my nfs share, but got those worked out,

it seems almost like the netboot specifically looks for /nfslinux-x86 even if you specify something different in your dhcp.conf so I just simlinked it and exported both.

Hope that helps any other strugglers

forgive my horrible spelling... don't feel like checking it today _________________Linux saved my life and made me $1 million dollars over night... for only 19.95 it can all be yours

I double checked my /etc/fstab and it says XFS... so is there a reason it's looking for Reiser?

EDIT:

OKEEE DOKEEE note, make sure you have drivers in your kernel for whatever filesystem type you use, especially for the root fs ...

rebuilding kernel now, as long as it works, I will work on writing a howto, going on X-max vacation starting on friday, so I should have more time then._________________Linux saved my life and made me $1 million dollars over night... for only 19.95 it can all be yours

this essentially only gives the address to the card with the specified MAC, you may want to double check that your mac is the same as the one I listed, it shouldn't be, I believe the rom menu has a way of giving it to you.
otherwise boot into the RaQ linux OS and do a

Code:

ifconfig -a

After that continue and be sure to include all the drivers you need in your kernel dumb me

Sorry to bring a dead thread back to life, but I have been donated a Qube3 and want to install Gentoo on it, a LOT of Google searching has produced many dead ends and not many results on alternate Qube3 distros, but there is a fair amount of info on getting Gentoo on to a Qube, and this seemed a logical place to start. I've never used Gentoo before but am fairly familiar with Linux and like a challenge! Plus the software on the Qube is a bit old now (2.2 kernel) and I find myself a bit restricted on what I can run on it. Having not used Gentoo before are there any pitfalls I should be aware of?

I have got as far as this in atopian's post:

Quote:

Its almost ready! The last thing needed is a few tweaks to the nfsroot image. Go into the /nfsroot-x86 directory, and modify etc/rc.d/rc.sysinit. Before the main_script executes, add a line running 'bash'. Grab the latest x86 generic stage1 tarball and place it in /nfsroot-x86. Also grab the latest cobalt kernel (c
urrently located in rpm form @ ftp://ftp.cobalt.sun.com/pub/products/raq550/RPMS/ ) and place it in /nfsroot-x86.

I have found the place in rc.sysinit where main_script is launched. Is he saying I just need a line that says 'bash' above this line?

Also this post is a few years old now .... is today's x86 generic stage1 tarball the same as it was 2 years ago?

I have the DHCP and NFS server ready and my Qube3 PROM is flashed to prepare it for the larger Kernel. If there is anyone subscribed to this thread who could give me any more pointers I would love to hear from you, PM me!