UEFI returns not found on kernel file: intermittent issue

[austanss]

I was testing my OS on real hardware, and I came across a kernel file not found bug.

This is rather interesting.

There are ought to be intermittent bugs when testing on different platforms.

But an issue like this weirds me out. A file is a file, it should always be there. It is there, it works in QEMU. It doesn't work on my computer though.

My directory structure is as follows

Code: Select all

::/
    sys/
        core/
            microCORE.kernel
        res/
            cursor.subi
    EFI/
        BOOT/
            BOOTX64.EFI

Also, I haven't changed the kernel loading code at all since the last time I tested on real hardware and it worked then.
I am unsure if this issue is with my code, my machine, or my disks/partitions/files.

[bzt]

But an issue like this weirds me out. A file is a file, it should always be there. It is there, it works in QEMU. It doesn't work on my computer though.

My guess is, you don't get a valid Volume here. You don't do much error checking (EFI_ERROR(status) isn't enough, you should also check if the returned pointer isn't NULL for example), and your code is a bit hard to follow. Where does "file_system_service.protocol" come from? If it's from here, then that won't work for sure. SFS Protocol is not something you can query with LocateProtocol, you must use a LoadedImage Protocol to get a handle for the boot device and use HandleProtocol on that device handle with SFSGUID, like this (for a GNU-EFI example, see the wiki). But GNU-EFI also provides a short-cut in a form of a library function, you could use

Code: Select all

file_system_service.protocol = LibOpenRoot(loaded_image->DeviceHandle);

Also, I haven't changed the kernel loading code at all since the last time I tested on real hardware and it worked then.

If LocateProtocol for SFS works without a device handle, that's a miracle It shouldn't!

Here's a bit explanation: UEFI is a huge pile of garbage. You never know if you can use a GUID with LocateProtocol or with HandleProtocol. You must GUESS and test it... For example, with GOP, which does not have an associated device with it (it could have, but it doesn't), you use LocateProtocol. But for SFS, which only makes sense when talking about a specific device, needs HandleProtocol. If only UEFI had specified defines with *_LOC_GUID or *_HND_GUID suffixes... but they didn't! So you must GUESS correctly if a protocol needs a handle or not, otherwise your code won't work on some machines.

Cheers,
bzt