I built apache-1.3.29, php-4.3.4, and its associated deps w/o any problems. Took forever, though. Apache was the quick compile, but having to build mod_php (for apache) and then standard php took longer than expected.

I built apache-1.3.29, php-4.3.4, and its associated deps w/o any problems

Any reason why you used the 1.3 Apache tree? I've got the v2 tree working. Might this explain why I got the weird PHP YP/NIS dependancy?

I won't have a chance to install these until the end of the week as I'm out and about with potential clients.

Philip

I got those same errors with 1.3.29-r1 :\

I had some fun setting this Qube2 up though
Making a 2.4.25 kernel small enough was quite a challenge.. and damn compiling takes forever on that machine. It only has 16 MB of RAM as we speak. I'm planning on bumping it to 128 MB though.

I had to compile every little thing that *could* be a module as a module.

First, Peter Horton seems to have publicly unveiled his bootloader, even though I've sorta had an advanced preview of it for some time. You can found a tarball here which includes binaries in it, which I recommend using for the time being. I'll get around to trying to build an ebuild out of it shortly and testing to see if it'll boot when built with modern gcc/gentoo tools.

The plus side is in the 1.4 release, Peter added a "chain loader" which lets you boot the bootloader from the existing cobalt bootloader so you don't risk nuking your flash chip. If later on down the line, you feel like permanently switching, you can flash the bootloader in. I won't explain the documentation aspects here, there's plenty of documentation inside to explain things.

As for 2.6 sources, mips-sources-2.6.3 has cobalt patches that allow it to bootup and work. Just make sure you have the cobalt profile in use, or if you want to cross-compile them, pass PROFILE_ARCH="cobalt" to the emerge/ebuild command to get it to apply the cobalt patches.

Now as for apache and crew, Not to sure there. I got preoccupied the last few days, so I haven't paid attention to this thread for a bit. I primarily built apache-1.x cause it's what I've always used. Just haven't gotten unlazy enough to bother switching to apache2.

NIS, if I recall, seems to be an integral part of glibc, so if NIS isn't working, it may indicate a bug in glibc itself, or a bug in the way things are setup. Maybe a bug in PHP that only appears on mipsel systems. Dunno really, that one will need some looking into, although I'm gonna have to switch the cobalt over to stage building in a couple days (2004.1 is around the corner).

After 2004.1 is out the door, I'll be able to take a closer look at the issue, cause I got that funny feeling I'm going to be fighting all of my machines to play nice with me and build stages. If someone here manages to trace it down, post here or file a bug on bugs.gentoo.org, and I'll address it.

//------------------------

Francis85: You won't have to worry about the size limitation issue anymore if you use the newer bootloader. It eliminates that, cause with 2.4, I'm beginning to think 2.4.25 is the end of the line for the cobalt, cause it's just getting hideously impossible to crunch that kernel size down much more. Especially if you try and build a netbootable kernel.

I have booted my raq2 using the debian-netboot, and after some jiggery-pokery with bzips and tars, got Kumba's stage3-mips4-..0131 installed.

Copied over the kernel from Kumba's kernel directory, loosed the modules tarfile into /lib/modules, and rebooted.

I've got Peter Horton's bootloader working in chain mode, but that can't seem to pass arguments on to the kernel. For some reason, the kernels I have downloaded insist on using /dev/hda5 for root. Fine, no biggie. I repartiton, and make hda5 my root. install, reboot again.

The above should work off the bat for you. I'm going to mess around with the script feature that the bootloader looks for and see if I can't setup a few example scripts for people. I'll also have a default script with the ebuild that will drop to the bootloader command prompt (if that's possible to do).

I've even tried changing the root entry to something silly like root=/dev/wocket, and the kernel still doesn't seem to pick it up.

There's also a command called 'arguments' in the bootloader, i've tried using that as well (just add another line: arguments root=/dev/hda5 console=etc) both in the script and the bootloader. nada. yer kernel just loves /dev/hda5.

Incidentally, this is fantastic work. I've been thinking about how much of a grind this would be, and your work has taken much of the headache out of the setup. BIG THANKS. :D

Okay, the bootloader is in portage under sys-boot/colo. Its official name is COLO, or COablt Linux lOader. It'll get auto installed with your next world update most likely because I added it to the default cobalt profile (it won't affect the current boot setup of a running machine, there are still a few manual steps like copying chain.bin from /usr/lib/colo).

