Currently I am willing to bring an API CS20D AlphaServer, fitted with two EV68AL, back to life. I can access this very compact but very loud machine through a serial console, and ultimately get a remote display with VNC on my iMac hopefuly in a very near future.

Because of the simplistic hardware configuration, there is no possibility to connect a display, and it is hard to plug the box over the internet. Previously, I did start the installation from the usual minimal iso image, however the process described in the documents, using standard emerge commands was too lengthy and leave the machine in an unknown state because the compilation stopps in the middle of nowhere. So, I choosed to start from the LiveCD available for download on the official website.

Obviously, the way Gentoo works with packages allows us to do so, because after all, the simple "emerge --update -deep world" can do the trick to bring the live system back to the current stand. Since the current stand is moving quite fast these days, and because the settings of the compiler suite and compilable source can be a painful process, I think this can be a good method to cope to underlying problems of the very fluidic and fast changing Gentoo distribution.

Doing so, I could finaly step over the Chapter One of Gentoo Handbook, and start with real things which are unfortunately only briefly discribed in the handbooks available on internet. But obviously, there is something not clear in the documentation, or at least the information is not well sorted, how Gentoo is Booting on AlphaServers.

There is no other example of aboot.conf than the one delivered with the distribution itself, so I took it and simply copied into etc/aboot.conf of the target system. This brought the Gentoo box to a semi-finished product: After a short cp /mnt/livecd sda1 I was pretty much ready with the basic programs. The following aboot.conf summarize all trials

One last trick to solve: ABOOT starts the kernel, and the initrd goes up to the selection of the keymap. Then, it says:

Code:

!! The root block device is unspecified or not detected.
Please specify a device to boot, or "shell" for a shell...
boot() ::

I had a look in the MAN Pages of aboot.conf, abootconf and aboot. I also read the threads regarding problem configuring the bootloader and Gentoo aboot issues on alpha ev56, but I don't think we are in these cases. Thinking I just lack one parameter in my aboot.conf, it would be very interesting if someone would extend the explanation in the man pages, to include an explanation about the last parameter "cdroot" and also the meaning of "looptype" "zisofs". Perhaps I need to flash the kernel is the first sectors of the harddrive, like it is done with fd0 boot disks, using the brute-force DD command! What else will I miss, the configuration of EMERGE perhaps ?

Thank you to have taken the time. Sure, you are right, the LiveCD is placed into an "Unsupported" folder from the FTP.
But the 2006.1 LiveCD is working great! Without hassle I could start the server and get the X graphic interface up an running in matters of minutes!

What is the idea behind INITRD ?
The file /LINUXRC was not existing on 2006.1 version's kernel neither. Anyway, currently the 2006.1's LiveCD Kernel is being installed, I do not quite understand why one of these ABOOT.CONF I am using (copied and modified from the LiveCD) couldn't work. The solution you are proposing is not working neither:

