Can't find a BIOS bootable OpenWrt image

I've already tested old and new versions: squashfs and normal; efi and non-efi.

I have an i5 that supports efi, and it boots into the efi image just fine and not the BIOS version, the problem is that my core2duo that only supports legacy BIOS doesn't boot into the non-efi images.

Did OpenWrt drop support for legacy BIOS?

Also, my core2duo can boot into the same Debian iso that my i5 can boot into, why doesn't OpenWrt just do the same? one ISO that works everywhere.

No

Those are Legacy images. You’ll likely have to set up a Buildroot to obtain those formats.

No, the non-efi images are made for BIOS booting (legacy CSM).

EDIT: fixing the links to actually point to x86_64

BIOS/ legacy CSM:

UEFI:

…but there are some BIOS variants with rather peculiar expectations about the disk and its bootloader (bootflag, yes/no, etc.).

Creating a disk image (which is different from an ISO hybrid image, as the later would be read-only) that can boot from either BIOS mode or UEFI is possible, but rather complicated and fragile - and it will break even harder exactly on those quirky BIOS variants that might fail for you right now. (UEFI requires GPT, but later BIOS variants (around ICH7/ ICH8) on the cusp between classic BIOS and UEFI (so basically an UEFI BIOS with enforced legacy CSM) might not like GPT for BIOS booting (but would fail booting in UEFI mode). Having dedicated images for either is easier - and more forgiving with these 'special' BIOS variants out there.

--
The real reason for there being different OpenWrt images for BIOS and UEFI is kind of an historical accident, as in the contributors needing UEFI support - but not wanting to touch the existing BIOS images in fear of regressions (as mentioned, those would happen), as well as easing up the chances of -finally- getting UEFI support merged with the least amount of changes (and a combined legacy-BIOS & UEFI image would be anything but that).
There is a lot of potential optimization possible for x86, be it reducing the i386 flavours down to one, improving the disk image structure, multiboot support (as in a/b partitioning), more reliable support for growing the overlay and/or non-accidental partition retentions, etc. - so lots of potential to knock yourself out. However, be aware that getting these changes merged might not be trivial, big risk of regressions - probably few committers signing up for the task of reviewing/ merging and staying with you on top of it, for the subsequent fixes (x86 isn't really the main project focus, so it's hard to motivate the developers to dive in too deeply).

Is there any old version that has it built so I don't have to build from source?

image
Does Legacy refer to 32bit?

No.

i386:

  • generic
  • geode
  • legacy

x86_64 (amd64):

  • 64

A core2 (or newer) would be x86_64 (as in '64' subtarget).

Well my core2duo E7500 is 64 and doesn't have a UEFI. I can't remember the version, but I have installed OpwnWrt few years ago on the same machine.

To repeat it, this image is supposed to work:
https://downloads.openwrt.org/releases/23.05.3/targets/x86/64/openwrt-23.05.3-x86-64-generic-squashfs-combined.img.gz
of course it still might not, but that would be a bug (again, there are some really 'quirky' (and plain broken) BIOS variants around. Sometimes making it work is easy (as in setting the bootflag on the partition with fdisk), sometimes it's harder (and/or would break the other kind of quirky BIOS variants). If it doesn't boot, you'd need to do some hands-on debugging - if Debian boots (from disk, not the isohybrid images, which is yet another can of worms), it is possible to get OpenWrt booting as well (but it might be a tad complicated).

Sorry for my silly questions, I'll just try the legacy one and maybe an older legacy version after that. If they don't work I'll see if I can setup some Debian + Pihole's DHCP or something :laughing:

Thanks for your help, I really appreciate it.

OpenWrt can be made to boot on that hardware, that's not the problem (finding out what part needs kicking into gear may be).

Just for a comparison, slightly newer, but roughly the same ballpark (not UEFI capable, booting in legacy CSM mode) - at least it's the closest to your system I have at hand:

Host/Kernel/OS "OpenWrt" running Linux 6.6.30 x86_64 [ OpenWrt SNAPSHOT r26240-51c70e459d ]
System         Gigabyte Technology Co., Ltd. EP45-DS3
CPU Info       4x Intel Core2 Quad Q9550 @ 6144 KB cache flags( sse3 ht nx lm vmx ) clocked at [ 1999.675 MHz ]
Videocard      Advanced Micro Devices, [AMD/ATI] RV630 PRO [Radeon HD 2600 PRO]  tty resolution (  )
Network cards  Intel 82557/8/9/0/1 Ethernet Pro 100, at port: bf00 
Processes 122 | Uptime 6min | Memory 71.3/7961.4MB | HDD ST3360320AS,Maxtor 6B200M0 Size 566GB (0%used) | Infobash v3.60

(just booted a snapshot version of openwrt-23.05.3-x86-64-generic-squashfs-combined.img.gz from a USB stick)

Be aware that this generation of x86_64 hardware is not at all power efficient, I do expect roughly 90-130 watts idle, so running it 24/7 is not exactly wise, getting some newer x86_64 hardware (e.g. n100 based) might quickly pay for itself via the power bill.

I found the video on YT that showed me the version that worked in the past, and dded it on a usb but my core2duo didn't boot from it, but then (using the same version) but dding it from a live Finix image to the HDD just worked! :exploding_head:

dd or cat will do the same regardless of the running OS.

And now I got the latest version to work just fine just because I copied to HDD and not USB, am I stupid or what? what am I missing?

Systems of that era can be a little special when it comes to booting from USB, some might require setting (when using the boot override) to boot from USB-HDD, USB-FDD, USB-CDROM or plain HDD and then selecting the USB stick as medium. Anything beyond the norm can be all over the place before ~sandy-bridge. On top of that, they've reached an age where physical degradation (leaky/ dry caps and more) can make them even more quirky.

How do big OSs manage to just hide all of these quircks?

a) a lot more testing on strange hardware (millions of users)
b) full-sized images (enabling all possible features)
c) relying more on (bigger) upstream orchestration (grub-install/ update-grub)
d) a much bigger userbase on very diverse x86 hardware (yes, this is a) again, but it matters - many more bugreports and patches)

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.