shadowlost: As for 2.6 kernels, yup, you can merge mips-sources-2.6.x in sys-kernel/mips-sources on the cobalt and it'll automatically apply the needed cobalt patches. If you've used crossdev and setup your own mipsel kernel compiler, you'll need to pass PROFILE_ARCH="cobalt" to the emerge/ebuild command to have it apply the cobalt patches (as well as keyword the ebuild). When you use a 2.6 kernel, you can specify the kernel command line in menuconfig to force the root device. Generally, the root device is on /dev/hda5 because /dev/hda1 is going to be /boot, and this will be true for a large majority of people still running these machines, due to /boot needing to be the special ext2 revision 0 format.

The above config is aimed at a system running udev, so make sure to add devfs into your config (don't use the above one blindly). Once you're satisfied with 2.6, you can transition to udev too if you want. It works great on the cobalts -- only 44 items in /dev :)

When merging the package, do read the output that the ebuild will print when the package finishes merging. It provides valuable advice to heed. If you miss it for whatever reason, run ebuild /usr/portage/sys-boot/colo/colo-1.4.ebuild postinst, and that'll re-print the info.

A super-quick guide to cross compiling cobalt binaries on x86 hosts while using distcc.

(UPDATE: 20040502: whee, ACCEPT KEYWORDS is bad. Did you know that? I didn't know that. We're supposed to use /etc/portage/packages.keywords instead, but i still have no idea how that would relate to this setup, so instead i'm going to shake my head sadly.)

1) emerge distcc on cobalt

2) emerge distcc and crossdev on x86

3) run on x86:

Code:

#PROFILE_ARCH="cobalt" crossdev --arch=mipsel

(if your cobalt make.conf has ACCEPT_KEYWORDS="~mips", then also use the '-u' / unstable argument to crossdev as well)

#distcc
distcc 2.13 mipsel-unknown-linux-gnu (protocols 1 and 2) (default port 3632)
built Apr 5 2004 05:42:12
Copyright (C) 2002, 2003 by Martin Pool
...
Server specification:
A list of servers is taken from the environment variable $DISTCC_HOSTS, or
the file $HOME/.distcc/hosts, or the file /etc/distcc/hosts.
Each host can be given in any of these forms, see the manual for details:
...
preprocessing are run locally. distcc should be used with make's -jN
option to execute in parallel on several machines.

This so far, has worked for me. Distcc and emerge have been smart enough to failover to a linear, local build (which the localhost/1 entry more or less does in the hosts file). So far, it's been working when emerge comes across a build it can do in parallel. You might have the occasional hiccup, and have to re-emerge the package, or set MAKEOPTS="-j1" emerge -u blahblah. This was done in a fit of impatience when i emerged my first build of glibc.

ugh.

By setting up a different port, you can set that up to be your mipsel-build port across many machines, and leave the default for x86 or whatever.

Hi,
After much arguing with the Debian netboot image and the stage 3 tarball, I managed to get my little Gateway Microserver (Qube 2) up and running.

