Limine version used
2.67.2

Expected behavior
Boots the Linux kernel.

Actual (broken) behaviour
PANIC: linux: Unable to set video mode

To Reproduce
Use the following config

TIMEOUT=5

:Arch Linux

PROTOCOL=linux
KERNEL_PATH=boot:///vmlinuz-linux
CMDLINE=root=/dev/vda2 rw loglevel=3 quiet
MODULE_PATH=boot:///initramfs-linux.img

Stacktrace

Stacktrace:
  [0xb63a] <panic+0x4d>
  [0x1a85a] <linux_load+0x3ba>
  [0x1050c] <stage3_addr+0x2dc>
  [0x936d] <entry+0x133>
End of trace. Press CTRL+ALT+DEL to reboot.

Additional information
QEMU VM / VPS accessed via noVNC.

The stivale2_struct_tag_smp tag has an array of cpus in smp_info. It seems that the BSP might not be the one with lapic_id 0 and might not be the first entry in smp_info.
Then if one wants to know which entry the BSP is (to avoid trying to restart it, ...), one might need to use CPUID or something, and walk the array to compare, and, maybe, the method that one used, wasn't the same as the bootloader used and could provide different results.
The bootlader has that information firsthand, and it might be possible to add a field in stivale2_struct_tag_smp like bsp_index, that indicated the index of the entry in smp_info that the BSP is.

There's no need to compile with support for filesystems that the scenario doesn't require. Same with image support and a bunch of things that could lower the final size of the binary.

Limine version used
trunk@be2b099b

Expected behaviour
Limine would build with full LLVM toolchain

Actual (broken) behaviour
The configure script rejects lld (ld.lld) as it's version string contains "compatible with GNU linkers" not "Free Software Foundation".
It also rejects llvm-ar, llvm-as, llvm-objdump, llvm-objcopy and llvm-readelf, which don't contain any reference to GNU in their version strings.

Patching out those checks - the build progresses until it attempts to link common-uefi32/limine_nomap.elf (log).

To Reproduce
Configuring with ./configure CC=clang LIMINE_LD=ld.lld LIMINE_AR=llvm-ar LIMINE_AS=llvm-as LIMINE_OBJDUMP=llvm-objdump LIMINE_OBJCOPY=llvm-objcopy LIMINE_READELF=llvm-readelf (Yes I know TOOLCHAIN exists I was just going through them one by one). I have tried on macOS and on Linux with both having the same behaviour.

Stacktrace
N/A

Additional context
I am using LLVM 13.0.1 (from Homebrew on macOS, from source on Linux).

Hello,

I am new to bootloaders and am working on a new kernel project that builds a x86_64 elf kernel.

I really did not want to use GRUB and wanted to find something new and came a cross your Limine project that seems like it will boot elf images.

Is there a simple demo ISO that I can download and see it in action before I dig into the coding?

Limine version used
trunk bcced19

Expected behaviour
KASLR performed for PIE kernels, virtual and physical address randomized

Actual (broken) behaviour
Kernel is always mapped at P: 0x0000000007AF3000 V: 0xFFFFFFFF80000000 when booting with the Limine protocol.

To Reproduce
Comple kernel with the following flags:
COMFLAGS=-mno-red-zone -O2 -mno-sse -mno-mmx -mno-80387 -Wall -Wextra -pedantic
CFLAGS=${COMFLAGS} -std=c17 -Iinclude -ffreestanding -fno-asynchronous-unwind-tables -fPIE -pipe
LDFLAGS=${COMFLAGS} -Wl,-pie -nostdlib -z max-page-size=4096

Observe non randomized values in limine_kernel_address_response

Stacktrace
N/A

Additional context
Booting with stivale2 results in correctly randomized physical and virtual addresses.

Limine version used
2.68.2 (binary branch)

Expected behavior
BusyBox init to load and thus bring up the system

Actual (broken) behaviour
Blank screen? I think the system is up since there's CPU usage in the VM

To Reproduce
Try booting ./build/ikeda after running ./build.sh qemu from https://git.tar.black/ikeda/Ikeda/-/tree/limine (ensure limine branch :) )
Expected behavior can be seen doing the same with the main branch (using GRUB2)

Stacktrace
N/A

Additional context
I saw another closed issue about VM memory, so I tried using virt-manager instead of just pure qemu

/boot/limine.cfg contents:

PROTOCOL=linux
KERNEL_PATH=boot:///boot/bzImage
KERNEL_CMDLINE=quiet

(same behavior w/o quiet param.)

I'm happy to share the source disk image(s) in question, just not sure how to do so well since they're 2.9GB

