DEC Alpha - boot partitions : SRM/aboot [workaround found]

Altivo · Last edited by Altivo on Wed Aug 12, 2015 2:42 am; edited 1 time in total

I'm trying to install Gentoo on an Alpha Personal Work Station 433au (Miata). The hardware is fine, boots and runs OpenVMS (8.3,) Debian (old no longer supported,) and OpenBSD 5.7 (current release.) I downloaded the Jan 3 2015 ISO for Alpha and burned it to a CD. Added an extra SCSI drive to my disc tower, and booted from the CD.

First problem: The boot runs fine until it tries to mount the source CD, which fails. Apparently there's a driver missing from the CD configuration. Solved that by plugging in an external CD drive to the USB port, and putting a second copy of the CD into that drive. (You can't boot SRM from USB. But the CD boot image is able to find and mount the USB drive once it gets running.)

Handbook for Alpha works fine until I get to the disk partitioning. It says (correctly) that the SRM console firmware needs aboot installed in the first track of the disk, and that the drive must be partitioned on an OSF/BSD disklabel rather than a DOS partition table. The instructions say to run "fdisk /dev/sda" (in my case /dev/sdd but that shouldn't matter.) Of course the drive already had a DOS partition table. It seems that fdisk can't delete that. Typing a "b" as directed by the handbook tries to create an "embedded BSD label" on disk partition 3. Trouble is, that will only let me assign boundaries within partition 3. So I went back and defined DOS partition 3 to include all of the disk. Created the BSD label on partition 3, assigned a, b, and c partitions as recommended. Wrote the labels to the disk, exited fdisk. No good, you can't create the file systems on those partitions because the OS only sees the disk as a single partition. Tried rebooting from scratch and it still looks the same.

So I used dd to blank out the first few sectors. Started "fdisk -tbsd -c=nondos /dev/sdd" hoping it would let me create the BSD disklabel. No such luck. It does come up without writing a DOS partition table, but when you give the "b" command it aborts.

Then I tried booting OpenBSD, and had it initialize a BSD disklabel on the drive ("disklabel -i /dev/sd3c") and then I partitioned the swap, root, and whole disk partitions as a, b, and c respectively. It looked right to disklabel and to sfdisk on OpenBSD.

Went back to the Gentoo CD boot, and it still doesn't see those partitions on the drive. The CD version of fdisk complains that the disklabel is absent or corrupt.

I've tried several sequences of steps, and reset the first few sectors of the drive to all zeros several times. Nothing works. The Handbook is no help, because the sequence of steps given there are not possible in this version of fdisk. You can't issue the "b" command on an uninitialized disk. It simply won't accept that.

I suspect that the sequence of steps given farther down the page, for the ARC console management firmware rather than SRM, are probably correct for ARC. But when I tried them, they still can't be used with SRM because you get to the point where aboot will be written to the drive and the installer can't do it. It complains that the label is corrupt or invalid.

I've tried Google, I've searched the forums, I've even asked on the Gentoo IRC (where there was no one who knew anything about the Alpha processor, apparently.) I'm sure this can be done, but not with the version of fdisk that is included on that CD image.

Can anyone offer clarification of the missing/scrambled instructions?

Keruskerfuerst · Posted: Sun Aug 02, 2015 6:02 am Post subject:

Can you post a detailed hardwareinfo of your computer?

DONAHUE · Posted: Sun Aug 02, 2015 6:13 am Post subject:

Have no alpha cpu's but:
fdisk /dev/sdd
enter m
I see only

Altivo · Posted: Sun Aug 02, 2015 11:57 am Post subject:

Altivo · Posted: Sun Aug 02, 2015 12:15 pm Post subject:

Altivo · Posted: Sun Aug 02, 2015 3:38 pm Post subject:

Current status: restoring the tar backup I made of the original failed install.

I rebooted to OpenBSD, and erased the first few blocks of the drive:

Altivo · Posted: Sun Aug 02, 2015 5:12 pm Post subject:

Much, much closer, but still not successful.

All steps completed, through configuring and installing the aboot loader. (Yes, I altered the swriteboot and abootconf commands to get the correct drive /dev/sdd and partition 2, which should be equivalent to BSD partition b, right?)

Clearly we are on the right device, the disklabel is valid and readable, and the setup seems correct. Using the menu to query the boot options or the contents of the current partition produces this:

There are only 4 actual partitions defined. Partition 1 (a) gives the same message but with filesystem type 1 (swap.) This is correct. Partition 3 (c) gives the same message but with filesystem type 0 (unused.) This is correct. Partition 4 (d) gives the same message with filesystem type 17 again.

In the OpenBSD system, I set the disklabel to have file type "ext2fs" for partitions 2 and 4. Partition 2 is /boot and partition 4 is the root /. Evidently, OpenBSD used code 17 for those, when I think it should be 8. So now I have to figure out how to change just that value in the BSD disklabel. I can't use fdisk, we've pretty much established that it will corrupt the label. I may be able to use OpenBSD, but I don't yet know what value to insert for file system type to get the desired code. I pray I don't have to use some raw disk editor to make the change when I'm this close to being operational.

Suggestions welcome. I'm still researching.

Altivo · Posted: Sun Aug 02, 2015 10:06 pm Post subject:

Successful boot at last!

This is not a suitable workaround to recommend in general, though. It's a massive, ugly kludge. Something needs fixing. A lot of things, I think.

What I had to do to get the disklabel functional was create it on an OpenBSD system, define my partitions as desired, and tell OpenBSD that the partition type for the root and boot partitions was "MSDOS". I had to read the /usr/include/sys/disklabel.h file on OpenBSD to figure out that this would place a value of 8 into the FS_TYPE field for the partition. Abortive experiments with fdisk while trying to get this working showed that 8 is apparently interpreted as "ext2" by Gentoo and aboot. With that change, aboot is able to find the /boot directory, and the /etc/aboot.conf file, and it can load a kernel and boot.

Most people, even the rare ones who are running Alpha hardware, are not going to have OpenBSD handy to create this disklabel. It is very clear that the fdisk utility included in the Alpha LiveCD configuration is (for whatever reason) unable to deal properly or even benignly with BSD disk labels.

As an experienced technical writer (now retired) I will be glad to volunteer to rewrite relevant sections of the Alpha Handbook to make this all clearer, but first a replacement for fdisk must be found so that correct instructions can be determined for those who have an SRM console. In case there is any doubt, SRM is generally much preferred over ARC. The SRM firmware allows some primitive debugging, interactive booting, and will boot many different systems and devices. ARC was really designed just to boot Windows NT, with very little interaction from the user. Unfortunately, many of the later Alpha workstations that sold for lower prices were designed primarily to run 64-bit Windows NT and came with the ARC loader. (Loader is what it really is, not a true console command shell.) That's why systems like Gentoo should support both SRM and ARC.

I can't say whether the ARC instructions in the Handbook are correct. They may well be. Both of my Alpha systems have SRM, however, and the Handbook instructions as they now stand are not usable to get Gentoo installed for SRM.

Thanks to the folks here who tried to help. I don't know where to escalate this issue. I guess it could be called a "bug" though, so should it be a bug report?

Altivo · Posted: Wed Aug 05, 2015 12:11 pm Post subject:

Footnote, in case anyone is paying attention.

The version of fdisk included on the 20150103 Alpha LiveCD is 2.24. This version is brain-dead when it comes to BSD disk labels, and therefore cannot be used to initialize disks for booting on the Alpha with SRM console.

The version of fdisk included in Debian 4.0 (obselete stable, "etch") is 2.12r. This version is capable of reading and writing a proper BSD root label. In fact, the copy of fdisk included in my working Alpha install of Debian runs correctly under Gentoo 4.0.5 and can be used there.

Somewhere between 2.12 and 2.24, fdisk has been lobotomized. I have no idea whether this was intentional, or accidental, but it needs to be repaired. And at least for the Alpha, an older, functional version of fdisk is essential.

mattst88 · Developer Joined: 28 Oct 2004 Posts: 422

Wow, you've gone through a lot to get Gentoo installed on your alpha. I'm impressed.

It's disappointing that people on IRC weren't able to direct you to the #gentoo-alpha IRC channel. Join us there.

I'll do some research and see if I can figure out what happened to fdisk.

Altivo · Posted: Fri Aug 07, 2015 10:12 am Post subject:

Thanks for letting me know that someone is listening. I think the real disappointment for me is the realization that this was released eight months ago and no one had caught the problem yet. That suggests that no one is doing new installations on Alpha hardware. And that news is indeed sad.

I have so far been unable to create a working kernel, too. I guess I need to start another thread on that. After several attempts I finally was able to get configurations to compile and link, but they either lock up without error message or arrive at a kernel panic when trying to boot.

Fortunately I was able to copy the preconfigured kernel from the installation media and I'm up and running with that. It's about 30% bigger than I need, and lacks a couple of features I would like, but at least it's functional. The worst flaw is its apparent inability to activate the framebuffer consoles properly on my Elsa Gloria Synergy graphics card. OpenVMS, OpenBSD, and Debian all do this successfully, so the hardware is not a problem. The card is a Permedia 2 chip set, and was sold by DEC for these workstations with the Miata motherboard config.

mattst88 · Developer Joined: 28 Oct 2004 Posts: 422

I dug in the util-linux git tree, and indeed a bunch of code changed in fdisk between v2.22 and v2.23. I emailed util-linux@vger.kernel.org and asked, and here was (my quoted message and) the reply from the developer:

Altivo · Posted: Wed Aug 19, 2015 11:41 am Post subject:

Not only is it less intuitive, I'm not sure it will work. If I understand what they are doing, I suspect that aboot will reject the drive. I tried something similar, but it's been a couple of weeks and I didn't keep the notes.

Yes, I can test this out. I'll have to swap another drive into the machine and see if I can initialize and then boot from it.

I'll post results here, it may take a day or so.
_________________
Have patience with me, I'm only half-baked.
--Altivo

Altivo · Posted: Thu Aug 20, 2015 1:39 pm Post subject:

Short answer:

This recommended procedure does not work.

Longer answer:

First, it is necessary to make sure that the suggested single "DOS" partition of type a5 (FreeBSD) gets written to the disk before you exit. On the first attempt, I did exactly what the instructions said, then created my desired BSD paritions, used "w" to write the label followed by "q" to exit fdisk.

The embedded BSD label was written, but the DOS partition table was not. Even after a reboot, both Gentoo and fdisk insisted that the disk had no label and was unpartitioned.

Second attempt, I used "w" to write the DOS partition information after creating the whole disk partition of type FreeBSD. Then I restarted fdisk (it exits and re-syncs after the "w" command at that level) and went to make my BSD partitions. Used "w" from within the BSD submenu, then "r" to return to the DOS level, and "q" to quit. Result: Even after a reboot, Gentoo sees only one partition, /dev/sdc1. This means it is not possible to initialize the file systems on the individual BSD partitions and will not be possible to mount them. Neither OpenBSD nor Debian is able to see these "embedded" partitions, and I assume they must be a FreeBSD analog for the DOS "extended" partition trick. FreeBSD might see them, but the tools I have available do not recognize them. This is not going to work with SRM/aboot if it doesn't work in Gentoo or OpenBSD.

My guess is that somewhere along the road, someone thought that FreeBSD==BSD but this is not always true. I had never heard of this "embedded" disklabel concept, and my old BSD UNIX manuals don't recognize it either. The label required must follow the OSF/1 standard, which was in turn drawn from (I think) BSD 3 or 4. Aboot was based on boot technology originally created to boot OSF/1 on the Alpha, and the firmware in these machines was designed to boot OSF/1 as an option. (OSF/1 went on to become HPUX and Tru64 UNIX, as I understand it.)

While I have a spare disk installed, I'm going to try something else and will report back on the results. But I still conclude that the current version of fdisk is damaged and unusable for our purposes when DEC/Compaq/HP Alpha hardware is involved.
_________________
Have patience with me, I'm only half-baked.
--Altivo

Altivo · Posted: Thu Aug 20, 2015 3:18 pm Post subject:

So, I wanted to try a Sun disklabel to see whether it would work. It didn't. Gentoo doesn't see the partitions on that either.

Then I tried the GPT disklabel, but couldn't find a way to align that with the BSD structure either, though Gentoo does see the partitions in that one.

Finally I went back to Debian 4.0 "etch" and initialized the drive following the exact instructions in the Gentoo Handbook for Alpha. This is fdisk version 2.12r, and it works exactly as described in the Handbook. I initialized the ext2 (for /boot) and ext3 (for root) file systems on the appropriate partitions, and made the swap partition, ignoring the third partition which is that BSD oddity, a whole disk partition that overlaps all others.

Then I used Debian to copy the contents of my working boot and root partitions over to the new drive.

Rebooted Gentoo, and used swriteboot to put the aboot program in the boot sectors of the new drive.

Then I shut down and booted from the new drive. This works perfectly, and the new running system is a clone of what I had on my working drive.

Again the conclusion: Older versions of fdisk do successfully create a disklabel that can be used by Gentoo, Debian, and the Alpha SRM/aboot bootstrap. The current version of fdisk is not capable of this operation. An "embedded" BSD label does not work with either Gentoo or SRM/aboot.
_________________
Have patience with me, I'm only half-baked.
--Altivo

alphahere · n00b Joined: 09 Sep 2015 Posts: 1

Installation notes on Alpha - COMPAQ Professional Workstation XP1000

I can confirm what the previous poster noted: Creation of bsd disklabel as recommended in the previous posts in a partition (/dev/sda1) is not recognized by linux. fdisk is unable to create a bsd disklabel for the entire drive (/dev/sda).

A quick work around is the following

# parted
(parted) mktable bsd
(parted) q

parted is on the installation CD and will make a correct bsd disklabel for the whole disk. Then I used fdisk to partition the disk. "fdisk" did see the bsd disklabel created with "parted". This work well. The was done on a drive without any partition table. One probably could use parted for the whole drive but I prefer fdisk.

Repeat the current version of fdisk on the installation CD does not make the correct BSD disklabel for installation or disk setup. However, one can use parted to create the BSD disklabel and then use fdisk. Hopefully fdisk will be fixed.

So far everything is working well and compiled and installed kernel 4.2 without any problems expect one small change.

https://lkml.org/lkml/2012/11/11/183

Hope this helps someone that is trying to install gentoo on dec alpha hardware.

Maquis196 · n00b Joined: 02 Apr 2003 Posts: 62 Location: London

I never ran into these issues when i installed gentoo on my alpha sometime a year ago. The only issue I have is with Xorg server. Anyone here able to run X on their alpha out of interest?

I've since been trying to get debian 5 installed without too much luck I might add. Still, good to see Kernel 4 running on Alpha!

Altivo · Posted: Mon Apr 04, 2016 3:56 pm Post subject:

The aboot issues only affect hardware models that require SRM console for booting. Machines that were originally intended to boot Windows NT will, presumably, install Gentoo successfully.
_________________
Have patience with me, I'm only half-baked.
--Altivo

Ivan The Viking · Posted: Mon Dec 19, 2016 9:58 pm Post subject:

Strange as hell this problem you have on archaic hardware I happen to love!

I did an reinstall on my ev56 LX164 alpha about a year ago and didn't run into any issues making the BSD disk label and partitions with the liveCD I had for the machine using fdisk. I think the disc was from 2012 or so?
Parted seems to be a lackluster replacement at best.

Granted this SRM and Alpha stuff is becoming niche knowledge, but the livecd should work.

I'll check the latest iso and confirm I too see the shoddy behavior.

Btw, 4.8 kernels work just fine on the LX164 as well, they just take forever to compile!

Altivo · Posted: Mon Dec 19, 2016 10:55 pm Post subject:

A LiveCD from 2012 is probably fine. This problem was introduced somewhere later than that, evidently when fdisk was revised by someone who did not understand the nature of the BSD disk label. Note too, that this thread dates back more than a year and a formal problem report was filed, so the most recent LiveCD may in fact have the problem fixed. I haven't checked that.
_________________
Have patience with me, I'm only half-baked.
--Altivo