Apparent freeze during installation of system.

[globetrotterdk]

I am pretty sure that vmlinuz-3.16.0-4-amd64 refers to the Devuan kernel and not the Salix kernel.

Yes, that's it. The path given to the kernel in the Salix stanza of lilo.conf needs to be the path to it as mounted at the time you reinstall the bootloader. Like this:

Code: Select all

root=/dev/disk/by-uuid:9d2c1561-d6d7-4651-9373-bcd440c289dd
   image=/path/to/mounted/dd1/boot/vmlinuz
   label=Salix
   read-only
#   restricted
#   alias=3
# End Salix OS configuration

Thank you mimosa. Regarding the Salix configuration, my lilo.conf file has exactly the same configuration as yours, except of course for the following:

Code: Select all

image=/media/username/9d2c1561-d6d7-4651-9373-bcd440c289dd/boot/vmlinuz

Unfortunately, despite everything testing OK, I get some sort of panic that includes:

EOI panic+0x1b7/0x1f0
(...)
3.762164 -[end trace 6e0a640ecf8d150a]---

Regarding the Devuan section, I agree that it looks weird, but I think that it is because it has the following at the very beginning of the lilo.conf file:

Code: Select all

# Specifies the boot device.  This is where Lilo installs its boot
# block.  It can be either a partition, or the raw device, in which
# case it installs in the MBR, and will overwrite the current MBR.
#
#boot=/dev/sda
boot = /dev/disk/by-id/ata-ST2000DM001-1CH164_S1E21XPJ

# Specifies the device that should be mounted as root. (`/')
#
#root=/dev/sda1
root = "UUID=2e1478a0-3356-4ce7-9efe-f72cb7e85a2b"

This was auto configured, but it works fine, so I have left it alone...

[globetrotterdk]

Edit lilo.conf.

If you use an initrd add

Code: Select all

initrd=/dev/sdd1/boot/initrd.img

or

Code: Select all

initrd=/boot/initrd.img

Be sure you have vmlinuz and initrd in /dev/sdd1/boot folder
Run as root
lilo -v

Thank you for your post djemos. Due to the configuration of my computer, I have discovered that after replacing the motherboard, I need to use UUID as the /dev/sdX naming changes. I believe that it has to do with my using a recent motherboard in legacy mode, but as long as I stick with UUID (The Devuan/Debian installer ask if it should convert to UUID in the lilo.conf as it is being installed), I haven't experienced any problems that can't be overcome, however I admit that it can be a pain with Grub2 when installing new distros.

Regarding initrd, I am unsure if I use one. I assume so, as I did a vanilla Salix64 XFCE install so...

Another approach is ince you use devuan to update lilo.conf to boot salix is to copy salix vmlinuz and initrd.img if you use one to /boot folder in devuan partition.
If there is already vmlinuz and initrd.img file with the same name there can named vmlinuz1 and initrd1.img the salix files.

Then edit lilo.conf in devuan partition and add

Code: Select all

image = /boot/vmlinuz
root = /dev/sdd1      
label = Salix
initrd = /boot/initrd.gz
read-only

and run lilo -v

Interesting. I wasn't aware of that. Not sure how copying those files over would play with using UUID, however.

[mimosa]

It doesn't matter how the other OS (in this case, Salix) will be mounted on boot, the path in the image line just needs to point to the right kernel using the path on which it is mounted when the bootloader is installed, ie you give the command sudo lilo -v. As djemos says, you can put it anywhere you like, as long as it is mounted and the correct path is given.

[globetrotterdk]

It doesn't matter how the other OS (in this case, Salix) will be mounted on boot, the path in the image line just needs to point to the right kernel using the path on which it is mounted when the bootloader is installed, ie you give the command sudo lilo -v. As djemos says, you can put it anywhere you like, as long as it is mounted and the correct path is given.

Ahh, I understand. Firstly, I have done a:

Code: Select all

$ ls /media/username/9d2c1561-d6d7-4651-9373-bcd440c289dd/boot/boot_message.txt    inside.dat     System.map              vmlinuz-huge
coffee.dat          onlyblue.dat   System.map-huge-4.4.19  vmlinuz-huge-4.4.19
config              README.initrd  tuxlogo.dat
config-huge-4.4.19  salix.bmp      vmlinuz

