Ubuntu 23.04 produces GRUB "error 452: out of range pointer" when booting in BIOS mode #2233
Comments
pbatard
changed the title
|
Fedora 38 also seems to be affected by the same issue, so we'll need to fix the |
* See pbatard/rufus#2233 * Also update signing script to ignore symlinks
|
Aaaaand, as expected, fixing GRUB for 23.04 BREAKs boot for older versions, such as 22.04. |
|
I got the same error. , |
With what ISO? Can you please provide the full name of the ISO you used? |
Using Rufus 4.0p (portable) has resolved the issue. |
|
A similar problem. Rufus + Ubuntu Server 22.04 (the latest from the official website) |
|
Yes, that's what I said earlier when I mentioned that fixing GRUB for 23.04 BREAKs boot for older versions, such as 22.04. Right now I don't have a good solution apart from advising people installing older versions of Ubuntu to use Rufus 3.22. The problem is that GRUB 2.06 with patches is now incompatible with GRUB 2.06 without patches, so using a version of GRUB that works for 23.04 breaks 22.04. And the other problem is that, whereas Rufus does have a mechanism in place to download special version of GRUB as needed, this only works if the distro maintainers do the right thing™ and change the GRUB version AS THEY SHOULD when they are no longer using the vanilla source. In other words, if Ubuntu had edited their GRUB version so that it says something like I also looked into trying to detect the version from the presence/absence of specific GRUB modules, but, sadly, there are no differences between 22.x and 23.x there. And I want a mechanism that works for more than Ubuntu, as Fedora suffers from a similar issue (Fedora 38 also requires a "patched" GRUB 2.06 to work, while also reporting that it uses plain 2.06), so I can't do something that's specific to detecting Ubuntu. Right now, the solution I am being cornered into, both because the GRUB project really screwed everyone with their lack of timely releases and because distro maintainers don't do the basic job of appending a custom suffix to the GRUB version the minute they stop using the original unpatched source, is use the ISO label as a GRUB 2.06 version suffix to try to differentiate between GRUB versions that need the recent out of range patch and those who don't, and then use the existing Rufus mechanism of downloading remote GRUB/Syslinux bootloaders. But even that is tricky because labels can contain tons of stuff (e.g. arch, X environment, "flavour") that we have to remove before we can get to something that doesn't require creating tons of symbolic link for each distro release, so I'm going to have to add some kind of ISO label sanitizer before I can get to a half-assed solution (since it will still require me to create symbolic links every time we discover a new release that requires a patched 2.06). And the worst thing of all is that both the Ubuntu maintainers and, especially, the GRUB maintainers, have no idea of the complete shit show they created by not following the FRIGGING ESTABLISHED BEST PRACTICES THAT EXIST FOR A VERY GOOD REASON of:
And, unfortunately as usual, it is the end-users that pay the price of developers thinking that they are above following best practices, or thinking that they somehow "know better" and that these best practices somehow shouldn't apply to their projects... |
|
Alternatively, we may have to rely on osinfo-db to tie a label regex to some kind of identifier we can use for GRUB. Unfortunately, while osinfo-db is officially a database, it's one that spread into tons of small files and it doesn't look like it's designed to perform operations like |
* As was *ENTIRELY PREDICTIBLE*, the lack of timely releases from the GRUB project has resulted in distro maintainers (Ubuntu, Fedora, etc.) taking matters in their own hand and applying patches on top of their 2.06 version. However, these patches result in 2.06 bootloaders that are incompatible with 2.06 modules that don't have the same patches applied. Especially this now results in the infamous "452: out of range pointer" error message when using patched modules with unpatched bootloader or unpatched modules with patched bootloaders. * Making this issue worse, we also have distro maintainers who won't add a suffix to their GRUB version, AS ONE SHOULD DO WHEN ONE APPLIES TONS OF PATCHES ON TOP OF A PROJECT'S SOURCE, and MISreport their non 2.06 GRUB as "2.06", and, because we can't detect what patches are needed from modules themselves (unlike what is the case for grub_debug_is_enabled), we have no way of telling incompatible GRUB 2.06 binaries from one another. * As a result, we have no choice but to append a sanitized version of the ISO label to the GRUB version, as a means to differentiate between incompatible versions, and tweak our existing bootloader download mechanism to *ATTEMPT* to download a compatible 'core.img' from our server... where we will have to waste a lot of time adding new binaries and symlinks to try to make all these GRUB "2.06" based images work, and will probably miss quite few with the end results that users who are just trying to install Linux will be left stranded. * Again, I have to point out how the end result of regular users wanting to try Linux and being unable to do so is the *DIRECT* result of the GRUB project maintainers having sat on a 2-year influx of CONTINUOUS patches, and thinking that "Release Early, Release Often" is only a gimmick, and not something that should apply to their project, even as they have been warned before, by yours truly, that *NOT* releasing on a timely basis is causing actual grievances... That's because, had the GRUB maintainers released on a timely basis (at least once a year) Fedora and Ubuntu would be using vanilla GRUB 2.07 with the memory patches, and we wouldn't be trying to mix that with old GRUB 2.06 binaries. * For more on this, see #2233, noting that we will need to apply a compatibility breaking change during the 4.1 release, to revert the patches we applied to the default 2.06 'core.img' in pbatard/rufus-web#320b800592abc2b63650061476b16ccff6a3e133.
* As was *ENTIRELY PREDICTIBLE*, the lack of timely releases from the GRUB project has resulted in distro maintainers (Ubuntu, Fedora, etc.) taking matters in their own hand and applying patches on top of their 2.06 version. However, these patches result in 2.06 bootloaders that are incompatible with 2.06 modules that don't have the same patches applied. Especially this now results in the infamous "452: out of range pointer" error message when using patched modules with unpatched bootloader or unpatched modules with patched bootloaders. * Making this issue worse, we also have distro maintainers who won't add a suffix to their GRUB version, AS ONE SHOULD DO WHEN ONE APPLIES TONS OF PATCHES ON TOP OF A PROJECT'S SOURCE, and MISreport their non 2.06 GRUB as "2.06", and, because we can't detect what patches are needed from modules themselves (unlike what is the case for grub_debug_is_enabled), we have no way of telling incompatible GRUB 2.06 binaries from one another. * As a result, we have no choice but to append a sanitized version of the ISO label to the GRUB version, as a means to differentiate between incompatible versions, and tweak our existing bootloader download mechanism to *ATTEMPT* to download a compatible 'core.img' from our server... where we will have to waste a lot of time adding new binaries and symlinks to try to make all these GRUB "2.06" based images work, and will probably miss quite few with the end results that users who are just trying to install Linux will be left stranded. * Again, I have to point out how the end result of regular users wanting to try Linux and being unable to do so is the *DIRECT* result of the GRUB project maintainers having sat on a 2-year influx of CONTINUOUS patches, and thinking that "Release Early, Release Often" is only a gimmick, and not something that should apply to their project, even as they have been warned before, by yours truly, that *NOT* releasing on a timely basis is causing actual grievances... That's because, had the GRUB maintainers released on a timely basis (at least once a year) Fedora and Ubuntu would be using vanilla GRUB 2.07 with the memory patches, and we wouldn't be trying to mix that with old GRUB 2.06 binaries. * For more on this, see #2233, noting that we will need to apply a compatibility breaking change during the 4.1 release, to revert the patches we applied to the default 2.06 'core.img' in pbatard/rufus-web@320b800.
|
Just a few notes for those who might still be experiencing this issue:
|
|
I were using rufus 4.0p and my computer was unable to boot up with error 452: out of range pointer |
Sorry for the dumb question - the "ALT-D" sequence, is this applicable for a USB device that has been formatted and a complete new download of RUFUS 4.1? Reason I ask is that I am still getting "452 out of range" errors for Fedora Rawhide (FC39), downloaded from https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Server/x86_64/iso/ Hardware is HPE DL380p Gen8 server, using Legacy BIOS - tried two different USB sticks, Sandisk 256GB, formatted as Large-FAT32 |
|
Alt-D removes all the files previously downloaded by Rufus on the host computer. It doesn't do anything to the target drive. You will see a line at the bottom of Rufus (status bar) that says Now, I have just tested Oh and since the Fedora folks stupidly decided that their RawHide ISO label should not have any hint of a version (the one from the problematic ISO is simply For now, and as Rufus explicitly advises you to do in a prominent prompt every time you create a Fedora media, you should try creating the media in DD mode, as you should find it should work around the issue. |
|
@pbatard, many thanks for your quick response. Indeed using DD worked, and the installation process began correctly. I am not sure if it is related to the GRUB mess that has been created, but when I went to re-install my server (due to a newly broken install - thanks to DNF 5 and PHP upgrades gone wrong, that is a long story) from a ReaR backup image, I found that the existing three backups all failed due to some weird issues as it was trying to run systemd-udevd.service. Now I am having to manually re-build the server from scratch, at least I can go to Rawhide..... |
|
Oh man, thanks to the lack of timely GRUB releases, Fedora currently have 332 patches (!) that they apply on top of GRUB 2.06. I think I'm gonna wait for the official 2.12 GRUB release, that may eventually happen sometime this year (but please don't ask me what happened to the 2.07 to 2.11 GRUB releases), and for Rawhide to switch to 2.12, because there's no way I'm gonna sieve through 332 patches to figure out which ones are needed to fix Fedora's out of range pointer error on BIOS... |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Well, it had to happen, with GRUB 2 NOT releasing in a timely manner, distro developers have taken upon themselves to cherry pick GRUB patches with the end result that some of these BREAK compatibility between their kernel and a vanilla GRUB 2.06 bootloader.
Case in point, Ubuntu 23.04 now produces a random
error 452: out of range pointermessage when trying to boot using our vanilla GRUB 2.06core.img.Well, I don't have the time to sieve through this crap, so we're going to have to upgrade our GRUB 2.06
core.imgto latest (since we confirmed it fixed the issue) and use that as our bootloader. This is most likely going to break boot for other ISOs, but hey, at least it'll keep the Ubuntu and GRUB folks COMPLETELY OBLIVIOUS to the bullshit they are generating for others...The text was updated successfully, but these errors were encountered: