• Grub> Error 13: Invalid or unsupported executable format


    Problem booting new Antergos installation. Getting the following error on the kernel line:
    Error 13: Invalid or unsupported executable format

    Always have booted various linux distros from a common bootloader on main partition with a Grub4DOS config. On this particular machine, Antergos (installed without bootloader) was taking the place of a running ArchBang install using the same booting method. I also use this method on other machines with plain vanilla Arch with no problems, either direct boot or chainload into syslinux/grub on the PBS.

    I also duplicated the problem in a VirtualBox VM. But here I let the Antergos install its own grub to MBR, which did boot properly. But still could not direct boot it from the Grub4DOS partition.

    Is there something different about the Antergos kernel/compression or something special about the grub2 version compared to Arch? Will the current installation method produce something not compatible with Grub4DOS booting?

  • Similar situation here.

    Starting from autumn 2016, Arch-based systems, installed by various installers - first by Calamares, later by Cnchi - without Grub 2 don’t boot by other boot loader(s).

    As you do, I never install Grub 2 bloatware. Differently from you, I use the regular Grub to boot all systems, not Grub4DOS, with which I’m not familiar.

    The error Grub returns here is slightly different from yours, though similar - Error 14: Filesystem compatibility error, cannot read whole file.

    As it happens for you, when I install the native Arch using the same strategy - into a separate 20G partition and without any boot loader - it is booted by the regular Grub without a problem.

    I didn’t try to install with Grub 2 bloatawre - it takes from 4 hours, in best cases, up to 8 hours, in worst cases, depending on the number of other Linuxes present on the computers, to generate grub.cfg whenever the os-prober crapware enters in action.

    I still didn’t find neither an explanation, nor a simple solution for this anomaly. Though I found a workaround for it, which works perfectly here.

    If an Arch-based distro uses an installer, the workaround is:

    • install the distro normally, into a separate 20G partition and without Grub 2
    • without even booting it for the 1st time, immediately backup | archive the whole partition with fsarchiver; it takes about 15 min
    • and immediately restore with fsarchiver the backed up system into the same partition - it takes about 4 min
    • done

    Briefly: Install --> Backup - -> Restore

    The newly installed system will be normally booted now by the regular Grub.

    An important note. Backup-restore must be done with fsarchiver. It re-creates the filesystem from scratch during restore. Clonezilla doesn’t work here.

    It might work for you too.

  • Thanks for the reply.

    Yep, that’s the issue. Same problem booting with Grub4DOS as it is similar to Grub1/Legacy I guess.

    I tried your trick on the VBox install of Antergos, and it worked! Very strange, I wonder what the Antergos GUI install is doing to the Ext4 filesystem to make it incompatible with Grub4DOS/Grub1?

    I’ll try on the other machine on a real partition tomorrow. I had already uninstalled Antergos and restored the partition with partclone. And you’re right, only fsarchiver worked for this fix. I tried with partclone first and it did not work.

    I don’t ever notice this problem before with the typical Ubuntu, Fedora or other distros. Or, as you detailed in your post, plain vanilla Arch.

    I was just looking at Antergos as another way to get Arch installed. I’m so over the lame “Arch way” of plain vanilla. Right now if I install Arch, I use either of the text based installers, with ArchBoot ISO, or ArchBang is even easier and uses similar text installer.

  • @jondo220 said in Error 13: Invalid or unsupported executable format:

    Thanks for the reply.

    Yep, that’s the issue. Same problem booting with Grub4DOS as it is similar to Grub1/Legacy I guess.

    I tried your trick on the VBox install of Antergos, and it worked! Very strange,…

    Good! And I’m not alone with this issue.

    …I wonder what the Antergos GUI install is doing to the Ext4 filesystem to make it incompatible with Grub4DOS/Grub1?

    It doesn’t an Antergos-specific problem. It happens in other Arch clones too - in Bluestar, Apricity, Nurunner, Netrunner, Manjaro.

    I’ll try on the other machine on a real partition tomorrow. I had already uninstalled Antergos and restored the partition with partclone. And you’re right, only fsarchiver worked for this fix. I tried with partclone first and it did not work.

    That’s because Clonezilla - which uses partclone as a backend - does a very low level, bit-by-bit backup. They read bit chunks first, then compress and backup them. They create an exact copy of a disk | partition, at a physical level. It’s an exact partition copy at a bit level.

    During restore, Clonezilla places every single bit in exactly the same place where it was in original partition at backup time.

    Differently from partclone, fsarchiver works at the higher file level. All files are included in a backup, but a single bit displacement is not respected by fsarchiver.

    During restore, Fsarchiver simply formats the target partition from scratch, and restores all files from a backup. It doesn’t care to respect every single bit position on the target - as Clonezilla does. Fs archiver works much like a regular file archiver.

    I don’t ever notice this problem before with the typical Ubuntu, Fedora or other distros. Or, as you detailed in your post, plain vanilla Arch.

    You’re right. The problem is not (currently) present in Fedora, Tumbleweed, Debian.

    I was just looking at Antergos as another way to get Arch installed. I’m so over the lame “Arch way” of plain vanilla. Right now if I install Arch, I use either of the text based installers, with ArchBoot ISO, or ArchBang is even easier and uses similar text installer.

    I did it in another way. Time ago I created a core, bare-bones Arch images. They include an absolutely minimal set of components, like kernel, bash, vga and intel video drivers, network manager, basic IO drivers, and nothing else. They don’t include any boot loader, DE or GUI. They may be restored to disk at any time. Starting from bash, I add to them any additional sw, arriving to a fully fledged graphical DEs.

    Regards

  • @just is there any fsarchiver bootable .ISO or do you use systemrescuecd or some live system?
    I need some alternative for clonezilla…

    Antergos (default OS) - WIN10 (abandoned)
    I3wm - Mate desktop
    AMD - A4 7300 Radeon graphics
    16 GB ram
    HD 1 TB
    Linux newbie since 06/2016

  • @fernandomaroto said in Error 13: Invalid or unsupported executable format:

    @just is there any fsarchiver bootable .ISO or do you use systemrescuecd or some live system?

    No, there’s not a separate boot media for|with fsarchiver. It’s a very small - and enormously useful - utility, included in most common rescue|repair tools. So yes, it is present in SystemRescueCd, Parted Magic, maybe in others.

    I use it from SystemRescueCd, but mainly directly from other Linuxes, installed on my computers. It is present in regular repos of all distros, without any exclusion.

    When I need to backup a Distro A, I boot into a Distro B, and backup the Distro A from it.

    I need some alternative for clonezilla…

    Clonezilla is very rigid, but there’s nothing better than Clonezilla for mission-critical backups. Say, when you need to wipe totally out a Windowz from a new computer, it’s wise to back it up with Clonezilla. Clonezilla will allow to restore the computer to a factory default Windowz state.

    Fsarchiver is way more flexible than Clonezilla. If you have a computer with a dozen of installed distros, then copying, moving, shrinking, enlarging, reordering, cloning them from one computer to another, to smaller or large partitions. to partitions with different numbering, on other disks with fsarchiver is a breeze.

  • OK, I figured out what the problem was. Verified Antergos installed and booting fine now with Grub4DOS on real hardware.

    The Antergos installer is creating an Ext4 filesystem with the 64bit feature turned on. This makes it incompatible with booting from Grub1/Legacy, Grub4DOS and even Syslinux.

    To fix this, you can remove the 64bit feature from Ext4 after the fact, with the new resize2fs “-s” option, e.g.:

    resize2fs -s /dev/sda7
    

    Needs to be a newer resize2fs version as many of the ones I had on other distros and rescue disks could not do it, so I used the one from Antergos Live.

    Or they could change the installer to do mke2fs -O ^64bit without the (unneeded?) 64bit option.

    I didn’t even know about this option, just found out about it after troubleshooting the fix above. I also installed Syslinux on the PBR and can either direct boot from Grub4DOS or chainload into Syslinux to boot the Antergos partition.

  • @jondo220 Very, very interesting! Thanks for sharing this info.

    At this point I ask myself: “What will happen, if I’ll install Antergos into a preformatted ext4 partition with 64bit feature turned off, without formatting it from within the installer?”

    Some installers insist on formatting the / partition, and refuse to proceed without doing it. Hopefully, Cnchi is not among them.

    I’ll do these tests on real hardware asap, and will post back here the results.

    Thanks again. Much appreciated.

  • Glad I could help track it down!

    I was just looking at the before/after of the fsarchiver workaround you revealed, reverted back again in VBox, and noticed the tune2fs output showed the 64bit feature difference.

    So after some looking around, tried the change and it worked. Then I later found the Syslinux document which confirmed the 64bit feature as the culprit.

    And yeah, unfortunately the cnchi required the format before proceeding, that’s how this whole problem was revealed. I normally prepare all the partitions myself before any Linux installer mucks around with my drives.

    The resize2fs -s change is pretty quick and painless, couple seconds. I guess I need to update all my rescue disks with latest 1.43 version e2fsprogs. Had Ubuntu 16.04 LTS and various Puppy Linux also installed on the box, and none of them had the updated resize2fs with the 64bit feature.

  • Can only confirm the solution found by @jondo220.

    Scenery: Installing Antergos 17.2 Mate without bootloader into the single /dev/sda12 logical partition on the MBR system. The system is booted by Grub 1|Legacy.

    Cnchi wants to format the / partition, and refuses to proceed without it. Installation into a preformatted partition is not possible.

    Right after the installation Antergos in /dev/sda12 cannot be booted by Grub Legacy. The usual Error 14: Filesystem compatibility error, cannot read whole file is returned.

    On first run resize2fs suggests to force the file system check on /dev/sda12 first:

    ┌──[just]@[alexasm]:~$
    └─> sudo resize2fs -s /dev/sda12
    resize2fs 1.43.4 (31-Jan-2017)
    Please run 'e2fsck -f /dev/sda12' first.
    

    Checking the file system on /dev/sda12:

    ┌──[just]@[alexasm]:~$
    └─> sudo e2fsck -f /dev/sda12
    e2fsck 1.43.4 (31-Jan-2017)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    /dev/sda12: 203855/1281120 files (0.1% non-contiguous), 1656490/5120000 blocks
    

    It is now possible to turn off the 64bit feature in /dev/sda12:

    ┌──[just]@[alexasm]:~$
    └─> sudo resize2fs -s /dev/sda12
    resize2fs 1.43.4 (31-Jan-2017)
    Converting the filesystem to 32-bit.
    The filesystem on /dev/sda12 is now 5120000 (4k) blocks long.
    

    Done. Antergos 17.2 in /dev/sda12 immediately becomes bootable by Grub 1|Legacy.

  • Hi,

    I do not know what to do with this info… should I add a “ext4 32bit” option to the installer?

  • I do not have a clear idea about it too.

    1. I do not know the difference between 32- and 64bit filesystem feature. Is it that important? Probably yes, if it is set by default.

    2. Only 2-4 among millions Antergos users have Grub4DOS, Grub Legacy, Syslinux as their bootloader. Does it worth to change smth in existing installer for them? Probably not. If a person is capable to manipulate boot loaders by hand, for him|her it’s enough to know about resize -s trick. Maybe write an article in Antergos Wiki about it.

    3. Why on other platforms - Debian, Fedora, Suse - the problem doesn’t arise, even when the target partition is formatted to ext4?

    4. Probably, it is possible simply to not force the / formatting in Cnchi. The user may prepare a partition the way he|she prefers, with 64bit feature either on or off, and then install without modifying the filesystem.

    5. If there’s no a huge difference with 64bit filesystem feature switched on|off, and if Cnchi pepares the target / partition with mke2fs, it may be enough to add -O ^64bit feature to the command, as @jondo220 suggests: mke2fs -O ^64bit.

    Only questions without answers. But it would be great to have an installer which produces a working system even with alternative boot loaders when its own Grub 2 is not installed.

  • Thanks @just

    I’ll do some research about ^64bit implications and decide later.

    Thanks!

    EDIT: It seems that this option limits ext4 to 16 TiB

  • @karasu said in Grub> Error 13: Invalid or unsupported executable format:


    I’ll do some research about ^64bit implications and decide later.

    Wise decision. There’s no hurry.

    EDIT: It seems that this option limits ext4 to 16 TiB

    If I interpret correctly the Ext4 artcile in Kernel.org Wiki, and more specifically, file system maximums described in its Blocks section, the sutuation is as follows, for 4 KiB block size.

    1. Ext4 in 32bit mode

      • max file system size: 2^32 * 4 KiB = 16 TiB

      • max single file size: 2^32 * 4 KiB = 16 TiB

      • in other words, the whole file system may be occupied by only one file.

    2. Ext4 in 64bit mode

      • max file system size: 2^64 * 4 KiB = 64 ZiB

      • max single file size: 2^32 * 4 KiB = 16 TiB

      • in other words, file system size grows up enormously, but the max file size doesn’t change.

    A note. I use ext4 since 1998, and never seen a block size different from 4 KiB.

    Summarizing. How I see the difference between 32- and 64 bit modes for now.

    • The main difference between 32- and 64bit modes in ext4 consists in the maximum file system size. It’s of only 16 TiB in 32bit mode, and of 64 ZiB in 64bit mode.

    • The maximum single file size doesn’t depend on the mode. It is of only 16 TiB for both 32- and 64bit modes.

    All the best

  • @just said in Grub> Error 13: Invalid or unsupported executable format:

    1. Only 2-4 among millions Antergos users have Grub4DOS, Grub Legacy, Syslinux as their bootloader. Does it worth to change smth in existing installer for them? Probably not. If a person is capable to manipulate boot loaders by hand, for him|her it’s enough to know about resize -s trick. Maybe write an article in Antergos Wiki about it.

    +1 for that.

    Progress marches on… Seems like the end of the 32-bit era is here. With Arch going EOL on i686, and after May 2016 mke2fs defaulting to 64bit, I would expect most all newer Linux distros 2017 and beyond will be doing the 64bit Ext4.

    I’m an old dog using old tricks. When my old Core2 era and early Corei7 BIOS systems start to die out, then I’ll be forced to use Grub2 on new UEFI PCs. Until then, at least I’ll know the old trick to still use Grub4DOS/Syslinux with 32bit Ext4! :thumbsup:

executable2 error170 invalid7 unsupported2 Posts 15Views 1307
Log in to reply