Hello,
I am working on a kernel that uses stivale2 and compiles with LLVM and GNU. LLD, LLVM's linker, however, has a bug which prevents it from outputting the stivale2 header correctly and makes Limine bite the dust loading it. For this reason, it might be a good idea to have an alternative loading system in Stivale 2 that does what multiboot does (check in the first 8K or so for the image). That would make stivale2 work with kernels compiled with LLVM! I can contribute it if you would like.
Thanks,
nexos-dev

Limine version used
Commit 92d4246 at lukflug:trunk.
Only difference from Commit 0228c06 is that I've added legacy-fat16-test and mbrhdd.bin directives to the Makefile, in order to test it.

Expected behavior
panic("Memory allocation failure.")

Actual (broken) behaviour
Recursively calls panic. Evident as bootloop, presumably due to triple faulting due to a stack overflow or something like that.

To Reproduce
x86Box:

• Slot 1
• [i440FX] ASUS P/I-P65UP5 (C-PKND)
• Intel Pentium II (Klamath) @ 100MHz
• 16MB RAM
• [PCI] ATI Mach64GX with 4MB VRAM
• [PCI] IDE Controller (Dual-Channel)
• Hard Drive: mbrtest.hdd with CHS=130/16/63

Stacktrace
As there is no panic, I can't provide a stacktrace, but I was able to manually track down the program flow:

entry (entry.s2.c: 98)
init_memmap (pmm.s2.c: 269)
memmap_alloc_range (pmm.s2.c: 787)
panic (panic.s2.c: 22)
term_textmode (term.s2.c: 164)
init_vga_textmode (vga_textmode.s2.c: 143)
ext_mem_alloc (pmm.s2.c: 588)
ext_mem_alloc_type (pmm.s2.c: 592)
ext_mem_alloc_type_aligned (pmm.s2.c: 600)

After that it calls panic again, closing the loop.

Additional context
I was trying out Limine on a P6-class x86Box machine and ran into a boot loop. It may be that this machine doesn't support 0xE820 and that Limine reads garbage and passes it to the PMM. But regardless what causes the PMM initialization to fail, it calls panic, which decides to initialize textmode, which causes a framebuffer to be allocated, which fails due to the PMM not being initialized yet.

The core problem being reported here is thus a circular dependency which causes and infinite loop if Stage 2 panics too early.

The version of Limine that I used was Unstable, with commit hash 7f1dd08

Limine will not boot any operating systems. Upon selecting the os that I want to boot, Limine spits out some information about Loading ELF before giving a blank screen and not booting the kernel nor doing anything.

I expected the kernel to start after selecting it on the menu screen.

Instead what happens is that it just gives me a blank screen.

All I did was run a vhd with a FAT-32 partition and limine installed (using limine-install) in qemu. Upon boot, the limine screen shows up, but when I select an os, it loads for a few seconds then gives me a black screen.

There was no stack trace at all. Neither was there a panic screen.

I have recreated this problem with 2 Operating Systems. First with Skift OS Then with This Tutorial.

PS: I think the issue is with limine-install but I'm not yet sure.

limine seems very insistent on working with GNU binutils only, requiring me to compile them just for this one package. Is support for LLVM toolchain planned for the future?

Limine will fall into panic while booting on a hyper-v virtual machine. I attached screenshot as below:

It might be useful that the dimensions of the framebuffer could be also specified in limine.cfg, per entry, like FRAMEBUFFER=1920x1080x32 or something.
It would only be used if the kernel requested a graphical framebuffer. Or even it would only be used if the request was a default request (0,0,0).
The rationale is that the automatically selected default dimensions might not be the desired ones, and it is easier to change limine.cfg, or to specify several entries with different dimensions and the same kernel, than to change the kernel's source code and recompile it, to adapt to different machines, for example.

Limine version used
This happens on trunk (17c59eebd409d97791d0438134de53a3a8defa3e)

Expected behavior
As the stivale2 spec says: Usable and bootloader reclaimable entries are guaranteed to be 4096 byte aligned for both base and length.

Actual (broken) behaviour
Bootloader reclaimable entries are not 4096 byte aligned for both base and length when using ext4 filesystem.

To Reproduce
Simply modify the ext2-test target to use mkfs.ext4 instead of mkfs.ext2

