Vintage computing for fun and [no] profit

[MartinHowe]

That was probably the hard way to do it. Not sure why you couldn't just use update-initramfs (or whatever the equivalent was back then) after installing your kernel and modules to the file system, but whatever works.

Because I'm new to all this l33t unix stuff I've a fair amount of experience with unix and later linux, but not at this level ... kernel compiling ... cross compiling ... this is all new to me. Essentially, while I now know how to cross-compile, I don't yet have the experience to know how to "cross-initramfs" I used scp to copy the two kernel files over.

Out of curiosity any particular reason you went with 5.4?

Purely because that's the current kernel on Linux Mint 20.1 and I didn't want to mess with having two different kernel versions around until knowing a lot more about this stuff.

Oh and there's no mouse at the moment and it's still giving me trouble, but at least it does boot the installation with Gnome, though only using the Permedia card - gotta learn to crawl before I can walk

[Blzut3]

Because I'm new to all this l33t unix stuff I've a fair amount of experience with unix and later linux, but not at this level ... kernel compiling ... cross compiling ... this is all new to me. Essentially, while I now know how to cross-compile, I don't yet have the experience to know how to "cross-initramfs" I used scp to copy the two kernel files over.

While building the initram from your build system is doable, typically it's done when you install the kernel to the system (post install on the deb package). I don't know the exact sequence of commands you need to do but what you'd want to do is "make install" and "make modules_install". I think you effectively already did this part minus maybe transferring them to the Alpha outside of the initram? Once they're installed on the Alpha, run update-initramfs from your Alpha. The man page should be easy to get through.

Oh and there's no mouse at the moment and it's still giving me trouble, but at least it does boot the installation with Gnome, though only using the Permedia card - gotta learn to crawl before I can walk

If you didn't install the modules to the hard drive already and are running only off what initram loaded then there's probably a lot of drivers you're missing. Note that once your root file system is mounted the initramfs goes away so even if you installed all the modules there only a select few would have loaded.

[MartinHowe]

Thanks for the help - it now works much better by copying the modules to the target and running update-initramfs from there. Still a few issues, but that's to be expected, as I am still learning what works and what doesn't.

Some of it is the old userland; parts of the networking stuff trigger an unaligned exception; IIRC the Debian system was built for EV4 (no byte/word extensions) and installing NTP even provokes a "ntpd uses 32 bit features" warning; this machine has dual EV56s so direct 32/16/8 bit memory access is possible, but the software doesn't know that

I have also toyed with building a minimal Linux from scratch (indeed there is a project with that name, which I shall read up on in due course). But it's progress.

[MartinHowe]

This is now becoming such a stupefying problem Trying a serious, rather than experimental, attempt to get a kernel working; my previous attempts were hacky

Try 1:

Build a 5.10.0 kernel starting with the default options. Enabled drivers for the SCSI disks to be built-in to the kernel and enabled initramfs. Then copied to the target machine and run update-initramfs from there. The userland appears to absolutely require uevent_helper. So enabled it too. It manages to get to the point of mounting the root filesystem and fails with:

Code: Select all

mount: mounting /dev/sdc3 on /root failed: No such device

Then it drops me into the initramfs shell. This is crazy! I can ls -l /dev/sdc3 and it's there and showing the correct major and minor hex ids for the device and partition. The directory /root does exist in the initramfs. All the advice on Google for this deals with erros on the disk, but it's been checked several time with no errors and in any case the kernel supplied with the machine boots fine.

Since the filesystem is clean and the device and mount point both exist, how can it possibly be failing?

Try 2:

Get the original kernel configs for the current kernel (2.6.26) and import that into the 5.10.0 kernel config using the make olddefconfig target, then build it. Once installed, the kernel segfaults all over the place and I have to halt the machine and reboot it!

So if anyone (@Blzut3 ?) has any idea why the first one doesn't work when it should - please help!

[Blzut3]

Given that you're probably in a state that you can't dump the dmesg logs, guessing at what's going on is going to be a bit difficult. But my initial thought would be the file system driver for whatever file system you're using not being present.

Upgrading a config from 2.6.26 to 5.10 doesn't sound like something that would be likely to work. Did you ever look into Debian's sid kernel that I linked to you before? I would really like to know if it works at all. If so, then the hard work of building a kernel config is done for you.

[MartinHowe]

Given that you're probably in a state that you can't dump the dmesg logs, guessing at what's going on is going to be a bit difficult. But my initial thought would be the file system driver for whatever file system you're using not being present.

Pretty sure it was included, but will double check.

Upgrading a config from 2.6.26 to 5.10 doesn't sound like something that would be likely to work. Did you ever look into Debian's sid kernel that I linked to you before? I would really like to know if it works at all. If so, then the hard work of building a kernel config is done for you.

I tried, but dpkg on the system is too old to install it.; however, a manual install might be possible as I have now learned how to break into .deb files I might be able to steal the kernel config if nothing else. I'll have a look, thanks.

[Blzut3]

