GRUB Legacy support broken

[Martin Decky]

As of 64f85f54a27d11f2ce4cf0aef2e2fb35918fe5cd, booting HelenOS using GRUB Legacy (a.k.a. GRUB 1) does not work.

GRUB 0.97 from Fedora 12 reports "Error 13: Invalid or unsupported executable format" for the amd64 ELF kernel binary and "Error 7: Loading below 1MB is not supported" for the ia32 ELF kernel binary.

Manually converting the ELF kernel binary to a raw binary using objcopy solves the booting issue, but the VESA graphics mode is not initialized. AFAIK, GRUB Legacy actually never implemented the VESA mode setting (despite the specification) and that was the reason for the real-mode VESA code within SPARTAN that has been removed in e3fa1720e83c1029187354ec92323608505ed7e3.

[Martin Decky]

For the reasons of practicality, I would not object solving this by removing the already unboned multiboot support completely.

[Jiří Zárevúcky]

My apologies, I didn't consider that it should work with older GRUB versions than the one included in HelenOS source.

For VESA, a multiboot bootloader can ignore the modesetting request, but IMO the best solution would be to implement the modesetting in userspace using a realmode emulator (jermar mentioned that someone did that in the past but it was never merged due to quality issues?).

For ELF, that's a bit trickier. The latest multiboot1 specification says that the bootloader must be able to load ELF. We can boot using a bootloader that correctly implements it, GRUB Legacy just happens not to. However, while I very much want kernel to remain in ELF format, I also later plan to add /boot stage for x86, same as other platforms. That will again reduce the requirements imposed on the third-party bootloader.

We could say that we don't support GRUB Legacy right now, but might again in the future, and keep multiboot1 (which we currently use by default with GRUB2). Or we can remove it completely, as you say. I'm fine with either.

[Jiri Svoboda]

For multiboot 1, is there a major multiboot-compliant bootloader that (int it's current version) only supports multiboot 1 that we might want to support?

For GRUB legacy, if we choose to support multiboot 1, I think we should support GRUB legacy. We should make it easier to test - why are we not including GRUB legacy as an option?

Relying only on userspace for setting mode/palette means you cannot get a kernel debug console at boot (not a graphical one, anyway) which can be useful for debugging.

[Jiří Zárevúcky]

Relying only on userspace for setting mode/palette means you cannot get a kernel debug console at boot (not a graphical one, anyway) which can be useful for debugging.

We can just fall back to EGA if bootloader didn't set anything. It shouldn't be a problem.

[Jiri Svoboda]

So how about reverting the change and making it once we're ready? I have regressions in the name of progress.

[Jakub Jermář]

This is unfortunate, there should have been more communication re. this PR on the ML or the only person who actually understood the reasons why things are done that way (i.e. Martin) should have been asked for a review, with some longer timeout (a week?). Let's remember this for the next time.

However, does anyone know why we need to support GRUB legacy when GRUB2 does support multiboot1?

[Martin Decky]

Like I have written, I really don't demand that we keep supporting GRUB Legacy. I think that most other operating systems that use any version of multiboot have also switched completely to GRUB 2 by now.

I am just saying that having multiboot1 is essential for GRUB Legacy. If we choose not to support GRUB Legacy anymore (and this is what effectively happened), we can remove the multiboot1 support completely, keep just the multiboot2 support and switch the GRUB 2 configuration to use multiboot2 exclusively.

Of course, the VESA VBE extension support during bootstrap was always meant as a debugging and last-resort aid. For production deployments, a user space VESA driver would be the ideal solution. This has been in the making as a GSoC 2014 project (see VESA), but unfortunately never finished due to dissatisfaction with the student's progress and code quality.