I am using the x86 builds that boot using grub. For the 24.10 release, Grub 2.12 is used. This causes issues at my older hardware (that is still good enough for routing a gigabit) that can not boot with it - well it can when booting in legacy mode and not with EFI.
error: cannot load image.
Press any key to continue ...
In OpenWrt 23.05, grub 2.06 is used which works perfectly fine. I can take the grub efi file from the old image and put it into the new image and then everything works again. One of the changes in the new grub version is that loading linux kernels is delegated to the EFI implementation. Another project solved this by patching grub so that they can use the new grub version but use the old loading routine.
The question is: How should/could this be handled with OpenWrt? I could imagine that I am not the only user of old hardware.
Can you elaborate on how you achieved this? I wouldn't mind giving this a try myself as well, as 24.10 is unbootable on my Qotom appliance, too (blank screen after GRUB boot menu, and loss of keyboard input that is never restored)
Checked my grub setup on 23.05.5 and nomodeset isn't even there as a kernel param, interestingly. But if including that fixes my issue on 24.10 I will be able to test it later tonight then, hopefully
I extracted the old OpenWrt version image to a disk and mounted the first? partition. I copied the grub efi file (I would need to look up the exact path). Then I extracted the new version, mounted the partition again and overwrite the file there with the one from the old version.
However, it is very likely that this only helps with the error message that I got. In this case, grub can not start the kernel and grub itself shows the error message.
As I now have an older x86-64 device running as my backup router for the time being, I've finally been able to test this a little more. I juts flashed 24.10 over a perfectly-working 23.05.5 image. Rebooted, then in grub I added nomodeset, verifying that it was typed correctly and spaced separate from the other boot parameters, and then I pressed F10 to boot using this new set of parameters.
Immediately saw the screen change to "booting a command list" which I expect, however, keyboard input still diseppeared completely. I can still see that it's still displaying the message from above, so I can only presume the system is frozen completely.
So, I ended up re-assessing this subject a few days ago. I found that OpenWrt release 24.10.2 is still broken on boot for me. From a combination of recent and past reading, seems like a widespread problem affecting any target device that contains a CPU from Intel's Apollo Lake generation, along with an older BIOS.
Still not sure what the root issues is. But I was wondering if the x86/legacy OpenWrt target would work. I thought to myself that it should, being for legacy x86 devices. Sure enough, installing it on my Qotom device and it works perfectly, just like the amd64 release builds of 23.05.5 and prior.
I would have thought there'd be more people talking about this issue, as there are a lot of these devices being sold with Intel Apollo Lake CPUs. I'm still perplexed as to why only few people seem to be talking about it and/or may be affected by it.
At the end of the day, if the legacy, 32-bit builds still work on my device, I think I'll just stick with those for now. It's not 100 percent ideal, of course, as the Intel Celeron J3455E in this device is a 64-bit processor, but at least with it being x86, it still has its legacy x86-32 capabilities available to me. So I'll stick with that until I can get something newer maybe, like a device with an Intel N100 processor, or similar.
32 legacy images should not be considered an alternative on x86_64 hardware, not even as a fallback. OpenWrt does work fine on my older baytrail-d j1900 system (I don't have apollo lake), so there is no inherent reason why it should fail.
As OpenWrt gets less testing on 'weird' system combinations than the big distributions, it's more likely to find bugs - but those can only be fixed, if someone with the hardware debugs them. May be something as simple as a missing grub module, an unfortunate configuration (e.g. tty assignment to serial without physical serial interfaces), BIOS vs UEFI, DOS MBR vs GPT, boot flag (broken BIOS), … It's difficult to give advice if you can't see the error (and 'play around').
Running 32 images on x86_64 hardware is possible, but strongly discouraged. You lose support for larger RAM, multiple cores, a whole load of advanced security features and performance.
Yeah, I'm very aware it's far from ideal. Sadly I feel like I have no choice on the matter at this point, especially as any x86-64 build of 24.10.x just presents me with a completely black screen on boot up. I'm hardly a developer, so I wouldn't even know where to start from there, plus at the end of the day I have the goal of finding something that just works without having to spend potentially hundreds of hours learning development tools or such, just for a one-time purpose for debugging this.
I briefly tried OPNsense 25.1, which is the latest release of that particular variant of FreeBSD. And it would boot up perfectly, just like OpenWrt 23.05.5, as well as prior versions of OPNsense I have used on this device in the past. Unfortunately I don't find OPNsense nearly as flexible as OpenWrt (biggest example being a lot more community support behind OpenWrt with facts like having access to wayyy more community packages and repos)
So I'm not sure what else to do aside from running a 32-bit kernel with 32-bit binaries, even if I don't get access to all 4 GiB of the DDR3L RAM in this system, I still have 1 GiB which is plenty. I think the first bottleneck would be only having access to a single core.
I can get into the GRUB boot menu just fine. Where it's failing is right as it attempts to boot from there (both normal and failsafe modes will fail in the exact same manner with a black screen)
