Rufus does not detect and thus will not write grub bios boot loaders

[Thinstation]

Rufus does not detect and thus will not write grub bios boot loaders

[pbatard]

Could not detect Grub version is your issue.

It seems you built a custom GRUB that doesn't use a standard version, and as a result, since Rufus has to know what version it should use so it can install the proper USB/HDD GRUB bootloaders (since the ISO are incompatible) with USB/HDD boot and we can't just pick whatever core.img exists on the ISO and hope for the best (since a lot of ISO-provided core.img will be missing support for the file systems we need or the partition system, which we cannot load from separate submodules, and with compression, it's not like we can easily peek into the module to find out if it provides what we need or not).

Build a standard GRUB, that supplies a standard version (you can append a custom string, but if you do, make sure it is appended and that there is still the x.y version from the actual GRUB you used as your source), and you should find that your ISO works a lot better with Rufus (because, since hundreds of other GRUB-based Linux ISOs have no issue, why should yours, if you follow the same approach as these other folks do?).

[Thinstation]

I'm sort of using a common grub. I was building 2.06(updating to 2.12), and applying the fedora/redhat patches. For some reason these strip the grub version. Beyond that, I'm not making any changes to grub. As you noted, the core.img can contain quite a lot or not enough, but perhaps we can assume that if they are provided by a vendor, they contain enough to get a disk up and running. This would negate the need to maintain a database of grub versions and builds on you end. I'm not opposed to using a naming convention that would let Rufus know that these are the files to be used. i.e. rufus-core.img etc..

[Thinstation]

I should maybe also note that while I'm not using any crazy compilation of the binaries, I do embed a grub.cfg into core.img and I imagine that quite a few others do as well. I doubt there is any easy way(other than taking vendor provided core.img) for Rufus to account for that.

[pbatard]

and applying the fedora/redhat patches

I don't think you're applying all the Fedora/RH patches, because Rufus has no trouble detecting the GRUB version with Fedora images.

But perhaps we can assume that if they are provided by a vendor, they contain enough to get a disk up and running.

No. As a matter of fact, Fedora need a "special" version of GRUB (see the grub-2.06-nonstandard-gdie-fedora-## at https://github.com/pbatard/rufus-web/tree/gh-pages/files) because they also apply custom patches, and we can't just pick a version that was designed purely for ISOHybrid boot and "hope" that somehow, the maintainers will have added modules that they don't need for ISOHybrid at all, just for the sake on utilities that don't use dd to write the image... which they rarely do.

I'm not opposed to using a naming convention

You don't have to use a naming convention. You just have to fix the way you build and set up GRUB so that it does embed a version that can be parsed, like the GRUB binaries produced by Fedora do.

[Thinstation]

This a snapshot of what I was doing, and at the time these patches removed the grub version. https://github.com/Thinstation/thinstation/blob/6.2-Stable/ts/ports/opt/grub2/Pkgfile
Maybe things have changed, we will see when I get 2.12 going

[pbatard]

I do embed a grub.cfg into core.img and I imagine that quite a few others do as well.

None of the mainstream Linux distros do that, and you are the first person I hear from that does it. If you don't care about ensuring that users of your ISO can use the utility they want to write it, and force them to use dd or something, that's fine, but if you want to ensure compatibility with the widest of media creation tools, you should look into not doing that.

[pbatard]

This a snapshot of what I was doing, and at the time these patches removed the grub version.

Again, I can only state that Rufus is able to extract the GRUB version on standard Fedora ISOs, so you'll need to figure out how you deviate from the release builds, and sort that out. As you can understand, I can only ever invest time to support mainstream public ISOs and people who follow their design. If you customize your ISO in a super specific manner, things will break, and I am not going to try to patch Rufus so that it works just for your custom private design.

[Thinstation]

I was actually hoping that as these files(core.img, maybe boot.img) can be highly customized, perhaps there is a way that Rufus can take them, if they are provided by a vendor, and run with them. While this would solve my issue, I think it might be of wider appeal to quite a few distro's, and actually reduce your burden(tracking down builds).

[pbatard]

And then run into the current issue of distro maintainers deciding not to support NTFS at all (because they don't see the point), whereas it can actually be necessary if the distro uses symlinks, or deciding not to support GPT at all (because they don't see the point), whereas it can be desirable for the user to ensure that their media can only boot in pure UEFI mode. I have also some views into adding other GRUB modules that maintainers are unlikely to add in the future.

Unless I can sit behind each maintainer when they build their GRUB, and can force them to include specific modules, what you suggest is not a viable option, because people providing their own core.img will not be providing a core.img that is designed to work with Rufus, but a core.img that is designed to work with their limited set of conditions... which is the precise issue you are running into because, for some reason, your core.img fails to provide a version that can be parsed by Rufus.

So, again, not gonna happen. I will never, ever, rely on distro maintainers magically providing the modules and settings that are required for something they don't actually think they need. Plus, it's only for BIOS boot, which means a minority of end users (meaning, maintainers are even more likely to invest as little time as they can on that).

[Thinstation]

Yeah, I know bios boot is long long overdue for retirement, but I still get pings on it. sigh* So we are at this weird crossroads, where you want to control the core.img build, but I(and other vendors) also need control of the core.img build, because a lot of things can be done there. Is there some way, other than hacking Rufus(by me), that a path can be made to work with Rufus to get all things done?

[pbatard]

Is there some way

Get enough end users to use your public ISO, and I may look into adding support for it. Outside of that, you'll have to invest your own time, and not expect much help from me or anybody else I'm afraid.

[Thinstation]

I have over a million installations, but my primary users are admins, not end users. They take builds from my system and create deployments. It's used by the U.S. and U.K. and Israel Governments and was the basis for TENS and SecureView.

[pbatard]

I'm going to close this issue for the reasons explained above and since we are not dealing with public ISOs.