The test image spits out the following ranges (and you can see that some of the bootloader reclaim is not aligned properly):

                [0x1000+0x6a90] 0x1000
                [0x8a90+0x31570] 0x1000
                [0x3a000+0x65000] 0x1
                [0x9fc00+0x400] 0x2
                [0xf0000+0x10000] 0x2
                [0x100000+0x7334000] 0x1
                [0x7434000+0x376200] 0x1000
                [0x77ab200+0x8e00] 0x1000
                [0x77b4000+0x160000] 0x1001
                [0x7914000+0x200] 0x1000
                [0x7915200+0x2e00] 0x1000
                [0x7918000+0x160000] 0x1001
                [0x7a78000+0x200] 0x1000
                [0x7a79200+0xfe00] 0x1000
                [0x7a89000+0x45000] 0x1001
                [0x7ace000+0x9200] 0x1000
                [0x7ad8200+0x498000] 0x1000
                [0x7f71200+0x20000] 0x1000
                [0x7f92200+0x12000] 0x1000
                [0x7fa5200+0x3ae00] 0x1000
                [0x7fe0000+0x20000] 0x2
                [0xfd000000+0x1d4c00] 0x1002
                [0xfffc0000+0x40000] 0x2

Limine version used
Tested on the most recent release (v1.0.6)

Describe the bug
When the handoff from Limine to my kernel entry occurs, I pop off what I believe to be the address of the boot info struct, but instead I always get a null pointer (0).

Expected behavior
I expect to get a non-null address pointing to the boot info structure.

Actual (broken) behaviour
The popped value is always null.

To Reproduce
Checkout 187-Limine-Migration from https://github.com/panix-os/Panix.git

git submodule update --init
make
make run

Observe boot info printed as null in the console.

Bootloader info at 0x0

Additional context
I believe that the bug is in stage2/protos/stivale.c in stivale_spinup.
I believe the code that reads

"mov esp, dword ptr [esi]\n\t"
"push edi\n\t"
"push 0\n\t"

Should be

"mov esp, dword ptr [esi]\n\t"
"push 0\n\t"
"push edi\n\t"

Since the spec says that first a null stack frame is pushed before the boot info is pushed. This change makes my code work properly.

If this indeed is an issue, I am willing to submit a PR to fix it.

Do you have plans to support btrfs and f2fs?

During development, grub-mkrescue is pretty essential for building quick ISO images for testing in e.g. VMware or Qemu (via -cdrom).

Would it be possible to supply a limine-mkrescue utility that does something similar?

Limine version used
Commit bcc72e3, UEFI

Expected behaviour
When running qemu with -nographic, I should see Limines output.

Actual (broken) behaviour
I don't see any output until my kernel boots.

To Reproduce

1. Boot kernel with qemu options -serial stdio -nographic. No limine output should be seen (even though the display also points at stdio).

Stacktrace
No stack trace.

Additional context
Also routing serial port output through stdio but this theoretically shouldn't matter.

Limine version used
Release version v2.7.

Expected behavior
A proper, correctly-detailed memory map stivale2 structure tag.

Actual (broken) behaviour
Incorrect entries field.

To Reproduce
Use Limine v2.7, create a stivale2 kernel, find the memory map structure tag, and attempt to parse it, and entries will be incorrect.

Stacktrace
N/A

Additional context
I was switching to stivale2 and this bug just had to rear its ugly head.

Limine version used
Latest binary

Expected behavior
When I print "\b \b" at start of the line, cursor should go to end of the last line

Actual (broken) behaviour
It goes to the end of NEXT line

To Reproduce
Print "\b \b" at start of the line

Additional context
I'm not entirely sure that this isn't expected behavior and I think old version worked fine

Limine version used
v3.0 BIOS and UEFI

Expected behaviour
After updating cr3 everything should work and no page fault should occur.

Actual (broken) behaviour
After new cr3 function returns but when a new function is called I get page fault at any address with the error e=0003 (Reserved bit exception?)
Tested on VMware and qemu, BIOS and UEFI. Same problem.