Problem 1: The Gentoo handbook, the Man pages of abootconf, swriteboot, aboot, are not telling what all these options meaning. The Man pages are not complete, it is missing a bunch of information, regarding the options which are of common use. Perhaps, you may say, the initrd option is a parameter passed to the kernel, I know, but that document is not even existing! (The Code Is The Document isn't it?)

Problem 2: The LiveCD is a great help to bring the system up and running in a matter of minutes. The powerful "EMERGE --UPDATE --DEEP WORLD" can upgrade any Gentoo installation to the latest stand.
But, the installation process has dramaticaly changed since 2006 Gentoo, and especialy the "env-update" script, the "parent" files placed inside the portage, are not compatible.
Unfortunately, the former command will not work, and EMERGE permanently fails to use the portage after a single "EMERGE --SYNC":
The old portage has been removed, and the new one is not functionning because of this script "env-update" which is not compatible with the "parent" files.

Problem 3: You may say, then we shall use the latest Minimal Install ISO available on the release FTP. But these ISO are issued one after another these days.
Alone in the beginning of this year, five of these ISO have been released. I burned the 20110212 version of this ISO, but it does not even boot!!
Can somebody explain How to Create a IMAGE.SQUASHFS, and I will create the latest CD on my own.

May I ask, why are there so many releases available, What is the ChangeLog, and why it does not boot?
Moreover, a good and suitable release notes can ensure the quality of the release.
Whoever Geek did all these changes, we wanna know, because he may need support to test all these release versions.

Problem 4: It is a Great Idea to provide a LiveCD, because it can bring a system to a semi-finished installation in a matter of minutes.
But, please, do not put the documentation directory from a x86 platform into an Alpha LiveCD.
The LiveCD's Documentation includes the Gentoo Handbook for x86 platform installation! Not even explaining how to configure ABOOT and how to properly start the Network and how to configure the X server properly. Sadly, NET-SETUP utility crashes before the end...
Somebody better fixing this, because Documentation is important to avoid posts like mine.

Maybe I could one day bring these issues a part of solution, if my Gentoo Alpha could start.

Currently, the Gentoo on /dev/sda1 (on DKA0) is the most advance stage in the installation process. It is a 2006.1, with emerge --sync on the portage directory, and full setup from Chapter 1 of the Gentoo Handbook, all done from the CHROOT as explainend in the handbook.

It does start with "boot DKA0" and "aboot> 0" (see the post above to read the options)

My guess, the Kernel is not supporting some block devices or something.

Although the Kernel from the ISO image _did_ a great job, I would need now to emerge vanilla-sources to compile my own kernel with support to my CS20's hardware configuration (2,5 minutes download and 2,5 hours compile).
However, this does not work as such, I needed the emerge --sync to bring the fresh install portage to life. After that, the portage got broken, or better said, the "env-update" script was not compatible with "parent" files. So I hacked the files "parent" (not documented) and the new "make.conf" inside the Portage directories to make it compatible with env-update from older release. Doing so, I do not really need the latest minimal install ISO, which was somehow not able to boot. Apart from that, the problem mentionned above seems unrelated, because this error "root block device" is probably related to the installation of ABOOT or the setup of a ROOT disk, in which case the # make dep && make vmlinux modules modules_install && make boot will solve this error right away. So, nothing to do with installation of Gentoo's Emerge itself, either I need to compile and install the kernel, or I need to tune ABOOT's installation. Will somebody be so kind to confirm, prior to loose hours in kernel compilation ?

Let me insist again that nobody is going to help you install from an unsupported method, so please stop asking questions about it. And i'm saying that as a member of the Gentoo Alpha architecture team.

Regarding your problems:

=Problem 1=
-Those are options from the kernel, not from aboot. Read the documentation of the kernel.

As for why the aboot.conf from the livecd wouldn't work, its easy. That aboot.conf has specific parameters to boot from a image that lives in a cd. On a installed system, the system is on a hard disk, on a partition, and on a file system.
The problem i see you're having is that you're missing the support for your disk controller and/or the partition you're specifying is wrong. In my case the partition is /dev/sda1, since you have tru64(i think) on the disk as well, the partition containing gentoo may be in other than sda1. You should know where you installed it...

=Problem 2=
-Installing from that outdated livecd is unsupported and breakage is expected

=Problem 3=
-You should know how Gentoo works first. There's no easy documentation on how to build that, and what do you want to build that, anyway?
Regarding the newer releases. Those are called autobuilds, and they are built every week, the announcement was done three years ago: http://www.gentoo.org/news/20081220-releng-first-weekly-stage.xml
The last release apart from the autobuilds is 2008.0. The autobuilds are done to provide updated installcds(with latest kernels) and stage3s(with latest packages) so when you install you don't have to go through the problems you're having due to using outdated releases.

There's no changelog, and for sure there's not going to be a release notes for an automated release. The last manually done release was 2008.0(for alpha, that is, for amd64/x86 was 10.1)

=Problem 4=
-The livecd is unsupported. I'm pretty sure the livecd its not mentioned on the handbook...

So please, ditch the livecd, or at least don't ask about it because there are supported methods for installing. In other words, you're on your own if you're using the livecd.

Define how the installcd doesn't boot...be more specific, please. Paste the logs, etc...

I already ditch a CD today, it was the install-alpha-minimal-20110212.ISO, the automatic build which could be one of the most advanced. Luckily, I could retrieve it from the trash bin, to show the output below.

The CD got an error with the boot sector while burning the image I guess. But the CD is readable, surprisingly, something went wrong with Disk Utility from OS X, or the manipulator, I do not want to know who did it wrong.

If I understand well, the structure of OSF/1 (BSD) partition table can be slightly different than that of usual DOS disklabel.
So, you mean "root=" should be adjusted. I tried already in the "shell" that appears when it fails.

I do not know the syntax for this, but the "shell" that can be request is not support mount /dev block devices anyhow.

The Kernel was installed with following ABOOT bootstrap commands:

Quote:

# swriteboot -f3 /dev/sda /boot/bootlx
# abootconf /dev/sda 1
This last number slightly differs because the Root it searches in will be SDA1 and not SDA2 since the Handbook do not recommand to have a Root partition when using SRM (this was understood from the Gentoo Handbook Chapter 1 Part 4 and Man abootconf

>> Will I need to use the BOOTSTRAP command I from FDISK in BSD Disklabel mode in order to bootstrap the root disk ? Can that be the problem ?
nb: Another reason why I am not going to change the Disklabel, apart from the fact I'm not willing to reset the spare partition SDA4. I have to support SRM and OpenVMS, which are only compatible with OSF/1 disklabel.

The ABOOT configuration works, because I did it wrong once, and Aboot is then not recognised from SRM.
So, you mean to say, the kernel that is available on the root disk is not supporting SCSI disk controller.
So, let's assume: BOOTLX is right, because using the bootstrap commands as above, it outputs the result below. The other INITRD GENTOO.IGZ probably not right.

Luckily, I could manage meanwhile to get the Internet connection for the Alpha Server, through the Router, and enable the Internet Connection Sharing from the iMac (which is connected with wireless Lan). Now, I can download, but the STAGE3 and PORTAGE shall be residing somewhere on an existing partition, this can be loaded into my SDA4 spare partition. Since those minimal install CD is not containing anything else than the minimal environment, few utilities, Gentoo's legendary Emerge, and the needed scripts env-update which behaves so different from one release to another (btw emerge --sync does not seem to cope with this evolution). Beforehand, I have to burn a blank CD, containing STAGE3.tar.gz and PORTAGE.tar.gz, and copy those files using the SRM management console on SDA4 spare partition ? It is very likely that the CD drive being locked with the Minimal Install Disk, we have to proceed this way.

I want to know if it would be possible at this point to load a Kernel Module that supports the SCSI disk controller.
I think it is the right time to study the full transcript, from the current boot using precompiled kernel.
I think this shows the actual hardware configuration, but I lack of knowledge for decrypting what ther Kernel is doing with the SCSI controller.
Here comes the last open question for today:
Which one of these Build is going to bootstrap the freshly compiled kernel ? make vmlinux modules modules_install; make boot

Because of the simplistic hardware configuration, there is no possibility to connect a display

Not true. It's quite easy to put a PCI graphics card (I'd recommend a Radeon) and a USB card for keyboard/mouse into the two PCI slots.

But... what are you trying to do? Dump the LiveCD contents to disk and then update from there? If so, that's a terrible idea. I can't imagine how many incremental ABI breaks there have been since 2006. Just grab the latest stage autobuild and dump it on the disk and go from there. It's much simpler this way.

Wow you could setup the graphics on this small server?
I didn't know those PCI-X 64 bits 133MHz slot could host a Radeon graphic card. Until now, I thought we would eventualy stick with the capabilities of a PowerStorm 350.
My plan was to use the faculty of X-Server to provide a remote login screen through the network, thus using the capability of my host's graphic card

It gave me confidence, because everything was already working seamlessly right out of the livecd. Keeping some disappointment from the past in mind, as the compilation stopped in the moddle with a bunch of GCC coompiler errors. You are right, I will start over, installing from scratch on the second partition, with the latest stable release.

Perhaps it is better to take not-too-old 2008.0, or one of the many automatic build which ever ISO starts . This will be quite interesting too, perhaps I will discover some tricks by following the first Chapter of Gentoo Handbook in a strict step-by-step procedure. The installation is way not finished after following the first chapter, in fact it only begins from that standpoint. I see one big advantage in using the hot release ISO images, that I could eventualy take advantage of the very latest graphic interface developments, and eventualy take part to the Screenshot Contest, or having less ambition trying to reproduce one of the beautiful award winning gui.

I will also get rid of OpenVMS for the moment.
- There is a problem with ABOOT not finding the Root partition, to my supposition this could be due to the BSD Disklabel.
- Some partition could not be found from the Kernel it seems, even though the missing Root has never been the forbidden third partition "whole disk".

But I can't believe that a Kernel built for any official ISO does not support the SCSI controller and the Seagate 36GB fitted into the CS20. Anyway I will have to try this out, configure the MAKE.CONF to take advantage of the BWX,MVI,FIX,CIX,MAX from the EV68AL processor architecture, which I did not assume to be required, because my twin 21264B apparently lacks of support from the "-mcpu" compiler option ( that is what I believe while reading http://gcc.gnu.org/onlinedocs/gcc/DEC-Alpha-Options.html). Compiling the Kernel could rather be time consuming, but the time I hesitate, this incredible machine could have finished to Emerge the whole World

Anyway, it is going to be a very very long installation process, because I am still not understanding the background.

Frankly speaking, I'm not so sure about OpenVMS, why it shouldn't work, if I may ask?
At least, my CS20 had a vestige of this operating system on its harddrive as I received it. The partition did not boot, probably it didn't get a valid installation for a standalone node. Only the OSF/1 partitioning was ready on the original disk, but SRM failed to boot the drive, and I did not try much more with this.

So, I intented to start with Gentoo, CentOS, Fedora AlphaCore, in the thought I would bring one of the original Digital OSes to the first partition later on. This will be in case I ever hand on original installation disks (very high licencing costs apply I imagine), OpenVMS might become more affortable. Such a pitty if OpenVMS won't be compatible with the CS20/DS20. I was bluffed by the shiny Gentoo Screenshots, it makes good impression I must say.

This machine was part of a much bigger mainframe minicomputer, so possibly it must synchronize with its friends nodes, with BOOTP or so... Perhaps the original setup has a much more complex setup than that what I am about to build now:
Network an SGI with InfinitePerformance graphic pipe with the twin Alpha in the same rack... Imagine the fun to put that test machine online One day maybe.