Let me start by saying that I deliberately didn't do what I was supposed to do, so if I have problems now, you could say it's my own fault! You are supposed to install GRUB as your bootloader, but I took the option not to install it. I have never liked GRUB and I was able to boot all my other systems out of elilo on the old drive, so I didn't anticipate any problems with AntiX (although I hadn't run it on this machine before).

The contents of /boot after installation looked something like this:
Looks OK, doesn't it. Two kernels and two corresponding initrd images. But I couldn't boot with those. And when I examined the initrds, they don't seem to be proper initrds at all, just cpio stubs containing microcode.
So I thought: obviously you need to use mkinitramfs to add a second archive with all the boot stuff and then zip it all up into a working initramfs disk.

No such luck! I couldn't do it with mkinitramfs; I couldn't do it with update-initramfs. Both these scripts run to completion without errors but they don't create anything useful.

I can boot this system using my LFS kernel, which doesn't require an initrd. I can also boot it with its native 6.1.42 kernel and a corresponding initrd image that I made on Slackware. That's what I'm using now. But I would quite like to know how to do it properly

I have never used elilo so am unable to give much help.
Does it need efibootmgr installed? (It isn't on antiX-23)

The problem isn't with elilo. Elilo works perfectly well. I have been booting various distros out of it for years. All it needs for any distro is a kernel and an initrd copied over onto the ESP, and a stanza in elilo.conf referring to them. You do indeed need efibootmgr to get elilo (or for that matter GRUB) to run on a UEFI machine in the first place (and I had some problems with that after I put in the new drive), but I already have the program available in Slackware. And you might remember that you yourself gave full instructions on how to install it on the live AntiX-23 in order to then use it to install GRUB.

The problem is further down the boot sequence: how to make a working initramfs image for AntiX, because without that, no bootloader is going to work. The mkinitramfs and update-initrmfs scripts supplied with AntiX don't seem to work for me; they don't produce any useful output. If you could suggest some way of testing them, I would be grateful.

Slackware has a mkinitrd script that works very well and I was able to use that to make an initrd for AntiX simply by cheating a bit. I mounted my AntiX partition on Slackware and created a temporary symbolic link in /lib/modules to the module tree for AntiX's new kernel. The script produced a fully functional initrd image for that kernel which elilo was able to use to boot the entire system.

So problem solved, you might say, except that I don't think that's a proper solution. I'd like to know why the initramfs scripts supplied with AntiX don't work for me. What is missing in my AntiX system that these scripts are looking for and don't find?

I'd call that a win.

It's beer o'clock here... off t'pub.

Maybe copy over the live initrd.gz?

I had a look at how the live disc booted earlier in this saga. It's quite complicated: there are a lot of bits and pieces of GRUB configuration files that somehow slot together at boot time. I'm pretty sure that the final product of a GRUB install is not going to be as complex as that.

But in any case, if the solution is just to import an initrd, I might as well stick with the one I imported from Slackware, since I know that that one works.

That looks fine: it's a combined initrd image with Intel cpu microcode in uncompressed cpio format and the real, possibly compressed, initrd image concatenated in one file. Your cpio command only saw the microcode part.

I think I was able to duplicate your problem. I was able to be get it to work in my test by adding to /etc/initramfs-tools/modules and rerun mkinitramfs
Try adding modules needed to boot to /etc/initramfs-tools/modules

1 members found this post helpful.

OK, that sounds like an excellent programme. I've just created a new initrd-img file with ext4 in it and copied it over to the ESP. Later I'll try booting with it. If it's an improvement, I'll use Pat's helper script in Slackware to find all the other modules I need to add to to the configuration.

I assume that if you choose to install GRUB, it sets up your initial initramfs requirement automatically. After all, it's part of the job of an installer to know exactly what hardware you have. But if that is so, then I think the sequence is badly designed because that job should be done unconditionally as part of the general installation, not made conditional on installing a particular bootloader. After all, there must be plenty of GRUB users who have multi-distro installations and want to keep their old GRUB setup and not have it hijacked by AntiX. They would find themselves in the same situation as me.

Yippee! That worked! Thank you, @colorpurple. I wish I could give you a second rep point but that's not allowed.

Now I have two (hopefully) helpful suggestions for the person on Team AntiX who designed the installation script:

1) The bash code to create the first initramfs image should be included in the main sequence, so that it takes place automatically after all the files have been copied over. At present, it seems to be part of the optional "install GRUB" branch; if you don't install GRUB, you don't get a preconfigured initrd. But any modern stock kernel needs an intrd image in order to boot properly, no matter what bootloader you use. It's far from intuitive that not doing a new GRUB installation (and you might have a perfectly good customised working GRUB controlled by another distro) means you don't get a proper initrd.

2) I was somewhat confounded to find that syslog wasn't included in the install. That means that by default the only logging is the kernel's dmesg log. This really isn't enough. A lot of Linux newbies use AntiX and if something goes wrong and they post in a forum about it, the first thing they'll probably be told is to check the logs and post the result. Then they look and find that there aren't any!

I suspect that this is a carry-over from Debian. Debian has journald/journalctl so maybe modern Debian releases don't bother with syslog any more. But AntiX doesn't use systemd (hooray!) so it needs syslog (actually syslog-ng) and that ought to be provided in the basic installation.

Just my

@hazel

1. Did you install using the gui or the cli-installer script?

2. On Debian syslog-ng brings in libelogind-compat, which we have blacklisted.

I did it graphically and it went very smoothly. Very well designed apart from a couple of cavils I have made above. I particularly liked the partition selection tool, which was quite easy to use.
I installed syslog-ng-core via synaptic and it seemed to go OK. I think it brought one other package across with it but I wasn't taking notes.

Thanks.

syslog-ng-core brings in libelogind-compat libelogind0.
By default, antiX will not ship with any systemd/elogind parts.

I'll see if I can build nosystemd/elogind versions.

There is a livelog tab on the installer window that shows what the installer is doing.