Salix Forums

I actually have some at least potentially, interesting news. I tried a re-install of Salix on the same hard disk. This time I tried installing Lilo on the disk at the end of the install. Both to see what would happen, but also thinking that if nothing else, I could try chainloading the system as with Windows, if for nothing else, to get the initrd sorted out and then return to what we have been working on with Lilo. The install, unfortunately didn' work, but the error was interesting and could lead to an eventual solution. I just don't quite understand what it means:

Code: Select all

Fatal: Bios device code 0x80 is being used by two disks /devsdb (0x0810) and /dev/sde (0x0800).
Sorry, but the attempt to install Lilo has returned an error...

I used cfdisk to check, and /sdb is my Windows system, while /sde is my Devuan system. Lilo is supposed to be able to multiboot, but it seems like the boot flags on both installs are somehow preventing Lilo from getting installed. I don't think that this is a limitation of a modern BIOS.

globetrotterdk wrote:I used cfdisk to check, and /sdb is my Windows system, while /sde is my Devuan system.

That's a little surprising since form your posting of the outputs of lslblk -f and blkid I concluded the following:

sda is for Devuan with its root file system on sda1, swap on sda5 and home on sda6. It appears that its a DOS (MBR) partition table with and extended partition sda2
sdb has not partitions
sdc is for Windows, both sdc1 and sdc2 are both formated as ntfs, so I assume this is your window install.
sdd is for Salix with its root file system on sda1, swap on sda5 and home on sda6. It appears that its a DOS (MBR) partition table with and extended partition sda2
sde appears to be another window disk with both partitions formated as ntfs

So it doesn't seem to jive with what you just said. Is this the changing disk ordering that drove you to change to UUID?

I just don't quite understand what it means:

Code: Select all

Fatal: Bios device code 0x80 is being used by two disks /devsdb (0x0810) and /dev/sde (0x0800).
Sorry, but the attempt to install Lilo has returned an error...

Google "Bios device code 0x80 is being used by two disks". There are some answers there but it very complex and beyond my current knowledge of lilo. You might want to also consider simplifying your system a bit. sdb is not being used and it is apparently one of the drive causing the latest issue. I suggest you take it out along with sde since that one appears to have no purpose in your current scheme, and see if you can get it working with the three other drives.

Lilo is supposed to be able to multiboot, but it seems like the boot flags on both installs are somehow preventing Lilo from getting installed.

Read the hit from the Google search, it has nothing to do with boot flags. The problem seems to be with BIOS IDs being passed from lilo and the bios at either the time that lilo is installed or at boot up. It also appears that the use of both grub and lilo may have added to the confusion of the BIOS ID. There appears to be some lines that can be added to lilo.conf to resolve it but again, I couldn’t really get a full understanding in my brief review of the subject.

I don't think that this is a limitation of a modern BIOS.

You do know that even though your are booting legacy that you really are still running UEFI. UEFI is just emulating bios booting by running UEFI code. Since UEFI is a specification, there are many vendors producing their own UEFI compliant firmware. You can expect and do get bugs.

I will be trailing over the next week or so and will have little to no access to the internet, so I will not be able to follow or post during this time. Hopefully you will get this working soon

Regards
Rich

laprjns wrote:Is this the changing disk ordering that drove you to change to UUID?

Absolutely.

laprjns wrote:You might want to also consider simplifying your system a bit. sdb is not being used and it is apparently one of the drive causing the latest issue. I suggest you take it out along with sde since that one appears to have no purpose in your current scheme, and see if you can get it working with the three other drives.

My thoughts exactly. I tried this with a couple of drives and ended up with my BIOS insisting on booting Windows 10, but I eventually got it sorted. I BTW have an ASRock 970 Pro3 Rev2.0 motherboard at this time. I will have to try to find the correct drive and unplug everything else, to see if I can get Lilo installed on the Salix disk.

laprjns wrote:I will be trailing over the next week or so and will have little to no access to the internet, so I will not be able to follow or post during this time. Hopefully you will get this working soon

Regards
Rich

Good to know.
Thanks again,
Brian

I will have to try to find the correct drive and unplug everything else

It is probably better to try just unplugging the one or two drives you aren't even using, because otherwise, you are liable to mess things up again when you put them back. The idea is not so much to install the bootloader come what may as to simplify the configuration to make that possible straightforwardly.

However, this may be a good time to consider switching to UEFI. It is quite likely to just work. Legacy booting was designed a long time ago and copes poorly with scenarios like yours, which must have been pretty unusual back in the day. The EFI specification on the other hand has been created from the ground up to be more robust.

OK, I physically unplugged all of the internal drives, except for the one that I wanted to install Salix (with Lilo) on. I have now succeed at the task and ran mkinitrd. which gave the following response that puzzles me:

Code: Select all

# mkinitrd
Nothing found at location /boot/initrd-tree, so we will create an
initrd directory structure there... done.

Now cd to /boot/initrd-tree and install some modules in your
module directory (lib/modules/4.4.19).  Then see init
for more information (there are a few other files to edit).
Finally, run mkinitrd again once the initrd-tree is ready,
and /boot/initrd.gz will be created from it.

I have read "/boot/README.initrd" and gone through gslapt. I don't see any other "kernel-generic" or "kernel-modules" that I could install. I have looked at the "init" script, but don't think that there is anything that I should edit, as I haven't changed anything. Am I good to go to run mkinitrd again?

