SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,011
Rep:
Quote:
Originally Posted by garpu
Yep. 5.19.0 boots just fine on my laptop with regular LILO, no uefi, huge kernel, no initrd. (Desktop is uefi, elilo, and won't boot.)
Maybe see if there is a difference between 5.18.15 and 5.19 config? It seems that this is not an issue with elilo and 5.19 because I can boot 5.19 with elilo just fine.
vmlinuz-huge-5.19.0 works on my Systems (slackware64-current) with lilo, but does not work on my Systems with uefi/elilo and nvme-root (instant reboot).
Older Versions until 5.18.15 did without any problems.
If I change booting to classic and lilo instead of elilo/uefi the same Systems boot with without any problems to vmlinuz-huge-5.19.0.
So I am not sure, if there is a new feature/setting missing only for uefi/nvme or this may too apply to uefi and sata-HDD/SSD
There seems to be a problem related to "uefi stub support". I disabled that and now 5.19.0 boots normally from elilo. Anyone using a boot loader won't have much use for it anyway.
Last edited by rogan; 08-02-2022 at 09:17 AM.
Reason: spelling
There seems to be a problem related to "uefi stub support". I disabled that and now 5.19.0 boots normally from elilo. Anyone using a boot loader won't have much use for it anyway.
BUT, this "uefi stub support" is needed by those who uses rEFInd as EFI boot-loader.
Because technically the rEFInd treats a Linux kernel as an ordinary EFI binary.
So, we should chose what we broke in Slackware? ELILO or rEFInd?
Last edited by LuckyCyborg; 08-02-2022 at 09:38 AM.
There seems to be a problem related to "uefi stub support". I disabled that and now 5.19.0 boots normally from elilo. Anyone using a boot loader won't have much use for it anyway.
Is there a kernel append entry to disable efi stub support or does the kernel have to rebuilt with CONFIG_EFI_STUB not set?
Is there a kernel append entry to disable efi stub support or does the kernel have to rebuilt with CONFIG_EFI_STUB not set?
I tried to append 'efi=noruntime' but no joy.
The EFI stub is like its name says, a stub which transforms the kernel in a EFI binary - just like is the PE stub for the programs and DLLs of the operating system loved by everybody and invented by Bill Gates. In fact, from what I heard, the EFI binaries are some kind of PE programs too.
When there's a problem in the EFI stub, I guess that the kernel did not even start, so no kernel parameters will help you.
But the Grub2 will do. Tested myself.
Last edited by LuckyCyborg; 08-02-2022 at 10:38 AM.
Is there a kernel append entry to disable efi stub support or does the kernel have to rebuilt with CONFIG_EFI_STUB not set?
As far as now you need to re-configure and re-build your kernel. Doing this indeed will deprive your kernel of the ability to bootstrap itself, with possibly a bundled initrd, making of it a live system packed in a single EFI binary as well as an EFI OS loader, thus not needing any external boot loader (lilo, elilo, syslinux, grub2, systemd-boot, rEFInd, whatever). In other words, you can't eat your lunch and have it. Using this features means that every time you install a new kernel you have to rebuild it, so that that's just a use case among others.
Last edited by Didier Spaier; 08-02-2022 at 10:57 AM.
Is there a kernel append entry to disable efi stub support or does the kernel have to rebuilt with CONFIG_EFI_STUB not set?
I tried to append 'efi=noruntime' but no joy.
Chuck56 --
There is a new Kernel Commandline Parameter in /usr/src/linux-5.19.0/Documentation/admin-guide/kernel-parameters.txt that claims to do what you suggest:
Code:
efi= [EFI]
Format: { "debug", "disable_early_pci_dma",
"nochunk", "noruntime", "nosoftreserve",
"novamap", "no_disable_early_pci_dma" }
debug: enable misc debug output.
disable_early_pci_dma: disable the busmaster bit on all
PCI bridges while in the EFI boot stub.
nochunk: disable reading files in "chunks" in the EFI
boot stub, as chunking can cause problems with some
firmware implementations.
noruntime : disable EFI runtime services support
nosoftreserve: The EFI_MEMORY_SP (Specific Purpose)
attribute may cause the kernel to reserve the
memory range for a memory mapping driver to
claim. Specify efi=nosoftreserve to disable this
reservation and treat the memory by its base type
(i.e. EFI_CONVENTIONAL_MEMORY / "System RAM").
novamap: do not call SetVirtualAddressMap().
no_disable_early_pci_dma: Leave the busmaster bit set
on all PCI bridges while in the EFI boot stub
And it appears to match the syntax that you tried.
I'm not ready to try 5.19.y in my Slackware64 15.0 system yet so I can't say whether it actually works for me or not ...
HTH
-- kjh
p.p.s. I run GRUB2 and I won't be reverting so I can't help here ...
p.s. reading Didier's Post ... here is a blurb from /usr/src/linux-5.19.0/Documentation/admin-guide/efi-stub.rst
Code:
=================
The EFI Boot Stub
=================
On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
as a PE/COFF image, thereby convincing EFI firmware loaders to load
it as an EFI executable. The code that modifies the bzImage header,
along with the EFI-specific entry point that the firmware loader
jumps to are collectively known as the "EFI boot stub", and live in
arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
respectively. For ARM the EFI stub is implemented in
arch/arm/boot/compressed/efi-header.S and
arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
between architectures is in drivers/firmware/efi/libstub.
For arm64, there is no compressed kernel support, so the Image itself
masquerades as a PE/COFF image and the EFI stub is linked into the
kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
and drivers/firmware/efi/libstub/arm64-stub.c.
By using the EFI boot stub it's possible to boot a Linux kernel
without the use of a conventional EFI boot loader, such as grub or
elilo. Since the EFI boot stub performs the jobs of a boot loader, in
a certain sense it *IS* the boot loader.
The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
Last edited by kjhambrick; 08-02-2022 at 10:52 AM.
Reason: p,s,p.p.s.
I doubt this will work, as we are speaking about boot time support, not run time. Further that's not a good idea IMHO as this probably disallow you to edit the NVRAM variables from a running system......
Last edited by Didier Spaier; 08-02-2022 at 11:16 AM.
This is pure speculation, but I suspect elilo uses the efi stub by default and acts as a boot loader if it has to. That would explain why it works with a kernel without the stub.
Has anyone tried using rEFInd with the 5.19.0 ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
