[SOLVED] ELILO only boots stock kernel on Slackware64-14.1

fsLeg · 10-02-2014, 11:23 AM

I recently bought a new laptop, MSI CX61 2OD-062. It had Windows 8 pre-installed, but I had very little trouble installing Slackware once I figured out how to boot into the installer under UEFI. By the way, this laptop is my very first experience with UEFI.

This laptop is pretty good, but for some weird reason Slackware on it doesn't want to recognize my Logitech MX570 trackball, which uses Logitech Unifying Receiver. On my other laptop (Lenovo B550) with the exact same system (Slackware64-14.1) trackball worked out of the box. Both systems use stock generic unmodified kernels. MSI laptop does recognize the receiver properly, but the trackball doesn't want to work. But it works when I boot in Windows or Parted Magic (uses kernel 3.14.4). I googled a bit and it turns out there's a regression in 3.10 kernel that causes Logitech Unifying Receiver not to work properly. So I decided to use a different kernel.

This is where things get confusing. ELILO is a simple program, and its config also has very simple syntax. My current elilo.conf:

Code:

chooser=simple
delay=50
timeout=50
default=Slackware
#
image=vmlinuz-3.14.18
        label=SlackNew
        initrd=initrd-3.14.18.gz
        root=/dev/cryptvg/root
        read-only
        append="resume=/dev/cryptvg/swap vga=normal"
image=vmlinuz-generic-3.10.17
        label=Slackware
        initrd=initrd-3.10.17.gz
        read-only
        root=/dev/cryptvg/root
        append="resume=/dev/cryptvg/swap quiet"

3.14.18 kernel is a huge kernel from Slackware64-current. I tested it on my other laptop and it worked flawlessly. But if I choose "SlackNew" at ELILO prompt, I get nothing. The kernel doesn't load. There're no messages from kernel itself (otherwise I would know what to do), but ELILO sports a few errors for a brief moment before rebooting. I managed to take a photo of them, and here they are:

Code:

elilo.c(line 276):
ExitBootSvcs: failed, memory map has changed.

elilo.c(line 279):Main_Loop: Retrying.... have to rebuild boot params

After that the laptop reboots. Googling didn't reveal any solution. Most interesting thing, these errors appear even when I load 3.10.17 kernel, but the system still loads.

I tried compiling my own kernel, I tried generic and huge kernels from -current, I reinstalled ELILO, but nothing helped, I can only boot the stock 3.10.17, both huge and generic. Other kernels don't produce any output, no kernel panic or whatever, the laptop seems to reboot even before the kernel actually tries to load.

I don't want a workaround like switching to grub or some other boot manager, I want to solve this problem (it's more fun that way). But I have no clue where to start. Any ideas?

keefaz · 10-02-2014, 11:57 AM

Quote:

Originally Posted by fsLeg

I don't want a workaround like switching to grub or some other boot manager, I want to solve this problem (it's more fun that way). But I have no clue where to start. Any ideas?

There is a Changelog entry in elilo v. 3-16 about Memory map changes:
http://sourceforge.net/p/elilo/mailman/elilo-announce/

Unfortunately, I don't think you can solve this issue without changing bootloader, eg use new elilo v. 3-16 or maybe use kernel EFI stub feature (which means recompile the kernel with EFI stub and with kernel boot parameters, root= etc... built in the kernel, embed the initrd into the kernel and add kernel to EFI boot entries with efibootmgr)
http://wiki.gentoo.org/wiki/EFI_stub_kernel

fsLeg · 10-02-2014, 12:28 PM

Quote:

Originally Posted by keefaz

There is a Changelog entry in elilo v. 3-16 about Memory map changes

Yeah, I thought about upgrading ELILO, but I thought maybe I did something wrong and there was some way to fix it. And other people who had that error couldn't boot any kernel at all, while I was able to boot a stock one just fine.

Quote:

Originally Posted by keefaz

I don't think you can solve this issue without changing bootloader, eg use new elilo v. 3-16

Using a newer version of ELILO isn't exactly changing a bootloader. It's about upgrading a package that had bugs in it.

Anyway, I upgraded ELILO to 3.16 (had to add one more sed string to Pat's SlackBuild) and it seems to work. Right now I'm on 3.14.18 from -current and my trackball finally works. So my problem is solved.

I saw somewhere here a post asking why ELILO-3.14 was not just in 14.1, but also still in -current. Now I agree that this is a good question.

urka58 · 10-03-2014, 10:42 AM

Quote:

Anyway, I upgraded ELILO to 3.16 (had to add one more sed string to Pat's SlackBuild) and it seems to work. Right now I'm on 3.14.18 from -current and my trackball finally works. So my problem is solved.

Which sed string did you add, I guess in the slackbuild, just to help other people, like me
Thanks

fsLeg · 10-03-2014, 10:57 AM

urka58, here's a diff for more convenience.

Code:

--- a/elilo.SlackBuild       2013-10-29 08:53:28.000000000 +0400
+++ b/elilo.SlackBuild    2014-10-02 21:12:33.214319934 +0400
@@ -60,10 +60,11 @@
 tar xvf elilo-${VERSION}-source.tar.gz || exit 1
 chown -R root:root .
 chmod -R u+w,go+r-w,a-s .
-cd elilo
+cd elilo-$VERSION-source
 
 sed -i "s,/usr/lib,/usr/lib${LIBDIRSUFFIX},g" Make.defaults
 sed -i "s,EFICRT0.*= /usr/lib${LIBDIRSUFFIX},EFICRT0    = /usr/lib${LIBDIRSUFFIX}/gnuefi,g" Make.defaults
+sed -i "s,dpkg-architecture -qDEB_BUILD_ARCH,uname -m,g" Make.defaults
 
 # We will build this from source.
 # However, we will package the pre-built EFI binaries, since we would

AlleyTrotter · 10-03-2014, 11:54 AM

[QUOTE=fsLeg;5248063]

Code:

chooser=simple
delay=50
timeout=50
default=Slackware
#
image=vmlinuz-3.14.18
        label=SlackNew
        initrd=initrd-3.14.18.gz
....

I was always of the belief that when using the huge kernel that an initial ramdisk was not required. Have you tried to remove the "initrd=initrd-3.14.18.gz" line from your elilo.conf?
Just a wild guess.
Thought I would mention this since stock 14.1 boots all huge (.config) kernels up to 3.16.3 without problems here.
John

fsLeg · 10-03-2014, 12:05 PM

Quote:

Originally Posted by AlleyTrotter

I was always of the belief that when using the huge kernel that an initial ramdisk was not required.

That is correct. But if you look at the name of the root partition, you'll see /dev/cryptvg/root, which is an encrypted LVM. In order to mount this partition it has to be there, and for that the kernel needs initrd which puts all needed devices where they belong in the filesystem. Ramdisk isn't just for modules only, which in the case of huge kernel don't even need to be added. With no initrd I would get a kernel panic.

Anyway, the ramdisk definitely wasn't the culprit. If it was, I would get some message from the kernel, not a boot manager.

urka58 · 10-03-2014, 03:26 PM

@fsLeg
Many thanks
Ciao