is too old to install it.; however, a manual install might be possible as I have now learned how to break into .deb files I might be able to steal the kernel config if nothing else. I'll have a look, thanks.

Ah, probably a good chance the only thing stopping it from installing on the old dpkg is the compression algorithm. So just in case you haven't thought of it: extracting the tars and converting them from xz to gz and then packaging them back up with ar might be enough.

But yeah compiling with that kernel config might be a good starting point as well.

[MartinHowe]

Sadly, while that's what I did, it seems also that the control scripts include directives that older dpkg's don't understand. So I installed it manually. It can't start because aboot (the Unix bootloader for 'modern' alpha systems) can't handle the compression of the kernel itself.

To be fair, going by the size of the lib/modules directory, they've put everything in it including the kitchen sink So I'll have to use their config file and build it myself, stripping out everything I don't need and specify optimisation for size rather than speed, as that's what seems to determine it. If all else fails, hack the Makefile and force it to use plain old gzip. I'll have a go when home from work tonight.

As for upgrading aboot - the source of a fairly late version is available - but it's one of the scariest hack jobs I've ever seen. Stuff like bootstrapping itself by ripping wholesale parts of the kernel source, #including bits of the actual source tree as well, kludging bits of gzip here and there with little or no error checking ... I feel dirty just looking at it - So maybe, but not today

[MartinHowe]

Well, that was weird. If I try to boot the compiled kernel as normal, I get the "unknown compression" message ... BUT ... booting the kernel image by itself works, at least until it realises that (with no initrd) it can't find the real root, init, etc.

I've been assuming that it's the kernel image that is too big or the wrong format, but what if it's the initrd that's tripping it up? I tried it with an uncompressed initrd, but that didn't work and segfaulted everywhere. I don't yet know if that's because the kernel itself is expecting one (and if so, can it be build to use an uncompressed one) or because aboot source seems to suggest it will barf if there isn't at least one compressed data chunk in the file. Maybe I could construct a file containing a gzipped cpio archive that has only one empty file with a name that the system won't look for (e.g, 'meow') and cat it on to the end of decompressed kernel and initrd. Maybe worth a try.

I know I can generate both with no zip issues by starting from scratch, but there's some issue with the support in the initrd for getting the file systems up. If only I knew what it was.

The other thing I could try is setting it up to boot without an initrd, as the only drivers it needs to boot are the pci, eisa, SCSI, keyboard and tty devices and I can compile them directly into the kernel.

But it's midnight and I have to go to work today so time to sleep!

Addendum - wonder if the 2.6 kernels include kexec()? I could use them as a bootloader, much as libreboot and such replaces almost everything in the EFI stack above the chip-within-a-chip (80186 running Minix, apparently, at least for Intel, no idea what AMD PSP uses) with a real linux kernel.

Update 1: The kexec seems to be available only for Intel, PPC and ARM. Same applies to that as to aboot and milo: if I were to even consider building those myself, there's too much to learn about Alpha memory mapping before I start; not saying 'never', but something for the long term only.

Update 2: I tried a 5.x.x kernel because that was what @Blzut3 suggested, but it's clear that kernel gives aboot nightmares - wonder how the sid people even tested it? Must find a way to contact them and ask.

Update 3: Will try a simpler kernel and bake in the drivers so it doesn't need an initrd; downloaded 3.0.1 and set up the infrastructure to build it; when home from work tonight, will configure and try it.

Update 4: Well well, it looks as if ${DEITY} smiles upon me - or at least as if ${DEMON[++demonindex]} has claimed my soul Debian sid has an updated aboot that (allegedly) fixes several of the build issues and includes a binary with some bugfixes; the sources even have some rudimentary support for cross-compilation! DEFINITLEY have go with that and the kernel @Blzuz3 mentioned, as it seems to be more up to date that the one that ships with Debian 5.

[MartinHowe]

New update. Please note that this is somewhat detailed in order to help those (all three of you, if that, LOL) who might need it in the future or who, like @Rachel, @Redneckerz and a couple of others, have expressed curiosity but may lack some of the technical context. Special thanks to @Blzut3 for the invaluable info that helped me find all this

TL;DR: Now my AlphaServer has aboot 1.0_pre20200212-1 instead of the 0.9b that came with the system.

The Debian sid (unstable or experimental) repository has an updated version of aboot, the secondary bootloader for Linux on Alpha systems, roughly equivalent to the pre-EFI versions of the Windows Boot Manager (e.g. on Windows XP/7). I used dpkg-deb to decompile the .deb package files in "raw" mode, which just extracts them as a directory (kinda like unzip -d), tar them up, scp them to the AlphaServer, untar them, repackage them using its (older) version of dbkg-deb, then install them in the right order using dpkg -i. Thanks ${DEITY} that while these packages use .xz tar compression, which nothing in Debian 5 understands and hence the need to decompile/repackage in "raw" mode, they are simple packages that don't use any of the new dpkg scripting directives (roughly equivalent to those in .msi or .nsi files on Windows) that older dpkg's don't understand.

