Last week I was able to acquire an Digital Server 3000 (AS800 whitebox) which was running NT4.
As I have another machine (i386) running gentoo I decided to try and see if I could get gentoo on the Alpha.

I've never worked with an Alpha before, but after reading some documentation on SRM / AlphaBIOS and general Alpha related stuff, I felt confident enough to try it.

Besides an annoying problem with the onboard scsi controller (qlogic isp1040b - kernel panics), I've come to the point where one needs to install the bootloader; which I want to do.

The (helpfull) handbook for alpha's says:

Quote:

'We first install aboot on our system. Of course we use emerge to do so:

# emerge --usepkg aboot

And ofcourse I do so; after wget-ting the sources (I have no $PKGDIR set, and I was unable to find any mirror), emerge unpacks and starts the compilation-process which ends in:

gcc -I/var/tmp/portage/aboot-0.9-r1/work/aboot-0.9/include -I/usr/src/linux/include -D__KERNEL__ -mcpu=ev4 -Os -Wall -fno-builtin -mno-fp-regs -ffixed-8 -c -o utils.o utils.c
In file included from /usr/src/linux/include/linux/compiler.h:29,
from /usr/src/linux/include/linux/stddef.h:4,
from /usr/src/linux/include/linux/kernel.h:12,
from cons.c:3:
/usr/src/linux/include/linux/compiler-gcc3.h:17:1: warning: "__attribute_used__" redefined
In file included from /usr/include/features.h:296,
from /usr/include/alloca.h:22,
from cons.c:1:
/usr/include/sys/cdefs.h:192:1: warning: this is the location of the previous definition

Don't have access to the machine right now, so I ran menuconfig on an i386 machine; found the qla1280, but how exactly do i enable 10x0 support? The driver option doesn't enable any extra 'suboptions', or do you mean 'Qlogic ISP SCSI support'?

2.6.8 might not support 10x0 - I'm currently using the qla1280 drivers 10x0 support on 2.6.10 and haven't had any problems at all.

hello again,

might I ask you how you installed your Alpha? I've been trying for some time now, but as I can't boot from the Adaptec SCSI controller (SRM .. sigh) and the QLogic always causes kernel panics when installing using the LiveCD for Alpha (latest release), I'm pretty stuck here. I've configured and compiled a 2.6.10 kernel with the mentioned support for the ISP10x0 in the 1280 driver, but as stated above, I have no means of booting it.

I even tried netbooting (bootp) using this howto SRM Firmware Howto - The aboot Loader, but using either method (aboot or kernel sources) fails. Aboot gives 'invalid stack' problems, whilst using the bootpfile method prints some messages and then hangs, no more output.

2005.0 will use a 2.6.10 kernel with the QLA10x0 driver - that should finally fix the ISP1020 lockups of the livecd. If you can't wait for 2005.0 to be released (I hope it will be released soon now) you can use any other boot cd and just follow the Gentoo handbook after getting a prompt. I've used the Debian install cd once or twice myself.

The card doesn't show up with a show dev? Ideally, you should see the scsi disk at least, and do a set bootdev thatnamefromshowdev.

How is the cdrom attached to the system? Is it scsi, and on the same scsi controller card, or is it attached directly to the motherboard?

What DO you get with a show dev?

hi,

'>>>show device' does give me the SCSI PCI card (Adaptec AHA-2940U/UW/D), but as far as I could find on the internet, it's 'normal' for SRM to not be able to boot from devices other than the onboard QLogic.

Booting from the QLogic works fine, SRM shows all SCSI devices (2 cdroms, 4 hdd); it's just SRM not booting from the Adaptec card.

and this will dump all your boot settings. If you haven't noticed already, SRM behaves like old Unixes (VMS, for example) that let you abbreviate the command name, as long as it's unambiguous.

For instance, you can type
>>> b
to boot.

It's boot_dev that sets which device to boot from. You should see the scsi devices attached to your pci card (you may need to do a
>>> show dev | less
and you can set your boot device to be the other scsi disk instead.

You'll also need to know the partition table and where the kernel is, to be able to set the other boot settings. This is where a live disk comes in handy. If you haven't already setup aboot or some other boot loader on the boot disk you'll need to do that too.

Or, if you want to practice with the arguments before you make changes to your settings, you can specify everything on the boot line.

for instance:
boot dka0 -fi 3/boot/vmlinuz -fl root=/dev/sda3

hopefully that's obvious. device name according to SRM, where to find the kernel (the first number is the partition), and you always have to pass where to find root as an argument to the kernel. You can also pass all your other kernel arguments using -fl. Once you have things the way you want. Use
set boot_osflags root=/dev/sda3
etc., but use the correct values for your setup.

Ok, I found a long enough SCSI cable to hook up all disks to the adaptec card, and install using the 'old' livecd (2004.3). No more kernel panics, and everything went fine (installed following the handbook, using qla1280+10x0 support compiled into kernel).

I then reattached disks to QLogic adapter, powered up the machine and at the prompt typed:

SRM then continues loading aboot, finds the kernel-image, and tries to load it (see output at end). Everything stops at this point, only thing to do is a hard-reset. sda2 is ext3 btw.

BTW: I think I was somewhat vague the last time; the Adaptec adapter shows up on 'show config', but 'show device' then shows no disks. If I try SRM to do 'boot dkb0 etc' I get: 'device dkb0 is invalid. Usage etc'.

I thought I hadn't given aboot enough space, as I read varying numbers on other sides for the amount of clusters to leave unused before the swappartition (from 3 to 12). I used 3; as specified in the handbook.