To Reproduce
Write a new Page Table level 4 in the cr3 register using Stivale2 protocol (I didn't test with Limine or other ones)

Additional context
Video of the problem.

Add support for ISO9660 so it can boot from a live CD. I'll try to do it myself in the next few days if I have the time.

Limine version used
Limine 3.4.1 bios

Expected behaviour
Limine returns the right RSDP pointer.

Actual (broken) behaviour
Limine returns incorrect RSDP pointer in Virtualbox when booting with Limine boot protocol, but the correct RSDP pointer is returned. when booting with stivale2.

To Reproduce
Booting this image in virtualbox.
The code can be found here (the only modification is the print of the RSDP pointer)
Selecting the Limine protocol will return an incorrect RSDP pointer.
Selecting the Stivale2 protocol will return an correct RSDP pointer.

The RSDP pointer is printed in the serial log.

Additional context
Virtualbox Limine Protocol (Kernel serial log):

[main.cpp:66] Hello, world!
[main.cpp:67] Booting FoxOS using the limine boot protocol...
[main.cpp:68] rsdp: ffff8000000e0000

Virtualbox Stivale2 Protocol (Kernel serial log):

[main.cpp:66] Hello, world!
[main.cpp:67] Booting FoxOS using the stivale2 boot protocol...
[main.cpp:68] rsdp: e0000

The configuration keys BACKGROUND_PARTITION and BACKGROUND_PATH, for example, are undocumented.

I was wondering if limine had support for other executable format aside from elf, like PE or MachO. It would be quite neat!

Hitting space bar to boot highlighted entry. Many bootloaders support booting by pressing space bar, it is more convenient.

Hello,

I have downloaded the v2.83 binary releases from:

https://github.com/limine-bootloader/limine/tree/v2.83-binary

Then I set up a test directory:

iso-root/
     limine.sys
     limine.cfg

    boot/
          bg.bmp
          limine-cd.bin
          limine-eltorito-efi.bin
          test.elf

the test.elf is my test kernel.

The limine.cfg is the default "sample" limine.cfg and I tried to adjust my paths and names to match for a first attempt.

Then I ran:

xorriso -as mkisofs -b iso_root/boot/limine-cd.bin -no-emul-boot -boot-load-size 4 -boot-info-table --efi-boot iso_root/boot/limine-eltorito-efi.bin -efi-boot-part --efi-boot-image --protective-msdos-label iso_root -o image.iso

But now get the error message:

test$ xorriso -as mkisofs -b iso_root/boot/limine-cd.bin -no-emul-boot -boot-load-size 4 -boot-info-table --efi-boot iso_root/boot/limine-eltorito-efi.bin -efi-boot-part --efi-boot-image --protective-msdos-label iso_root -o image.iso

xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:image.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 1469g free
Added to ISO image: directory '/'='/home/lonnie/Limine/test/iso_root'
xorriso : UPDATE :       7 files added in 1 seconds
xorriso : FAILURE : Cannot find in ISO image: -boot_image ... bin_path='/iso_root/boot/limine-cd.bin'
xorriso : UPDATE :       7 files added in 1 seconds
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'

Any ideas as to what I missed which is probably something simple that I just do not see yet.

Thanks

When trying to boot Linux with initrd I get:

PANIC: Out of memory

The same files loaded from a different drive, work.
(EDIT: IT works if the kernel/initrd are on the same drive as Limine. Otherwise not.)

Limine version used
Both binary release v2.3.6 and HEAD at the time of writing (3702060)

Expected behavior
I expected limine to load my 64bit stivale2 kernel image and jump into it.

Actual (broken) behaviour
It crashed with "stivale2: ELF64 load failure".

After a short debugging session and code crawl in limine, I figured this to be the problem: https://github.com/limine-bootloader/limine/blob/trunk/stage23/lib/elf.h#L8

Limine has another definition of "higher half" than my kernel, which has the following LOAD segments:

  LOAD           0x0000000000000000 0xffff800001000000 0xffff800001000000
                 0x0000000000015bd6 0x0000000000015bd6  R      0x1000
  LOAD           0x0000000000015be0 0xffff800001016be0 0xffff800001016be0
                 0x000000000000c5d2 0x000000000000c5d2  R E    0x1000
  LOAD           0x00000000000221c0 0xffff8000010241c0 0xffff8000010241c0
                 0x0000000000000068 0x00000000005322b8  RW     0x1000

I believe 0xffff8... to be the correct start of the higher half on 4-level amd64, using this value also works fine when changing the line linked above and with my own loader.

To Reproduce
Build a 64 bit stivale2 kernel image with -Wl,--image-base,0xFFFF800001000000 (might be clang/ld.lld specific flag)

Stacktrace
Will happily provide if needed, but I think there is enough info in here.

Additional context
With limine being a generic bootloader, I'd expect this to be at least configurable somehow. Maybe it isn't needed at all, loading the kernel at a random place while using the image in limine and using whatever is supplied as VADDR for the final mapping.

Anyway, great project and I really like the stivale2 protocol, from what I've read so far - so kudos for that :)

Limine version used
2.88 (latest binary release)

Expected behaviour
My kernel should boot fine.

Actual (broken) behaviour
Limine believes I'm requesting text mode even though I'm not.

To Reproduce
Not honestly sure what I did wrong, here's how I declared everything:

• Stack: pointed to kernel stack (Limine still thinks stack is 0x0)
• Flags: (1<<1)|(1<<2)|(1<<3)|(1<<4)
• Tags:
  • Any video tag, preference 0
  • FB tag, BPP 32
  • Terminal tag
  • SMP tag, use X2APIC
  • 5-level paging tag
  • Unmap NULL tag

Stacktrace

stivale2: Loading kernel `boot:///EFI/BOOT/kernel`...
stivale2: Physical base: 0x7856e000
stivale2: Virtual base:  0xffffffff80000000
stivale2: 64-bit kernel detected
stivale2: Kernel slide: 0x0
stivale2: Entry point at: 0xffffffff80000420
stivale2: Requested stack at: 0x0
acpi: Found RSDP at 0x7fb7e000
acpi: Found XSDP at 0x7fb7e014
acpi: Found SMBIOS 32-bit entry point at 0x7f9ab000
stivale2: Current epoch: 1647183989
PANIC: stivale2: Cannot use text mode with UEFI.
Stacktrace:
  [0x7daa3a81] <panic+0x81>
  [0x7da8a15b] <stivale2_load+0x1d9b>
  [0x7da92dd2] <boot+0x1a2>
  [0x7da94541] <_menu+0x16e1>
End of trace. Press a key to return to menu.

Additional context
I am not requesting text mode. Booting in UEFI. Configuration file follows:

TIMEOUT=0
DEFAULT_ENTRY=1
GRAPHICS=yes
MENU_FONT_SCALE=2x2
EDITOR_ENABLED=no
VERBOSE=yes
SERIAL=yes
RANDOMIZE_MEMORY=yes
:Kernel
PROTOCOL=stivale2
KASLR=yes
KERNEL_PATH=boot:///EFI/BOOT/kernel

stivale only specifies UEFI boot flag but where's the system table?

Limine version used
2.49.1

Expected behavior
Boot without Limine errors.

Actual (broken) behaviour
Failed to allocate memory ranges.

To Reproduce
Clone and run the Skylight repo.

Stacktrace

Additional context
Occurred after copypasting a linked-list heap implementation and adding some modifications.
(I do not expect my OS to fully function in it's current state, but I do expect it to boot.)
I have resumed this project after a six-week hiatus and the previously used version of Limine was v2.17 (it auto-updates).
Running on 512 megabytes of RAM.

Hi guys, Trying Limine for the first time, I found that it ignored a ext4 partition. I have this:

KERNEL_PATH=boot://2/easyos/vmlinuz

I turned off the "encrypt" feature on the ext4 second partition on the boot drive, and Limine does recognize the kernel and boots it.

This problem was fix in grub2 some years ago, and a grub2 developer helped me create a patch for refind, posted here:

https://sourceforge.net/p/refind/discussion/general/thread/6cfc10d3c2/

Would you guys mind looking at that patch, and see how it can be adapted to Limine?

Limine version used
v3.4.3-binary

Expected behaviour
xtrix when compiled with mold (https://github.com/rui314/mold) should boot.

Actual (broken) behaviour
limine screws up the load pretty badly, including the stivale1 header, and it just completly freaks out

To Reproduce
iso: https://dl.malwarez.xyz/broken-xtrix.iso
elf: https://dl.malwarez.xyz/broken-xtrix.elf

try booting the iso and observe triple fault. observe that a hw breakpoint at _start is never hit. observe that the binary is not loaded correctly. note that _start contains an endless loop

Stacktrace
Sadly, no panic

Additional context
I want to build my os with the moldy linker since its way faster, but it no works.

Limine version used
v1.0

Describe the bug
limine-install make target fails on Debian Buster (amd64)

Expected behavior
limine-install make target exits successfully.

Actual (broken) behaviour
ld fails to link it, claims limine.o's “unknown” architecture is incompatible with my i386:x86-64 output format.
I don't think it's objcopy's -O default's fault because I set it to elf64-x86-64, rebuilt the object file and it still had an unknown architecture. I don't think I've ever used objcopy for anything so forgive me if this is really trivial or something. But I couldn't figure out how to build.

To Reproduce

• on Debian Buster
• download relevant source code
• make toolchain
• make bootloader
• make

Stacktrace
N/A

Additional context

• gcc version 8.3.0
• binutils version 2.31.1
• make version 4.2.1, x86_64-pc-linux-gnu

I'll try it on my personal computer to see if I succeed building it there (didn't work, but my setup is really similar there so idk).

If I have neglected to add any information, please ask away.

Limine version used
2.64

Expected behavior
The terminal prints

Actual (broken) behaviour
My kernel just shows a blank screen

To Reproduce
code can be found at https://github.com/nailuj29gaming/esos

Additional context
I'm using the zigvale library to generate the stivale2 header, but I don't think the issue is there

Code can be viewed here
I use example's kernel.ld and a similar Makefile.
The only difference are presence of symbols and asm.

Here is what objdump says:

kernel/bin/kernel.elf:     file format elf64-x86-64
kernel/bin/kernel.elf
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0xffffffff80000050

Program Header:
    NULL off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags ---
    LOAD off    0x0000000000001000 vaddr 0xffffffff80000000 paddr 0xffffffff80000000 align 2**12
         filesz 0x0000000000000285 memsz 0x0000000000000285 flags r-x
    LOAD off    0x0000000000001285 vaddr 0xffffffff80001285 paddr 0xffffffff80001285 align 2**12
         filesz 0x000000000000017b memsz 0x000000000000017b flags r--
    LOAD off    0x0000000000000400 vaddr 0xffffffff80002400 paddr 0xffffffff80002400 align 2**12
         filesz 0x0000000000000000 memsz 0x0000000000000010 flags rw-

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00000285  ffffffff80000000  ffffffff80000000  00001000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       0000000d  ffffffff80001285  ffffffff80001285  00001285  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .eh_frame     00000138  ffffffff80001298  ffffffff80001298  00001298  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .note.gnu.property 00000030  ffffffff800013d0  ffffffff800013d0  000013d0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .bss          00000010  ffffffff80002400  ffffffff80002400  00001400  2**3
                  ALLOC
  5 .debug_info   0000075f  0000000000000000  0000000000000000  00001400  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  6 .debug_abbrev 0000030d  0000000000000000  0000000000000000  00001b5f  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  7 .debug_aranges 00000090  0000000000000000  0000000000000000  00001e6c  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  8 .debug_line   0000022d  0000000000000000  0000000000000000  00001efc  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  9 .debug_str    00000366  0000000000000000  0000000000000000  00002129  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 10 .debug_line_str 000000c4  0000000000000000  0000000000000000  0000248f  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 11 .comment      00000012  0000000000000000  0000000000000000  00002553  2**0
                  CONTENTS, READONLY
SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 kernel.c
0000000000000000 l    df *ABS*  0000000000000000 mem.c
0000000000000000 l    df *ABS*  0000000000000000 gop.c
ffffffff80000000 g     F .text  0000000000000050 stivale2_get_tag
ffffffff8000013a g     F .text  0000000000000024 gop_init
ffffffff800000ca g     F .text  000000000000003e memcpy
ffffffff80000215 g     F .text  000000000000003d draw_pixel
ffffffff800001be g     F .text  0000000000000057 clear
ffffffff80000050 g     F .text  000000000000007a _start
ffffffff80002408 g     O .bss   0000000000000008 cursorpos
ffffffff80002400 g     O .bss   0000000000000008 framebuffer
ffffffff80000108 g     F .text  0000000000000032 memset
ffffffff8000015e g     F .text  0000000000000060 draw_filled_rectangle
ffffffff80000252 g     F .text  0000000000000033 get_pixel

PHDRS header is present, but .stivale2hdr is not.
Any thoughts on this?

P.S. The example kernel errors out (no modifications):

make -C kernel
make[1]: Entering directory '/home/theairblow/limine-barebones/stivale2-barebones/kernel'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/theairblow/limine-barebones/stivale2-barebones/kernel'
rm -rf iso_root
mkdir -p iso_root
cp kernel/kernel.elf \
        limine.cfg limine/limine.sys limine/limine-cd.bin limine/limine-eltorito-efi.bin iso_root/
xorriso -as mkisofs -b limine-cd.bin \
        -no-emul-boot -boot-load-size 4 -boot-info-table \
        --efi-boot limine-eltorito-efi.bin \
        -efi-boot-part --efi-boot-image --protective-msdos-label \
        iso_root -o disk.iso
make: xorriso: No such file or directory
make: *** [Makefile:22: disk.iso] Error 127

I'll try to use my image build script

P.S. Example kernel works

Limine version used
2.56 (x86-64)

Expected behavior
Limine should disable APIC IRQs before entry to kernel, as per Stivale2 spec

Actual (broken) behaviour
APIC IRQs are not disabled, in fact they are enabled by Limine; external IRQs can trigger interrupts. Kernel crash may occur if the kernel is not prepared for this.

To Reproduce
Any boot as far as I can tell, but tested with UEFI.

Stacktrace
N/A

Additional context
Stivale2 spec:

PIC/APIC IRQs are all masked.

See stivale/stivale#8.

Is there a way to make Limine load a UEFI app as a boot option?

Limine version used
2.88 BIOS MBR

Expected behaviour
Limine boot menu.

Actual (broken) behaviour
Limine does not start from IDE (PATA) HDD

To Reproduce
Start Limine on a Dell Latitude C600.

Stacktrace
limine.sys build ID mismatch
PANIC: Failed to load stage 3
Stacktrace:
[0xdaff] <panic+0x86>
[0xe159] <entry+0x7c>

Additional context
Computer is Dell Latitude C600 with 512MB RAM. Same disk image when written to newer computers boots fine. Issue only appears on this old computer. Build ID check is first time memcmp is called. Is asm memcmp implementation the culprit?

The kernel path now takes a URI which is not documented anywhere

Hello,
BIOS has been superseded as of 2019. I think it would be a good idea to add a UEFI loader to the repo. I could contribute it in a series of PRs if you would like it.

I've tried using limine for my distro and it works fine, but I don't get anything on the serial port as with the other bootloaders. I can only wait until the timeout expires and boots the default entry.

Is controlling limine through a serial port a planned feature?

At the moment, the framebuffer tag seems to assume something like ARGB8888 for bpp=32 and RGB888 for bpp=24, but not all framebuffers are like that. For example, there also are framebuffers in the style of RGB101010 with bpp=32, and these cannot be differentiated from ARGB8888 today.

Limine version used
4b724e6

Expected behavior
Limine should boot the file properly, regardless of whether its named the same as the volume

Actual (broken) behaviour
Limine fails to read the actual file, despite it being there and readable when accessing it from a mounted file system.

To Reproduce
I threw this script file together to help me test different setups: https://gist.github.com/czapek1337/d10c28a21130286e11ad8ff4a57b14c5

I believe the kernel in the script I provided can be anything as long as it's a valid ELF executable.

Stacktrace

Additional context
Add any other context about the problem here.

Limine version used
3.0

Expected behaviour
To see printed text, framebuffer, memory, acpi etc

Actual (broken) behaviour
Watch video running both in Qemu and Virtual Box.

To Reproduce
Copied code from test folder.

Stacktrace
VBox.log
Vbox.log file.

Limine fails to boot when TERM_WALLPAPER and TERM_FONT are provided -
https://drive.google.com/file/d/1CkCVJkV9cBkNwCFYW_XxvriSM0P2CIuC/view?usp=sharing
If commented out limine boots fine -
https://drive.google.com/file/d/1HtTqo0_20NLAh0nf_sEOC7mggFd9I2ey/view?usp=sharing

Here is the limine.cfg:

${KERNEL}=boot:///boot/vmlinuz
${ARGS}=root=/dev/sda1 ro vt.default_red=21,202,171,196,135,204,65,231,104,227,175,224,115,225,108,240 vt.default_grn=21,94,203,141,135,152,129,231,104,54,215,167,115,162,191,240 vt.default_blu=21,94,141,98,175,224,121,231,104,54,138,101,201,220,196,240

TERM_WALLPAPER=boot:///boot/splash.bmp
TERM_FONT=boot:///boot/tosh-sat.f16
TERM_FONT_SIZE=9x16
INTERFACE_RESOLUTION=1600x900
INTERFACE_BRANDING=***** AXE *****
INTERFACE_BRANDING_COLOR=1
DEFAULT_ENTRY=1
GRAPHICS=yes
TIMEOUT=3
TERM_BACKDROP=262626
TERM_FOREGROUND=A8A8A8
TERM_BACKGROUND=51262626
TERM_PALETTE=151515;CA5E5E;ABCB8D;C48D62;8787AF;CC98E0;418179;E7E7E7
TERM_PALETTE_BRIGHT=686868;E33636;AFD78A;E0A765;7373C9;E1A2DC;6CBFC4;F0F0F0

:Boot
PROTOCOL=linux
KERNEL_PATH=${KERNEL}
KERNEL_CMDLINE=${ARGS} mds=full quiet

:Safe Mode
PROTOCOL=linux
KERNEL_PATH=${KERNEL}
KERNEL_CMDLINE=${ARGS} single

$ doas fdisk -l
Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C6ABA0D7-B303-794C-9064-E042D2983AD1

Device Start End Sectors Size Type
/dev/sda1 2048 7170047 7168000 3,4G Linux filesystem
/dev/sda2 7170048 8386559 1216512 594M Linux swap
$ uname -a
Linux AXE 5.10.117 #2 SMP PREEMPT Wed, 25 May 2022 13:41:28 +0000 x86_64 GNU/Linux
$ free -h
total used free shared buff/cache available
Mem: 993Mi 13Mi 949Mi 0,0Ki 29Mi 887Mi
Swap: 593Mi 0B 593Mi

Link to the font:
https://github.com/viler-int10h/vga-text-mode-fonts/blob/master/FONTS/PC-OTHER/TOSH-SAT.F16

Link to the wallpaper:
https://drive.google.com/file/d/1WWNO1zgH9OF1OYf4iyfIAejMifU7foOy/view?usp=sharing

Limine version used
Limine v2.73.4

Expected behavior
I expected Linux to boot.

Actual (broken) behaviour
PANIC: linux: Failed to open kernel with path 'boot:///vmlinuz-linux'. Is the path correct?

To Reproduce
Install Arch Linux, follow the default install instructions and then these: https://wiki.archlinux.org/title/Limine

Stacktrace

Stacktrace:
  [0x9cc8] <panic+0x9d>
  [0x1d31f] <multiboot1_load+0x3f>
  [0x1a4ff] <boot+0x12f>
  [0x1b1a3] <_menu+0xbb3>

Additional context

Partitions:

• /dev/sda1 -> swap
• /dev/sda2 -> root

The /boot directory contains a file vmlinuz-linux, initramfs... and also a limine.cfg:

TIMEOUT=5

:Arch Linux

PROTOCOL=linux
KERNEL_PATH=boot:///vmlinuz-linux
CMDLINE=root=UUID=<uuid> rw loglevel=3 quiet
MODULE_PATH=boot:///initramfs-linux.img

Limine version used
v2.69

Expected behavior
Should not happen

Actual (broken) behaviour
Limine page faults at IP=0x000000003E244690

!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData - 0000000000000000  I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
RIP  - 000000003E244690, CS  - 0000000000000038, RFLAGS - 0000000000000287
RAX  - 0000001000000000, RCX - 00000000A0000000, RDX - 0000000000000000
RBX  - 0000000000000000, RSP - 000000003FF025D0, RBP - 000000003FF026F0
RSI  - FFFFFFFF80392000, RDI - 0000000000000100
R8   - 0000000100000000, R9  - 0000000039FE06B0, R10 - 0000000000000001
R11  - 0000000000000010, R12 - 000000000140F630, R13 - 0000000000000000
R14  - 0000000038B51000, R15 - 000000003FED4000
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - 0000001000000000, CR3 - 000000003FC01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000003F9DE000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000003F55C018 0000000000000FFF,   TR - 0000000000000000
FXSAVE_STATE - 000000003FF02230
!!!! Find image based on IP(0x3E244690) (No PDB)  (ImageBase=000000003E23D000, EntryPoint=000000003E241000) !!!!

The IP subtracted by the image base is 0x7690 and if I build limine locally and dump and grep that address in limine_efi.elf I get the following:

    7546:       0f b6 85 c6 fd ff ff    movzbl -0x23a(%rbp),%eax
    754d:       84 c0                   test   %al,%al
    754f:       74 52                   je     75a3 <fat32_open+0x463>
    7551:       41 bc 01 00 00 00       mov    $0x1,%r12d
    int i = 0, j = 0;
    7557:       45 31 f6                xor    %r14d,%r14d
    bool ext = false;
    755a:       45 31 ff                xor    %r15d,%r15d
        if (src[i] == '.') {
    755d:       3c 2e                   cmp    $0x2e,%al
    755f:       0f 84 2b 01 00 00       je     7690 <fat32_open+0x550> # referred here
--
    context->hidden_sectors = bpb.hidden_sectors_count;
    7676:       89 85 9c fd ff ff       mov    %eax,-0x264(%rbp)
    context->sectors_per_fat = context->type == 32 ? bpb.sectors_per_fat_32 : bpb.sectors_per_fat_16;
    767c:       8b 85 ef fe ff ff       mov    -0x111(%rbp),%eax
    context->number_of_fats = bpb.fats_count;
    7682:       88 95 98 fd ff ff       mov    %dl,-0x268(%rbp)
    context->sectors_per_fat = context->type == 32 ? bpb.sectors_per_fat_32 : bpb.sectors_per_fat_16;
    7688:       e9 9d fb ff ff          jmpq   722a <fat32_open+0xea>
    768d:       0f 1f 00                nopl   (%rax)
            if (ext) {
    7690:       45 84 ff                test   %r15b,%r15b # here where it faults

This might not be accurate since the actual release binary does not have debug symbols embedded into it.

This is only reproducible in UEFI and works perfectly fine when using legacy BIOS. Also it is not reproducible with previous versions of limine.

To Reproduce
cc https://github.com/Andy-Python-Programmer/aero/runs/4491775693?check_suite_focus=true

Stacktrace
None