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.
--
Jason
Sun Microsystems
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?mroch wrote: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.
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.xlarge wrote: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 dont see why this wouldnt work, but has anyone done it this way?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.
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.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.
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 bootedQuote:
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.
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 sharexphyr wrote: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.
love to, but first I need to figure out why when I boot the new gentoo system it ends up with this message and a kernel panic:Greml1n wrote:Mind providing a brief how-to for the netboot method you've used ehudokai ?
Just about to try tackle this myself.
Code: Select all
sh-2021: reiserfs_read_super: can not find reiserfs on md(9,1)
Kernel panic: VFS: Unable to mount root fs on 09:01 Code: Select all
host cobalt {
hardware ethernet 00:10:E0:05:1A:97;
fixed-address x.x.5.21;
server-name "x.x.5.222";
next-server x.x.5.222;
option root-path "x.x.5.222:/opt/nfsroot-x86";
}
Code: Select all
ifconfig -aI 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?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.