As you can see, there is no initrd.img for some reason. Is that why I am getting the panic messages when I try to boot Salix? If I moved the Salix vmlinuz to /dev/sda1/boot/ and called (for example) "image=/dev/sda1/boot/vmlinuz1" in the Salix section of the Lilo configuration, I assume that this would mean that every time I upgraded a kernel or needed to install the Nvidia driver/blob (I have a newer card that isn't supported by the stock drivers in Salix.), that I would have to manually move vmlinuz again over to /dev/sda1/boot/ again?
----
Wouldn't it be simpler to re-install Salix and then install Lilo on the MBR of /dev/sdd? Then in the Devuan lilo.conf, I could chainload Salix, or isn't this possible? It works with Windows.

[laprjns]

As you can see, there is no initrd.img for some reason. Is that why I am getting the panic messages when I try to boot Salix?

Yes, this is the reason. Unfortunately lilo cannot pass UUIDs to the kernel without an initrd. As you can see, your Duavuan install has an initrd so it boots with the UUID reference. The only way to to get UUID working on Salix is for you to make an initrd. Use the mkinitrd_command_generator.sh sript found in /usr/shar/ and follow these instructions:
https://docs.slackware.com/talk:slackwa ... ners_guide.

As far as I can see you had two problems that where causing Salix not to boot. The first was the lack of an initrd and the second was the path used for the image= line. You should now have this fixed using:

Code: Select all

image=/media/username/9d2c1561-d6d7-4651-9373-bcd440c289dd/boot/vmlinuz

There shouldn't be any problems updating lilo as long as you have the Salix partiton mounted there when running lilo. You will need to use the same path in the initrd= line in lilo.config

[globetrotterdk]

As you can see, there is no initrd.img for some reason. Is that why I am getting the panic messages when I try to boot Salix?

Yes, this is the reason. Unfortunately lilo cannot pass UUIDs to the kernel without an initrd. As you can see, your Duavuan install has an initrd so it boots with the UUID reference. The only way to to get UUID working on Salix is for you to make an initrd. Use the mkinitrd_command_generator.sh sript found in /usr/shar/ and follow these instructions:
https://docs.slackware.com/talk:slackwa ... ners_guide.

Thanks for the reply laprjns, and thanks for clarifying that the issue has to do with the system lacking an initrd. Having looked at some of the documentation, but not understanding everything, I have a couple of questions:
Firstly, a clarification. I have been working on this issue so long that I couldn't remember if the Salix system was a completed system without Lilo or a system where installing Lilo froze the installation and never completed, so... I did a reinstall, which changes the UUID as the partitions were reformatted. The new UUID is 8624b400-0a3d-4e9d-92a2-56779e96260e.
1) Generating an initrd appears to be related to using a generic kernel, whereas my system appears to be using a standard "huge" kernel, hence the "System.map-huge-4.4.19" and "vmlinuz-huge-4.4.19" entries when I $ ls the boot partition. Do I need to switch to a generic kernel to genereate initrd?
2) I have been as of yet unable to boot into the Salix system. The Salix docs refer to being able to pass an argument at the boot prompt after booting the install media, however this option seems no longer to exist in 14.2:
https://docs.salixos.org/wiki/Boot_into ... llation_CD
How do I boot into the system to generate an initrd?
3) The link that you referred to appears to be more a discussion of issues with the documentation, rather then what arguments to use with the mkinitrd/mkinitrd_command_generator.sh. Any recommendations?
4) There appear to be two related tools mentioned in the documentation. One is mkinitrd/mkinitrd_command_generator.sh, which apparently only generates a sane lilo.conf section, while mkinitrd creates an actual initrd. This would suggest that I need to run both. Correct?

[mimosa]

I can hopefully advance things by answering part of your post, but I've never needed to make an initrd myself, so laprjns is much better qualified to answer about the specifics.

You can have an initrd with any kernel you like. The reason the discussion tends to involve the generic kernel is you definitely do need one for that. "huge" has the kitchen sink, almost ... unfortunately, it seems it doesn't have everything you need in this case. You have really been hit by a perfect storm in that you need to use UUIDs to boot from your hardware.

You should be able to get to the boot prompt right at the beginning, perhaps by pressing TAB. I'm afraid I don't have one handy to try here, but a little experimentation should do it.

Alternatively, exit from the installation at the earliest opportunity, and chroot into your hard disk Salix in order to build the initrd there in the console. This is the hair shirt method though. However, it should work well enough, because the kernel that boots the USB is the same one it will install, and you haven't had an opportunity to update it yet (which you definitely should once all this is done and dusted).

EDIT
Having looked into it a little further, I think actually making the initrd is probabyl as simple as

Code: Select all

sudo /usr/share/mkinitrd/mkinitrd_command_generator.sh /boot/vmlinuz

as per the link given by laprjns.
If that doesn't work, you may need to explicitly specify the missing module that gives the ability to boot by UUID:

Code: Select all

sudo /usr/share/mkinitrd/mkinitrd_command_generator.sh -m MODULE_NAME /boot/vmlinuz

I have been unable to find what the module is though.

[globetrotterdk]

You should be able to get to the boot prompt right at the beginning, perhaps by pressing TAB. I'm afraid I don't have one handy to try here, but a little experimentation should do it.

Alternatively, exit from the installation at the earliest opportunity, and chroot into your hard disk Salix in order to build the initrd there in the console.

TAB gives the Grub prompt, unfortunately. I can get a console by exiting the installer after setting the keyboard keymap. I tried this:

Code: Select all

# mkdir /mnt/test
# mount /mnt/test

but the system complains that /mnt/test is not in the /etc/fstab. If I get past this hurdle, I am supposed to first run:

Code: Select all

chroot /mnt/test /bin/bash

and then:

Code: Select all

# /usr/share/mkinitrd/mkinitrd_command_generator.sh /boot/vmlinuz

as you posted? I don't understand the issue with the /etc/fstab at all. That should only be changed if I was making a permanent change, I would think.

[mimosa]

I think it's LILO, rather than Grub. In any case, that should be what you want - not a console, which you get to after booting. Did you try following the instructions? This way will be much simpler than messing around with chroot.

[globetrotterdk]

TAB gives me a > prompt, not $ or #. This a boot loader prompt. The installer still starts after having passed the "huge" or the "sudo /usr/share/mkinitrd/mkinitrd_command_generator.sh /boot/vmlinuz" command. No feedback of any kind appears after passing either command.