Out of range pointer 0x400 on certain systems.

I'm trying to install Manjaro Cinnamon on one of the computers and I'm facing this strange problem. Booting the USB stick and GRUB complains about this (similar to this one):

out of range pointer 0x400
Aborted. Press any key to exit.

And I couldn't continue. I did check my hardware clock and confirmed it's correct and it doesn't matter whether I use UTC or local time in BIOS. I tried several different USB sticks and no avail.

The machine in question was meant for multi-booting several different operating systems that use either local time or UTC (though I may try configuring them to all use UTC).

And another thing, this seems to happen only on later images that uses GRUB (tried several versions, including earlier 17.1.x ones). The problem did not occur on old Manjaro images that used syslinux (I think) and I was able to boot such, just that I'll need to do an update later on. Not sure if there are still any early syslinux-based images around. Haven't tried the 17.0 build yet (which is currently the earliest build that still resides on the SourceForge archive).

I don't know exactly what caused it, as googling "out of range pointer 0x400" only returned very few results and it's mainly here (incluing the post I referenced) and some old IRC messages (plus a thread in an Arch-related forum that was solved with newer images, which is not helpful at all).

1 Like

Do you have the md5sum, sha256sum ... checked
Create the USB stick with the Etcher program.

At first I thought sha256 sum might be different so I checked and confirmed what I downloaded were correct (identical sum).

It also occurs on Architect as it also uses GRUB. For some reason that particular system doesn't cope well with it. It seems using Etcher to make the image doesn't make a different, nor would changing USB slots... strange.

EDIT: I think this might be interesting to investigate. Apparently the computer which I'm having the problem had the mainboard replaced. The original board (Intel G41, LGA775) and the replacement board (AMD 760G, AM3/AM3+) have almost nothing in common, except one thing: they both use AMI Core8 BIOS with a ROM build version of 4.21. This "out of range pointer 0x400" problem happens on both the original and the replacement boards. I suspect the image's GRUB or some other part of the boot logic is somehow having issues with this particular AMI BIOS revision.

Unfortunately, both the original and replacement boards were on the latest BIOS ever available for them, so there's no way I can update BIOS even further. Maybe some other users with motherboards using that particular AMI BIOS revision can test if it's reproducible.

so you have dual-boot on this hdd or want it ? if so back up everything now

with out formatting it with some tool, or windows install tool, your hdd will be totally unusable in linux

in my case, this odd behavior continued, affecting the usb stick installer/live desktop, as i could not copy the time settings file from the home directory.

I don't know the exact reason why it was broken. If HDD partitioning issues can affect USB live media GRUB startup then something definitely isn't configured properly. Normally a USB live media should be able to boot regardless of HDD partitioning, as it shouldn't have known anything about HDDs at that time.

I'm fine about starting things over, as currently the target system hasn't any important data yet.

Actually, the target system's partitions were created and validated using DFSee, as I also intend to run ArcaOS (OS/2 based) on this system. Before replacing the board the old system also has a functional installation of it, and I encountered the same issue during preparation phase (when installing Manjaro). I tried several USB sticks and Manjaro images and managed to find one that booted (that was probably sheer luck at that time) and proceeded to install. The installed system (even with GRUB) can boot normally afterwards. My operating systems (including Linux) were managed using AIR-BOOT (which ArcaOS currently uses, with OS/2 LVM support and could boot other OSes such as Linux and Windows).

For the time being ArcaOS (OS/2 LVM, not be confused with the Linux one) has a stricter partitioning requirement that's not compatible with any partitioning tools outside DFSee, so that all actions (including formatting) done outside DFSee has to be re-validated using it. For my use case, I need to set a CHS geometry with higher sectors-per-cylinder (such as ?/255/248) as that's only way to make ArcaOS properly recognize disks above 512GB. I'm starting to suspect this (instead of BIOS) might have been the real cause of the breakage, as I noticed some OSes would misbehave under this setting (for now it's just some DOS variants, but FreeDOS worked fine anyway. Other OSes including Linux don't appear to have any issues with this), and that I never encountered this issue elsewhere (I don't run ArcaOS on these systems, so no need to perform those complicated partitioning actions involving OS/2 LVM there).