The kernel was cross compiled on my main machine using crossdev (just the basic toolchain, not the full kit unfortunately -- glibc doesn't like me). I'll eventually emerge samba & apache, as I plan to use this box as a dedicated file server for LANs.

I've dropped an old PCI Adaptec SCSI card into the slot, and the box sits on top of an external SCSI CD-ROM tower which is loaded with 4 hard drives (3x 18GB and a 9.1GB). These drives were originally formatted to FAT32, but a bit of data shuffling later, and I've now got them running ReiserFS. (I did try to use XFS, but xfsprogs wouldn't compile). I clocked the transfer rate between drives at around 4MB/sec (~32 Mbps).

So far, it's been a lot more responsive using Gentoo than it was using Debian. Somehow compiling for an RM5200 CPU rather than baselevel MIPS makes a big difference on these boxes.

With the netboot... I found Kumba's image worked, except using the kernel gave me a corrupted display... the output from the serial console was being garbled. In addition to this, Debian's version of 'tar' seems to not like filenames of over 100 characters. I managed after some struggling to get a basic system on, but I was lacking a lot of files, including some critical for PAM (/etc/pam.d/* -- only sshd got extracted), causing fatal errors when I tried to log in using the serial console. I ended up booting into single user mode and extracting the rest of the archive using Gentoo's 'tar'.

The answer to this netboot issue may be to look into improving the netboot image to allow telnet access (ala, the Debian way -- let's face it, we're using NFS & DHCP for bootup, not exactly the most secure method). I did try to use Debian's version, but in.telnetd had other ideas... I'm thinking of using either the built in one for Busybox, or to get utelnetd going.

I'll keep you posted how I go..._________________Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

This is my first gentoo install so getting up to speed was kinda rough...not to mention conglomerating all the docs to get an install setup and working.

Colo works great in chain mode. I don't have it scripted yet but I'll do that shortly. I don't have the cajones to flash it yet though. An oddity is that it (colo-1.9) doesn't seem to fall into the boot-shell from any keyboard input on the console. I have to by-hand select it from the LCD menu, and then mount/load/execute to bring the system up. Otherwise it seems to just keep cycling itself.

Here's a quick rundown of what I did, in hopes that it'll help someone else out.

1 - Follow the netboot instructions linked earlier in this thread
2 - Setup a 100M REVISION 0 partition as HDA1. (mke2fs -r 0 /dev/hda1) This became my /boot.
3 - Setup swap on hda2, and use the rest as hda3, ext3.
4 - I used stage 3 for the install
5 - Tried to follow the instructions as they're laid out on the mips-install page
6 - Removed excess (virtual consoles) from /etc/inittab and fixed ttyS0.
7 - I used rc-config and removed consolefont and fixed/added the rest
8 - Grabbed the 2.6.6 config from Kumba's directory, unmasked 2.6.6 and built the kernel using his config. I did change the "Kernel Hacking --> Default kernel string" to say root=/dev/hda3. I also moved most modules into the kernel. Start the compile and go do something else for 2.5 hours.
9 - Emerged shadow to fix broken console login.
10 - Emerged udev
11 - mkdir /sys
12 - NOTE - Doing an emerge -u portage will cause gcc/glibc and perhaps other packages (I went to bed and my serial console was kinda hosed-up so I couldn't see the output well) to be rebuilt so be prepared, if you do this, for a long long wait. I figure it took between 20-24 hours to finish.

I may have missed something but essentially #6 and #8 --> #12 are worth noting if it even helps one person out.

Thanks Kumba for the work and the online help.

Now, has anybody done work with the LCD and panel buttons?

sedawkgrep

Last edited by sedawkgrep on Wed May 19, 2004 5:42 pm; edited 1 time in total

or something to that effect... Scrolling left/right should reveal a HALT and RESET menu item._________________Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

I'll admit I haven't messed around with the lcdutils package in quite some time, so I had to check for myself what buttonsd did. I guess that rules buttonsd out as a useful utility. Maybe if I get time this summer, I'll study how buttonsd works, and see if I can't write soem kind of quagmire in C and see if I can't make something that listens for button input and performs various actions based upon the commands given. I believe the CobaltO2 stuff did something similar (letting you select the IP, etc..), but I dunno.

Any volunteers wanna offer ideas, like if such a utility already exists for other LCD-based applications?

The item tag could behave a number of ways to allow for yes/no answers, entering IPV4 addresses... (perhaps IPV6 as well -- but the screen will be small for this), text/numeric entry (tedious), menus, etc. The contents of the item tag could be the script that is run when the item is selected. Variables would be set (e.g. $ADDR in that example, for yes/no selections... $SELECT could be set.).

A useful feature (at least for me) would be for it to display stats such as its current IP, traffic levels, disk usage, etc... scrolled on the rear panel. I did have a hack using a perl script and putlcd which did exactly this....but I was not able to make use of the buttons.

Another useful idea would be to simplify the API used, to say allow for scripts to be programmed in Perl/Python...etc. Either that, or create a sort of "dialog" clone which uses the LCD panel and would allow Bash scripts and the like to make full use of the panel. This actually might prove to be a better idea than the one above (or could be used to implement the above idea).

Just some thoughts...

UPDATE: With my rather limited C knowledge, I managed to hack up buttond to create two new utilities.... asklcd_yesno -- which as the name suggests, gives you a yes/no prompt, and asklcd_menu, which gives you a menu prompt. Both are intended to be very simple.... they pop up the menu, and on selection, asklcd_yesno will return an exit status of either 0 (yes) or 1 (no). asklcd_menu spits out the selected item on STDOUT.

This is just the beginning, I'll see what I can do here, but my time at the moment is limited with university study. (I've got exams & assignments looming up ).

Is there anyone currently maintaining the lcdutils package?_________________Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

Im not new to gentoo but to the raq2.
I think i miss a straight documentation how to install gentoo on the cobalt-maschine. As i understood, i need the debian-mips-cdrom to boot from. Or i have to implement the netboot-functionality. But i simply don't know how to interact with the cobalt-bootmanager to change the boot-medium :-/. Can somebody give me a hint where to find a documentation about that?
If i connect the serial cable to get the bootmessages, how do i have to configure the other side (x86-gentoo)?