# Grub Error 13

## zipdrive

Hallo,

ich versuche mein Windows zu booten und bekomme Invalid or unsupported executable format als Fehler.

Der Fehler ist hier gelistet https://www.gnu.org/software/grub/manual/legacy/grub.html#Stage2-errors. Es hat offensichlich etwas mit dem Kernel zu tun, aber ich weiß nicht woran es liegen könnte.

Meine aktuelle Kernel config ist diese hier https://pastebin.com/S5SV9diq.

Ich bin der Meinung, dass es mal mit dem Kernel funktioniert hat. Seit der Umstellung auf Systemd funktioniert es wohl nicht. Ich bin mir aber nicht sicher, da ich das Windows schon länger nicht mehr gestartet hab.

Woran kann es liegen?

Grüße

----------

## ChrisJumper

Hi zipdrive.

Verwendest du Grub 0.97 oder schon Grub 2?

Schau dir auf jeden Fall noch mal an wie du einen Windows Kernel booten kannst. Die Fehlermeldung

```
13 : Invalid or unsupported executable format

    This error is returned if the kernel image being loaded is not recognized as Multiboot or one of the supported native formats (Linux zImage or bzImage, FreeBSD, or NetBSD). 
```

Scheint plausible, weil du einen Windows Kernel booten willst und Grub den halt für einen Linux oder Net-BSD Kernel hält. Da stimmt etwas mit deinem Grub-Eintrag für ein Windows nicht.

Das Archlinux Wiki ist eigentlich immer ziemlich Umfangreich daher verlinke ich immer gerne darauf. Wenn du noch Grub Legacy (0.97) hast: Schau hier für den Eintrag. Das schaut dann beispielsweise so ähnlich aus:

```
title Windows

 map (hd0) (hd1)

 map (hd1) (hd0)

 rootnoverify (hd1,0)

 makeactive

 chainloader +1
```

Wenn du schon Grub2 verwendest: musst du genau hinschauen, weil das Howto für Windwos wohl unterscheidet ob du ein Mainboard mit UEFI/GPT nutzt oder noch das alte BIOS/MBR System.

Ob es unter Grub 0.97 auch einen Unterschied machen würde ob du UEFI oder Bios nutzt. Das weiß ich leider nicht. Auch nicht ob sich da alle Windows-Varianten gleich verhalten oder ob es da Unterschiede seit Windows 10 gibt. Musst du eventuell mal im Internet nach schlagen.

Edit: Ah es ist wohl besser wenn du Grub2 hast, schaut der Bereich im Gentoo-Wiki Grub2 einfacher aus als bei Arch-Linux. Weil da gibt es dann ein Paket das schaut welche anderen Betriebssysteme installiert sind und dafür einen Grub2 Eintrag erstellt.

 *wiki.gentoo.org wrote:*   

> Optionally, install the os-prober utility (provided through the sys-boot/os-prober package) to have GRUB2 probe for other operating systems when running the grub-mkconfig command. In most instances, this will enable GRUB2 to automatically detect other operating systems including Windows 7, 8.1, 10, other distributions of Linux, etc.

 

----------

## zipdrive

Ich habs herausgefunden. Es lag an der Reihenfolge der Festplatten im Bios. Diese hatte ich aus mir unersichtlichen Gründen mal abgeändert. Die Frage ist mir jetzt ein wenig peinlich ...

----------

## Tyrus

Ist doch ok, deine Frage.

Zu dem Reihenfolgeproblem hab ich aber mal ne Frage an dich. Benutzt du sowas wie "/dev/sda1", "/dev/sdb3" und dergleichen in deiner grub.cfg Konfiguration?

Wenn ja, würde ich dir zur Verwendung von UUIDs raten. Damit würde es egal sein, welche Reihenfolge deine Festplatten im Bios haben. Natürlich solltest du die UUIDs auch in der fstab nutzen.

Du kannst dir die UUIDs mit dem Kommando "blkid" holen. Und dann einfach statt "/dev/sdx" schreibst du "UUID=<die UUID aus dem blkid>".

----------

## zipdrive