Unfortunately from my experience that setting is very fragile. I currently only know how to format FAT32 partitions with DFSee and other partitions (mainly ones that I don't intend to expose to ArcaOS) has to be formatted elsewhere. However, most other tools that involves formatting the partition, or altering the partition's boot records, are not aware of this quirk and would just slap the default, smaller geometry to it (usually ?/255/63), causing DFSee to report a non-trivial warning (geometry mismatch between disk and partition).

This warning has no effect on most other OSes as they don't use OS/2 LVM and they mainly use LBA (hence non-trivial), but could cause the ArcaOS installation to break if left unresolved (can usually be fixed via FIXPBR) as this could confuse the OS/2 LVM. So whenever I conducted such actions I'd always go back and re-check the disk until no such non-trivial warnings left.

Also, it seems even DFSee may not be able to properly handle a partition resize under such circumstance, as one time I attempted a resize of a FAT32 partition (created and formatted using DFSee) and it ended up irreversibly corrupted (inaccessible, fsck reports errors such as "block is outside filesystem" and Windows chkdsk crashes with some unknown error codes). So most of the cases I'd avoid touching anything regarding partitions once every OS has been properly installed and configured.

EDIT: I'm able to boot and install using an old Manjaro XFCE 16.10.3 image (which uses ISOLINUX). The installation procedure completed without any issues. It seems for some reasons, the GRUB boot loader incorporated in recent USB sticks is not compatible with certain configurations.

Now the question would be, is it still possible to make an ISOLINUX-based Manjaro installation in case GRUB doesn't work as intended?

bro, i dont really know alot about all that mess you got there, but if google and arch forums didnt help ya, then nobody will.!!!

but i seen that kde partition manager has some option for those cylinder/sector thing, or was it gparted?

if your HDD still shows that "out of range pointer message" (when booting from usb) just grab a windows installer, beta/dev/whatever ... and just boot it up, delete the partitions on your hdd, format the drive, and then just... shutdown the pc no need to install, and try again your usb stick

my issue in the link you posted was more complicated, as i used a btrfs, and a bsd-type os, cloning it from usb to hdd, and from hdd to another usb again. and i tampered with the time settings, am/pm, sync at boot, and all that.

The "out of range pointer 0x400" issue only happened on me while installing from USB media. And if I'm really lucky I would have successfully booted the image.

Earlier images (that uses ISOLINUX/SYSLINUX) do not have this issue. It's only the recent images that use GRUB do, and this is about the installation media.

I'm using AIR-BOOT as the main boot manager, so I install GRUB on the boot partition directly. AIR-BOOT can chainload GRUB and it would boot properly. I never encountered this "out of range pointer" issue when chainloading GRUB from AIR-BOOT so it has nothing to do with my SSD.

1 Like

A late bump.

I replaced my video card with a new one, cleared the partition table and redid the partitions using DFSee again. This time the USB media was able to boot properly. It's possible that in some cases GRUB's graphical mode would not work properly (It seems the reason I never had issues elsewhere might be that the GRUBs there were either set to text mode or, in case of my newest rigs, I'm using UEFI boot which uses a different GRUB variant but also in text mode).

I'm able to install all the operating system needed, including ArcaOS, which is installed last along with AIR-BOOT, as for some reasons I cannot install the bootloader from Windows (thanks to M$'s inflexible design I have to install it on the first partition which would be booted by default when without a bootloader).

For now it seems only NTFS formatting (via gparted) is affected by the geometry-related issue (that needs to be fixed via DFSee). Other filesystems looked just fine on DFSee post-format (without that aforementioned non-trivial warning). However, given GParted is merely a frontend of many filesystem utilities, not sure where I should report that particular bug upstream (given that ntfs-3g/ntfsprogs is directly responsible for dealing with NTFS partitions I should report the bug there, but not sure how)...

1 Like