I'm about to try again using the 2005.0 livecd; anyone any other ideas?

Can you tell us how your drive is laid out? How about booting the livedisk and giving us the output of
fdisk -l /dev/sda

is
sda1 /boot
sda2 /
or how have you laid this out? Are all filesystems ext2 or ext3? Unless something has changed, aboot doesn't like the more modern filesystems like reiserfs and xfs. If you have your boot on sda1 and your root on sda2, then your boot command would need to change a bit.

boot dka0 -fi 1/boot/kernel-gentoo-2.6.10-r1 -fl root=/dev/sda2

Would be what you would need in that case. The 1 that prefixes /boot/kernel-gentoo-2.6.10-r1 is the nth partition where the kernel image is placed.

And another possible gotcha: If /boot is sda1, then in /boot, you'll need to have a symlink that points to /boot. In other words, if you did an ls -l in /boot you should see
boot -> .
So aboot would be looking for the kernel in /boot/boot/kernel-gentoo-2.6.10-r1
Not suprisingly, you can also change your aboot argument to just 1/kernel-gentoo-2.6.10-r1 if that's where your kernel really is, and you can avoid the symlink silliness.

I agree that your boot parameters look right. I only have three ideas now:

1) Did you setup your kernel with initrd built into the kernel, or did you build a separate initrd? If it's separate, you'll need to pass that as a boot parameter.

2) there's something wacky with the kernel, that somehow passes the initial aboot check, but doesn't boot properly. I wouldn't know what that would be. I'm surprised there's NO kernel output whatsoever, but it leads me to think you should at least try copying the /usr/src/linux/arch/alpha/boot/aboot (or whatever that file is called ) to /boot, change your aboot or boot arguments a little bit, and see if another kernel image does the same exact stuff.

3) this is admittedly a bad idea, but here goes:
alphas need to see a keyboard and a video card before they'll boot graphically. If they're missing either of these items, they'll boot to serial output instead. (But in my memory, this means complete boot, as in from when you first push the power switch to when the system is sitting at a login prompt.) Perhaps you didn't build keyboard support into your kernel? If you see your hard drive going crazy, like the system is booting, you might suspect this. If you've already built ssh you could try ssh-ing into the system, or pinging it if you've provided proper network device support. This is a long shot.

I agree that your boot parameters look right. I only have three ideas now:

1) Did you setup your kernel with initrd built into the kernel, or did you build a separate initrd? If it's separate, you'll need to pass that as a boot parameter.

Errm, this might sound very stupid, but I've never had to do anything with a initrd. As I understood things, it is only needed for drivers (modules) the kernel needs to load before it mounts the root-filesystem. But if I compile my SCSI drivers into the kernel, is such a thing still needed?
(Btw, I copied the kernel of the livecd, plus the initrd, and had aboot boot those two which worked flawlessly; it's just a software thing it seems then.)

Quote:

.. try copying the /usr/src/linux/arch/alpha/boot/aboot (or whatever that file is called ) to /boot, change your aboot or boot arguments a little bit, and see if another kernel image does the same exact stuff.

Searched around in that dir, but couldn't really find anything that would make any difference; my money is on the initrd thing :].

The console / graphic mixup isn't an issue here I think. 'console' is set to graphics, and i've got both mouse+keyboard hooked up to the Alpha, together with a monitor.

I'm sure the current kernel has both drivers for the SCSI adapters (adaptec 7880 + qlogic (through the qla1280 driver)) compiled in.

This option won't show up unless you're also including "RAM Disk support", which is in the same section.

I agree that if you're putting your scsi controller support in your kernel, this shouldn't matter (I don't have a 100% clear understanding here, so I don't know whether to recommend "trying it anyway"). Is there anything else you might be leaving out, filesystem, scsi system support, wrong scsi controller driver, wrong cpu? I was really hoping you'd have more info on your screen, like maybe it would boot to the point where it tries to mount root and fail.

I don't see why initrd should be needed for booting. The only times I use initrd is when building the livecd kernels or if I'm using software raid or similar for /. Usually initrds only complicate matters further and I recommend not using it at all unless you have a very good reason why you need it.

Make sure you have built-in support (no module stuff) for your controllers, filesystem(s) and that /etc/fstab and your boot configuration is correct. If you somehow screw up the root=dev/??? argument in /etc/aboot.conf you wont be able to mount /.

so that's basically the same line as I used to boot manually from SRM.

I'm gonna search google some more, to see if I can find something similare. I also tried to see if the it was maybe my combination of CFLAGS (-mcpu=ev56 -mbwx -O3 -pipe -mieee); compiled a 'hello world' using a crosscompiler with the same options which worked (not really conclusive but still).

It boots the CD but only under 2.4. The 2.6 kernel on the CD hangs and turns the screen background red. I'm new to the Alpha so I'm not sure what it means but if you pay attention while booting the 2.4 kernel on the CD you'll see it flashes red right before going black for a normal Linux boot.

Realizing I could only boot the 2.4 kernel from the CD I tried compiling a 2.4 kernel but it also hangs at the "Starting kernel..." message. The next thing I'll try will be to copy the 2.4 kernel, initrd, and modules from the LiveCD to see if I can get them to boot from the HD. I'm not sure what this will tell me but at least I'll have a bootable machine.

I managed to get the thing to boot by copying the 2.4 kernel, modules, and initrd to the hard drive and directing aboot to boot from these. I also had to emerge devfsd to work with 2.4. This is no kind of solution but the machine IS running under it's own steam now.