Ich verwende das Legacy Grub und habe noch ein altes Bios ohne UEFI. Das nur am Rande. Eine UUID hab ich im kernel-Eintrag für meine Gentoo-Installation. Der Fehler betraf allerdings die Angabe hinter rootnoverify.

----------

## ChrisJumper

Ah, an die Bootreihenfolge hab ich auch nicht mehr gedacht. Das ist in der Tat so ein Punkt, der mir auch heute immer wieder mal passiert wenn ich an den sata-Kabeln spiele oder weitere Platten einbaue.

Aber wie schon erwähnt, kann man dagegen mit UUID vorgehen. Ich finde es oft allerdings von Nachteil wenn man dann nur die UUID Infos hat, darum schreibe ich mir meistens im Log oder den Konfigdateien als Kommentar noch dazu welche Platte das ist.

Man kann auch teilweise ein LABEL vergeben wie einen Namen aber das ist auch nicht praktisch, weil ich dann meiste zu SDA1 oder SDB2 neige oder wenn es hoch kommt Windows 20 GB, oder Linux 1 - 20 TB.

Peinliche Fragen gibt es nicht, sicher manch mal ist das blöd weil man vor lauter Bäumen nicht den Wald sieht, oder dachte den Punkt hat man schon abgehakt. Doch so Nachfragen, Reflektieren hilft meistens schon bei der Fehlersuche.

Selbst wenn hier einige Threads sind wo niemand drauf geantwortet hat und der Ersteller die Lösung alleine gefunden hatte.. das hilft einem auch schon mal weiter. Wenn man per Google in die selbe Situation kommt, zumindest geht es mir oft so.

Na dann, weiterhin viel Spaß mit dem System :)

----------

## firefly

Hinweis bezüglich UUID und LABEL als angabe des rootfs/partition in den kernel parametern.

Mit UUIDs und LABELs (welche auf Dateisystemebene existieren) kann der kernel selbst nichts anfangen. Hier wird immer eine initrd/initramfs benötigt, welche sich um das mounten der root-partition kümmert.

Der kernel selbst kennt nur PARTUUID und diese UUID ist bestandteil der Partitionstabelle wobei UUIDs auf partitionsebene nur von GPT unterstützt werden.

----------

## schmidicom

 *firefly wrote:*   

> Der kernel selbst kennt nur PARTUUID und diese UUID ist bestandteil der Partitionstabelle wobei UUIDs auf partitionsebene nur von GPT unterstützt werden.

 

GPT kann allerdings auch ganz ohne EFI/UEFI benutzt werden (z. B. so: https://wiki.gentoo.org/wiki/Syslinux#GPT), von daher gibt es eigentlich kaum noch einen wirklich guten Grund für eine MBR.

EDIT "27.07.2018 11:29":

Das war kein Vorwurf oder Korrektur sondern nur eine zusätzliche Rand-Bemerkung zur GPT.Last edited by schmidicom on Wed Jun 27, 2018 9:28 am; edited 3 times in total

----------

## firefly

 *schmidicom wrote:*   

>  *firefly wrote:*   Der kernel selbst kennt nur PARTUUID und diese UUID ist bestandteil der Partitionstabelle wobei UUIDs auf partitionsebene nur von GPT unterstützt werden. 
> 
> GPT kann allerdings auch ganz ohne EFI/UEFI benutzt werden (z. B. so: https://wiki.gentoo.org/wiki/Syslinux#GPT), von daher gibt es eigentlich kaum noch einen wirklich guten Grund stattdessen eine MBR einzusetzen.

 

Habe ich nie behauptet das GPT nur mit EFI/UEFI geht. Aber der Hinweis ist richtig. Ich selbst habe bei einem neuen Rechner statt MBR GPT verwendet obwohl der Rechner nur ein BIOS hatte und grub (sogar mit grub-legacy und nicht grub2) als bootloader verwende

----------

## Yamakuzure

zipdrive möchte Windows booten. Da setzt GPT zwingend UEFI voraus, sonst lässt sich Windows nichteinmal installieren. (Außer mit Hilfe einer UEFI-Emulation mittels DUET, aber das ist alles andere als einfach.)

----------