Right - excellent! Interesting that it now boots without panicking.

Before you get on to the initrd, though, you should upgrade your kernel. Instructions for how to do that are on the wiki. Remember to run lilo (locally this time) before rebooting. You shouldn't need to edit lilo.conf, but it may be as well to check. You want the image line to point to /boot/vmlinuz.
https://docs.salixos.org/wiki/How_to_in ... ent_kernel

I will pop back in after breakfast.

Edit
You might as well do a full upgrade as well:

Code: Select all

sudo spi -U

I think that will pull in a new LILO package, among other things.

mimosa wrote:Right - excellent! Interesting that it now boots without panicking.

Before you get on to the initrd, though, you should upgrade your kernel. Instructions for how to do that are on the wiki. Remember to run lilo (locally this time) before rebooting. You shouldn't need to edit lilo.conf, but it may be as well to check. You want the image line to point to /boot/vmlinuz.
https://docs.salixos.org/wiki/How_to_in ... ent_kernel

I will pop back in after breakfast.

Edit
You might as well do a full upgrade as well:
Code: Select all
sudo spi -U
I think that will pull in a new LILO package, among other things.

Thanks for the very timely reply mimosa. OK, I ran:

Code: Select all

$ sudo slapt-get -i kernel-huge kernel-modules kernel-headers kernel-firmware

with no errors.

Did you run lilo and reboot?

Assuming all is well there, to return to the initrd, you seem to have forgotten our discussion a number of pages back about the script used to work out the right command to generate it. It will also output a nice LILO stanza for you to copy and paste into lilo.conf.

I suggest that rather than deleting the existing Salix stanza there, you comment it out, so it can easily be recovered if the new one doesn't work.

This is the command to run the script:

Code: Select all

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

In my case the output is as follows, but it will be different on your system:

Code: Select all

#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 4.4.111 -f btrfs -r /dev/sda2 -m usb-storage:xhci-hcd:xhci-pci:ohci-pci:ehci-pci:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:btrfs -u -o /boot/initrd.gz
# An entry in 'etc/lilo.conf' for kernel '/boot/vmlinuz-huge-4.4.111' would look like this:
# Linux bootable partition config begins
# initrd created with 'mkinitrd -c -k 4.4.111 -f btrfs -r /dev/sda2 -m usb-storage:xhci-hcd:xhci-pci:ohci-pci:ehci-pci:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:btrfs -u -o /boot/initrd.gz'
image = /boot/vmlinuz-huge-4.4.111
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = 4.4.111
  read-only
# Linux bootable partition config ends

So in my case, I would need to select and paste this command into the terminal to make the initrd:

Code: Select all

sudo mkinitrd -c -k 4.4.111 -f btrfs -r /dev/sda2 -m usb-storage:xhci-hcd:xhci-pci:ohci-pci:ehci-pci:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:btrfs -u -o /boot/initrd.gz

Note that I needed to prepend 'sudo', because root priviliges are needed. Yours will be different (for instance, you probably didn't choose to format any partitions with btrfs).

Edit lilo.conf by inserting the new suggested stanza and commenting the old one, run lilo, cross your fingers, and reboot.

Edit It may be as well, before rebooting, to download the generic kernel just in case it is needed later:

Code: Select all

wget http://mirrors.nix.org.ua/linux/salixos/x86_64/slackware-14.2/patches/packages/linux-4.4.118/kernel-generic-4.4.118-x86_64-1.txz

As you may recall, I don't think we need the generic kernel in order to boot with an initrd, though you do need an initrd to boot the generic kernel and that is when it is normally used. The advantage of sticking with huge is it will be simpler to recover from any problems.

mimosa wrote:Did you run lilo and reboot?

I had a problem with the slackware.uk repo for Salix crapping out for some reason. I had to give it some time, but ended up having to do a CTRL C escape and then re-run. Everything seems to be OK, however. OK, I ran

Code: Select all

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

The result is here:

Code: Select all

$ sudo /usr/share/mkinitrd/mkinitrd_command_generator.sh /boot/vmlinuz
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 4.4.118 -f ext4 -r /dev/sda1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz
# An entry in 'etc/lilo.conf' for kernel '/boot/vmlinuz-huge-4.4.118' would look like this:
# Linux bootable partition config begins
# initrd created with 'mkinitrd -c -k 4.4.118 -f ext4 -r /dev/sda1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz'
image = /boot/vmlinuz-huge-4.4.118
  initrd = /boot/initrd.gz
  root = /dev/sda1
  label = 4.4.118
  read-only
# Linux bootable partition config ends

So the line that you refered to is here:

Code: Select all

mkinitrd -c -k 4.4.118 -f ext4 -r /dev/sda1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz

and I commented out the current entry in lilo.conf. When you refer to no need for a generic kernel, I understand the rationale. Does that mean that something needs to be edited in the above line?

Just put sudo in front of it.

Regarding lilo.conf, it occurs to me you may as well uncomment the original stanza again. You will then be able to choose at boot whether to boot with or without the initrd, making an easy fallback if needed. Make sure the 'label' lines are different, and preferably informative.

Salix Forums

Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.

Re: Apparent freeze during installation of system.