Opened 6 years ago
Last modified 6 years ago
#770 new defect
GRUB Legacy support broken
Reported by: | Martin Decky | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | helenos/unspecified | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description (last modified by )
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.
Change History (14)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
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.
comment:3 by , 6 years ago
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.
comment:4 by , 6 years ago
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.
follow-up: 10 comment:5 by , 6 years ago
So how about reverting the change and making it once we're ready? I have regressions in the name of progress.
comment:6 by , 6 years ago
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?
comment:7 by , 6 years ago
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.
comment:8 by , 6 years ago
Description: | modified (diff) |
---|---|
Summary: | multiboot support broken → GRUB Legacy support broken |
comment:9 by , 6 years ago
I have edited the original ticket to be more precise. Yes, GRUB 2 also implements the original multiboot specification. But I wouldn't consider it the "reference" implementation.
comment:10 by , 6 years ago
Replying to Jiri Svoboda:
So how about reverting the change and making it once we're ready? I have regressions in the name of progress.
Having kernel in ELF format simplifies things for me. Reverting it until x86 has /boot
is possible, but ultimately supporting GRUB Legacy gives us nothing and only creates a pointless complication.
comment:11 by , 6 years ago
Martin, can you please confirm that grub-legacy support has been restored? Or shall we close this because it is simply better not to care about grub-legacy anymore?
comment:12 by , 6 years ago
Milestone: | 0.8.0 |
---|
comment:13 by , 6 years ago
I believe this is still broken due to grub-legacy not supporting ELF kernels. That particular breaking change is somewhat older, and I'm not sure simply reverting it wouldn't break other stuff. Right now, my brain is still hibernating, so I don't think I'll have the energy to fix this until after new year.
comment:14 by , 6 years ago
But then that's because grub-legacy is itself broken wrt. ELF kernels. I would drop grub-legacy support, I see no use in supporting it and its limitations.
For the reasons of practicality, I would not object solving this by removing the already unboned multiboot support completely.