These commands don't actually install the newer aboot in the boot sectors; they install a ton of command-line utilities and man pages (text format manuals, which on Linux are roughly analogous to ye olde WinHlp32 help files), update the raw copies of the bootloader which are located as regular files in the mounted /boot partition (kinda like an EFI partition for old Linux systems) and leave you to read the man pages to learn how to use the command-line utilities to actually write the relevant one to the actual boot sectors. You have to ignore the 'overlap' warning and override it, as the particular utility for writing on-disk HDD boot files doesn't assume that the raw empty space partition 1 is where the bootloader is meant to go, even though it is its job to put it there So I had to fire up gparted (like the Windows disk manager GUI app, but a lot more functional and less fussy) to check things out before doing it, especially as fdisk gets the partition types wrong (says they are all ext2, but / is ext3). My system even booted correctly after that

Sadly, sid doesn't have the source code for the new aboot (it just says 'not found'), but it is available on GitLab, so I might be able to build it from source myself; let's hope that doesn't become necessary. I haven't tried the new aboot on a self-built kernel or the one @Bluzt3 mentioned yet; that will have to wait for another 'evening after work' as it's 11pm here in the UK and I will need to get some sleep soon.

But yay, some progress at last

[Blzut3]

Sadly, sid doesn't have the source code for the new aboot (it just says 'not found'),

It's here.

[MartinHowe]

Sadly, sid doesn't have the source code for the new aboot (it just says 'not found'),

It's here.

Thanks I found their gitlab for it anyway, so it's gonna be an interesting few days

[MartinHowe]

And about bloody time
[imgur]https://i.imgur.com/JYvBRh4[/imgur]

No mouse, no networking, stripped down as much as possible, no initrd/initramfs, drivers baked into the kernel,
a few complaints from init, but at least it works somewhat. I now have a starting point to enhance

('Rawhide' is the DEC engineer code name for the AlphaServer 4000 and its variants like my 5305)

Updates as at 21:40 UTC:

Upgrading to kernel 5.11.1 seems to have fixed networking and sound and I can now set it as the default
kernel to boot in aboot and it starts fine.

Still getting unaligned traps on the Debian network-manager, so not sure why it's working. Who knows? I may try
an even later kernel, but the latest stable kernels cause even some of the Debian infrastructure on my Mint 20.1
box to barf compiling modules and so on, so I'm being a bit cautious at the moment. Networking is still a bit
flaky; sometimes it works, sometimes not. Running dhclient at the command prompt fixes it, but does not update
the gnome icon in the titlebar. At least it works. Prettifying it will have to wait.

Getting a few whinges from ALSA, but sound is working now; though, I did have to go in and configure the audio
line-out jack switch, which incidentally is the logical negative of what you actually want, whereas in the original
Debian 5 it worked out of the box.

And as for graphics on the 8400, it seems Nouveau is x86, ARM and PPC only. Will need to try and build
it myself some day

[MartinHowe]

New update. Well, I got the new kernel more-or-less working, built gcc 4.9.1 and a few other modern utilities and common dependencies such as grep, awk, sed, pcre 1 & 2, pythons 2 & 3, etc. The biggest problem for me right now is glibc.

Nearly all modern Doom source ports use CMake and compiling a modern version of that and the libuv library it depends on requires a more modern glibc that the one on the system, which is 2.27, so I built glibc 2.7. This passed all the tests, apart from one FP maths test where the test wouldn't even compile; the FP maths tests themselves are known to be flaky on some architectures, including Alpha, so this isn't a big deal. Much of the system even worked with it.

The problem is that while glibc is supposed to be backward compatible with earlier versions, between 2012 and 2018, some of the symbols the 2012 apps expect aren't there or are represented differently, usually because they are in other libraries whose functionality has since been moved into glibc itself. While I could login via ssh and gnome, the actual command line login app at a terminal fails. The modified system also managed to mount two of the disks the wrong way round, as if it had detected them in the wrong order.

The silly thing is, most DooM source ports, AFAIK, aren't that bothered by which glibc they use on Linux, it's CMake. There is apparently a way to install glibc in a separate directory and explicitly link specific apps to that one, so I shall read up on that in due course. Once I have reinstalled the system anyway. Fortunately, I tar'd the build directories of all the stuff I compiled, onto a separate partition that's my rescue installation (command line only, no GUI, minimal as possible) so at least I should be able to simply 'make install' most of them again without recompiling.

[Blzut3]

Easiest thing to do in the mean time is use CMake 3.13 which is just before the libuv thing that's causing you problems. Should still be mostly compatible. That's where I've been setting the minimum on the overhauled configs for ZMusic and GZDoom at least.

I have heard of glibc causing compat issues although as you notice it is more of a "mostly" backwards compatible. At least I can say it never caused me issues with the binaries I build with 5+ year distro support. That said, my first thought would be to try to be more conservative on your glibc bump. Not sure what libuv needs but I don't think it's that much further ahead than what Lenny ships. I know the version in CentOS 6 is new enough for example.