• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Grub-Error 18 treibt mich noch in den Wahnsinn!!!

Auf einem Rechner habe ich das "Mutterbrett" austauschen müssen. Anschließend Opensuse 11.3 installiert (vorher war WinXP + OS 11.2 drauf), klappte soweit alles ganz gut, nur, daß sich Grub 0.97 mit dem berüchtigten Error 18 verabschiedete. :(

Hier: http://www.gentoo.org/doc/de/grub-error-guide.xml kann man aber nachlesen, daß das eigentlich lösbar sein müßte.

Also tagelang Partitionen verschoben und am Anfang der Platte etwas Platz frei gemacht für den Bootloader. /boot dorthin kopiert und zur Sicherheit noch mal das hier http://www.libe.net/themen/setup_mbr_boot_grub_Ubuntu_Linux_.php durchgeführt, was lt. Konsolenmeldung auch erfolgreich war.

Nur, daß der Fehler weiterhin auftritt. Ich habe es auch mit der Grub-Installation verschiedener Puppy-Distries, der Reperaturroutine der 11.3-CD und mit ConnochaetOS Beta-1 und Beta-2 versucht, ich bekomme den Fehler nicht weg.

die Partitionierung ist wie folgt:

1. Partition auf der Platte ist sda2 (für /boot)
2. Partition ist sda1; WinXP (war früher die erste Partition)
3. Partition ist sda3 (ursprünglich 2 Partitionen, zusammengelegt, damit eine primäre frei wird)
4. Partition (sda4) enthält mehrere logische Partitionen

Hat irgendjemand eine Idee, wie ich das gebacken bekomme, ohne die ganze Platte komplett platt zu machen und anschließend neu zu formatieren (letzte Lösung)
 

RME

Advanced Hacker
Hallo,

Deine Partitionsaufteilung (1. Partition = sda2, etc) hab ich so noch nie gesehen.

Könntest Du mal die Ausgabe (genauer links) von /dev/disk posten:

Code:
# cd /dev
# ls -lR disk/
und auch noch:

Code:
# fdisk -l
Gruss,
Roland
 
OP
Systemcrasher

Systemcrasher

Hacker
Hallo RME,

vielen Dank für die schnelle Antwort.

Die Reihenfolge kommt daher, daß ich die Bootpartition nachträglich von der sda1 abgeknabbert habe.

Den ersten von Dir angegebenen Befehl kennt die Puppy-Live-CD nicht.

fdisk liefert aber diese Antwort:

Code:
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              65        1297     9904072+   7  HPFS/NTFS
/dev/sda2   *           1          64      514048+  83  Linux
/dev/sda3            1298       22901   173534130   83  Linux
/dev/sda4           22902       30399    60227685    f  W95 Ext'd (LBA)
/dev/sda5           22902       23029     1028128+  82  Linux swap / Solaris
/dev/sda6           23030       25640    20972826   83  Linux
/dev/sda7           25641       30399    38226636   83  Linux

Partition table entries are not in disk order

Unter Gparted sieht das so aus.

http://www.myimg.de/?img=gpartedbilda5787.png

Auch cfdisk sagt mir, daß das Sektoren-Ende von sda2 vor dem Sektorenende von sda1 liegt.

Also sollte der Error 18 doch eigentlich nicht mehr auftreten. :???: :???: :irre: :irre: :irre: :???: :???:
 

josef-wien

Ultimate Guru
Zuerst müssen wir wissen, wohin überall GRUB schon installiert wurde. Starte das Rettungssystem, melde Dich als root an (ohne Paßwort) und führe den (von robi entliehenen) Befehl
Code:
for i in $(awk '/[0-9]/ {print $4}' /proc/partitions);do file -s /dev/$i; done | grep -i grub | cut -d":" -f1
aus. Alternativ kannst Du auch dreimal
Code:
dd if=/dev/XXX bs=512 count=1 | hexdump -C | egrep -i "error|grub"
ausführen, wobei für XXX jeweils sda, sda1 und sda2 anzugeben sind, und schauen, wo im Ergebnis das Wort "GRUB" vorkommt. Außerdem ist interessant, auf welcher Partition aus GRUB-Sicht dessen Dateien enthalten sind:
Code:
grub
find /boot/grub/stage2
quit
 
Dies hier
Code:
grub
find /boot/grub/stage2
quit
wird möglicherweise kein Ergebnis bringen, weil /dev/sda2 ja eine Boot- und keine Rootpartition ist. Bei openSUSE vielleicht doch, weil openSUSE in /boot einen Symlink auf sich selbst setzt, vielleicht aber auch nicht, wenn der Symlink irgendwie abhanden gekommen ist oder nicht gesetzt wurde. Ich würde deshalb zusätzlich auch nach
Code:
grub
find /grub/stage2
quit
suchen.

Außerdem habe ich irgendwo noch den Hinweis gefunden, dass Error 18 auftreten kann, wenn in der menu.lst "savedefault" steht. Kannst Du mal schauen, ob das da evtl. irgendwie reingerutscht ist?

Noch was: Wenn Dich die verkehrte Reihenfolge der Partitionen stört, kannst Du sie vor der nächsten Linux-Installation mit fdisk korrigieren:
Code:
fdisk /dev/sda
x
m
f
w
Jetzt würde ich das aber nicht unbedingt machen, weil sich dadurch die Gerätenummern wieder ändern und das schon installierte Linux entsprechend angepasst werden müsste und Dein Problem wahrscheinlich nicht daran liegt (eine verkehrte Partitionsreihenfolge ist nicht außergewöhnlich und bereitet bei primären Partitionen meist keine Probleme; problematisch wird es erst, wenn die Kette logischer Partitionen durcheinander ist).
 

joanne

Member
Hi!
Finde Grub: (als root natürlich)
Code:
fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n  2 -e '2/1 \"%x\" \"\\n\"' X | xargs -n1 -IY sh -c \"case  \"Y\" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder höher ;; *) echo X: Kein GRUB Y ;; esac\""
hat in Ubuntu, Mint und Fedora funktioniert.
joanne

Edit: dto. openSUSE
Auszug:
Code:
/dev/sda: GRUB 2 v1.97 oder höher
/dev/sda1: Kein GRUB b60
/dev/sda4: GRUB Legacy
/dev/sda10: GRUB Legacy
...
/dev/mmcblk0: Kein GRUB 00 (SD-Karte)
 

RME

Advanced Hacker
Hallo,

joanne schrieb:
fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n 2 -e '2/1 \"%x\" \"\\n\"' X | xargs -n1 -IY sh -c \"case \"Y\" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder höher ;; *) echo X: Kein GRUB Y ;; esac\""
Falls von interesse. dies ist vermutlich von:

http://forums.debian.net/viewtopic.php?f=17&t=56728

und etwas leserlicher:

Code:
fdisk -l 2>/dev/null | \
egrep "Disk /|/dev/" | \
sed "s#^/dev/#Part /dev/#" | \
awk '{print $2}' | sed 's/://' | \
xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n  2 -e '2/1 \"%x\" \"\\n\"' X | \
xargs -n1 -IY sh -c \
\"case  \"Y\" in \
'48b4') echo X: GRUB 2 v1.96 ;; \
'aa75' | '5272') echo X: GRUB Legacy ;; \
'7c3c') echo X: GRUB 2 v1.97 oder höher ;; \
*) echo X: Kein GRUB Y ;; \
esac\""
Gruss,
Roland
 
OP
Systemcrasher

Systemcrasher

Hacker
Zuerst mal vielen Dank für eure umfangreiche Hilfeleistungen. ;)

Die Umsetzung ist allerdings nicht ganz einfach, da ich im Moment nur von einer Live-CD das System gestartet bekomme (Puppy 5.1, das aber nicht stabil läuft und sich ständig aufhängt).

Außerdem kennt die CD kein grep (interessanterweise aber egrep).

Daher war der erste Befehl von josef-wien nicht ganz ausführbar, auch ohne den grep-Teil gabs ne Fehlermeldung (Syntax-error, hab aber keinen gefunden).

Beim dd-Befehl hat mir die Konsole gesagt: "hexdump -i invalid option" (aber das Puppy-egrep hat diese Option, hab extra nachgeschaut)

Der find-Befehl in der Grub-Shell lieferte mir das selbe Ergebnis, wie ich es auch bei meinen ersten Versuchen hatte, d.h., stage2 ist genau dort, wo auch stage1 ist (s. Tip von traffic):

Code:
(hd0,1)
(hd0,2)
(hd0,5)

Pfad: /boot/grub/stageX

Joannes Befehl habe ich jetzt nicht ausgeführt (zu lang und daher zu fehleranfällig zum Abtippen), werd das aber beizeiten mal als script machen (RME hat das ja praktisch vorgelegt). Auch geht es da um Grub1.97, ich habe aber Grub 0.97. Ginge das dann analog?

Vorläufiges Fazit: Die Grub-Dateien sind dort wo sie sein sollen, grub findet sie, wenn man es danach suchen läßt, aber nicht freiwillig beim booten.

Irgendwie merkwürdig...

PS: Die boot-Reihenfolge stört mich nicht, denn das ist ja das Schöne an Linux: Bei Änderungen in der Platten (2. Platte) -oder Konfigurationsänderung (neue Partitionen) bleiben die Programme funktionsfähig, weil sich die Pfade eben nicht ändern. :) :) :)


Edit:

Habe die Befehle jetzt mal auf nem Funktionierenden PC (unter ConnochaetOS Beta2) ausprobiert. Hier funzen die Befehle einwandfrei, was heißt, daß zumindest in Euren Beiträgen keine Tippfehler drin sind. ;)

Allerdings ergab die "Monsterbefehlszeile" keine Ausgabe. Was aber auch hier an Grub 0.97 statt 1.97 liegen kann.


Edit-2:

Habe das jetzt mal den Code vom RME in ein Script "umgewandelt" und um sudo "erleichtert", da nicht installiert.
Leider beendet sich die Konsole beim Ausführen, so daß ich keine Ausgabe sehen kann (Test auf einem funktionierendem Rechner).
 

RME

Advanced Hacker
Hallo Systemcrasher,

Systemcrasher schrieb:
Leider beendet sich die Konsole beim Ausführen, so daß ich keine Ausgabe sehen kann
Du könntest das Resultat in eine Datei schreiben:

Code:
fdisk -l 2>/dev/null | \
egrep "Disk /|/dev/" | \
sed "s#^/dev/#Part /dev/#" | \
awk '{print $2}' | sed 's/://' | \
xargs -n1 -IX sh -c "hexdump -v -s 0x80 -n  2 -e '2/1 \"%x\" \"\\n\"' X | \
xargs -n1 -IY sh -c \
\"case  \"Y\" in \
'48b4') echo X: GRUB 2 v1.96 ;; \
'aa75' | '5272') echo X: GRUB Legacy ;; \
'7c3c') echo X: GRUB 2 v1.97 oder höher ;; \
*) echo X: Kein GRUB Y ;; \
esac\"" > grub_find.txt
Gruss,
Roland
 
OP
Systemcrasher

Systemcrasher

Hacker
RME schrieb:
Du könntest das Resultat in eine Datei schreiben:

Danke Roland. ;)

Aber das erzeugt nur eine leere Datei (auf dem funktionierenden Rechner). Ich vermute mal, das liegt - wie oben erwähnt - daran, daß ich Grub 0.97 habe und nicht 1.97.
 

josef-wien

Ultimate Guru
Systemcrasher schrieb:
Ich vermute mal, das liegt - wie oben erwähnt - daran, daß ich Grub 0.97 habe und nicht 1.97.
Damit liegst Du falsch. Diese Befehlskette schreibt pro MBR und Partition jeweils eine Zeile und gibt dabei entweder "Kein GRUB" oder die GRUB-Version aus. Der von mir genannte for-Befehl begnügt sich damit, von der Gesamtmenge nur jene Zeilen auszugeben, bei denen GRUB gefunden wurde. Wenn die Befehle bei Dir nicht funktionieren, dann müssen sie bei der von Dir verwendeten Linux-Version anders oder gar nicht implementiert sein.

Systemcrasher schrieb:
Vorläufiges Fazit: Die Grub-Dateien sind dort wo sie sein sollen
Dem kann ich nicht ganz zustimmen. Wenn (hd0,1) eine Boot-Partition ist, dann enthält die Systempartition (hd0,2) üblicherweise diese Dateien nicht. (hd0,5) ist vermutliche eine weitere Linux-Installation. Aber wir können jetzt annehmen, daß (hd0,0) auch aus GRUB-Sicht Deine Windows-Partition ist.

Da ich denke, daß Du GRUB mehrfach installiert hast, solltest Du gemäß http://www.linux-club.de/viewtopic.php?f=4&t=100589&p=612947#p612947 GRUB in den MBR installieren. Ob es wirklich root (hd0,1) heißt, kann ich bei drei vorhandenen Möglichkeiten natürlich nicht beurteilen.
 

RME

Advanced Hacker
Hallo,

Beim dd-Befehl hat mir die Konsole gesagt: "hexdump -i invalid option" (aber das Puppy-egrep hat diese Option, hab extra nachgeschaut)
Ich habe mir puppy-5.1.1 heruntergeladen:

ftp://ibiblio.org/pub/linux/distributions/puppylinux/puppy-5.1.1/

Code:
puppy-5.1.1

lupu-511.iso	raw CD image	132,924 KB	09/02/2010 05:06:00 AM

ftp://ibiblio.org/pub/linux/distributions/puppylinux/puppy-5.1.1/md5sums.txt

Code:
6e34d1bcdad74df7d6352a6d672522ec  lupu-511.iso

Die md5sum habe ich überprüft:

Code:
> md5sum lupu-511.iso
6e34d1bcdad74df7d6352a6d672522ec  lupu-511.iso
>
Dann habe ich mein System von der Puppy CD gebootet und das Script zum suchen des GRUB audgeführt. Hat nicht funktioniert mit der Fehlermeldung:

Code:
hexdump invalid number '0x80'
Dies bezieht sich auf die '-s' Option von hexdump. Habe dann das Script nochmals ausgeführt, aber mit:

Code:
-s 128
Resultat (für mein System, von Puppy gebootet):

Code:
fdisk -l 2>/dev/null | \
egrep "Disk /|/dev/" | \
sed "s#^/dev/#Part /dev/#" | \
awk '{print $2}' | sed 's/://' | \
xargs -n1 -IX sh -c "hexdump -v -s 128 -n  2 -e '2/1 \"%x\" \"\\n\"' X | \
xargs -n1 -IY sh -c \
\"case  \"Y\" in \
'48b4') echo X: GRUB 2 v1.96 ;; \
'aa75' | '5272') echo X: GRUB Legacy ;; \
'7c3c') echo X: GRUB 2 v1.97 oder höher ;; \
*) echo X: Kein GRUB Y ;; \
esac\"" [> grub_search.txt]

Code:
> cat grub_search.txt
/dev/sda: GRUB Legacy
/dev/sda1: Kein GRUB 00
/dev/sda2: GRUB Legacy
/dev/sda3: Kein GRUB 00
/dev/sda4: Kein GRUB 00
/dev/sda5: Kein GRUB 00
/dev/sda6: Kein GRUB 00
/dev/sda7: Kein GRUB 00
/dev/sdb: Kein GRUB 2eb2
/dev/sdb1: Kein GRUB 00
/dev/sdb2: Kein GRUB 00
/dev/sdb3: Kein GRUB 00
/dev/sdb4: Kein GRUB 00
/dev/sdb5: Kein GRUB 00
/dev/sdb6: Kein GRUB 00
>

Anmerkung: ich habe Puppy vorher nicht gekannt -- mein erster Eindruck ist sehr positiv :thumbs:

Gruss,
Roland
 
OP
Systemcrasher

Systemcrasher

Hacker
josef-wien schrieb:
Systemcrasher schrieb:
Ich vermute mal, das liegt - wie oben erwähnt - daran, daß ich Grub 0.97 habe und nicht 1.97.
Damit liegst Du falsch.

gut zu wissen. :)

Habe das jetzt übrigens nochmal auf nem anderen Rechner mit der selben Puppy-Version (installiert) getestet, bis auf den langen "Monsterbefehl" funzen die anderen hier. :irre:

Da die rxvt-Konsole leider kein C&P beherrscht, habe ich das in eine Datei geschrieben und um die erste Zeile "#!/bin/bash" ergänzt. Leider funzt das bei dieser (!) Puppy-Version so nicht (auch nicht mit /bin/sh). Aber auf anderen Distries (Arch, Connochaetos, ...) klappt das so.

Die anderen Befehle haben auf dem Tosh übrigens alle ein sinnvolles Ergebnis geliefert.

Es handelt sich um die selbe Version, Puppy 5.1, nur einmal installiert (auf dem Tosh) und einmal von CE gebootet (auf dem Error-18-Rechner). :irre:

Da ich denke, daß Du GRUB mehrfach installiert hast, solltest Du gemäß http://www.linux-club.de/viewtopic.php?f=4&t=100589&p=612947#p612947 GRUB in den MBR installieren. Ob es wirklich root (hd0,1) heißt, kann ich bei drei vorhandenen Möglichkeiten natürlich nicht beurteilen.

Ja, aber das hatte ich schon probiert, bevor ich hier gefragt habe (s.o.).


RME schrieb:
Hallo,

Beim dd-Befehl hat mir die Konsole gesagt: "hexdump -i invalid option" (aber das Puppy-egrep hat diese Option, hab extra nachgeschaut)
Ich habe mir puppy-5.1.1 heruntergeladen:

Dann ist Deine etwas aktueller. Ich mache da nicht jeden Versionssprung mit. Wenn eine Version bei mir stabil läuft, isses ok. Und die 5.1 ist deutlich schneller und stabiler als die 4.3. :)

Dann habe ich mein System von der Puppy CD gebootet und das Script zum suchen des GRUB audgeführt. Hat nicht funktioniert mit der Fehlermeldung:

Einzelne Versionen von Puppy können sich durchaus gravierend unterscheiden. Das ist übrigens eines der wenigen Dinge, die mich an Puppy stören. Man verliert dabei leicht den Überblick und Hilfe wird schwieriger, weil manches zwar auf der einen funzt, auf der nächsten dann aber nicht.

Ein anderes ist (zumindest bei der von mir aktuell verwendeten Version) die fehlende Interaktivität von adduser. Bzw., daß man bei allen Puppys immer als root arbeitet. Aber den meisten Puppy-Anwendern gefällt eben genau das besonders daran.

Es soll zwar noch eine Multi-User-Version von Puppy geben, aber die habe ich mir noch nicht angeschaut (bin zu faul, danach zu suchen) ;)

Anmerkung: ich habe Puppy vorher nicht gekannt -- mein erster Eindruck ist sehr positiv :thumbs:

Gruss,
Roland

Ja, ich nutze Puppy übrigens auch gerne als "Notfall-CD", weil es auf fast allen Systemen problemlos läuft und Dinge wie GParted gleich standardmäßig mitbringt.

Gruß, Norman
 

RME

Advanced Hacker
Hallo Norman,

Ich denke folgendes wäre ein Versuch wert.

Ich gehe davon aus. dass sich /boot in der ersten Partition befindet, bei Dir /dev/sda2 (gemäss Deines ersten Beitrags), und dass das übrige Linux auf /dev/sda3 ist.

-1- Boote Dein System von einer live Linux CD: openSUSE od. Puppy.

-2- Öffne eine Konsole.

-3- falls nicht vorhanden, erstelle folgende mount-Verzeichnisse:

# mkdir /mnt
# mkdir /mnt/boot

-4- Mount /dev/sda2 und /dev/sda3

# mount /dev/sda2 /mnt/boot
# mount /dev/sda3 /mnt

-5- Installier GRUB

# grub-install --root-directory=/mnt /dev/sda

-6- fstab gegebenenfalls anpassen (/mnt/etc/fstab) so dass die boot Partition an "/" gemounted wird.

-7- Unmount die Partitionen und mache eienen Neu-Start

# umount /mnt/boot
# umount /mnt

Sollte dies funktionieren, müsste nachher noch das Windows auf /dev/sda1 bootbar gemacht werden.

Gruss,
Roland
 
OP
Systemcrasher

Systemcrasher

Hacker
RME schrieb:
Hallo Norman,

Ich denke folgendes wäre ein Versuch wert.


Gruss,
Roland


Hallo Roland,

'tschuldigung, daß ich mich erst jetzt melde.

Leider hat sich bei diesem Versuch der betreffende Rechner verabschiedet. Da zunächst Linux unter einem graphischen Desktop regelmäßig einfrohr (was mir nun auch die Festplattenpartitiopnen zerschossen hat, halt blöde wenn das passiert, während gParted gerade ne Partition vergrößert), jedoch nicht unter init3, vermutete ich erst einen Defekt des RAM.

Nun zeigte sich, daß aber die Graphikkarte die Grätsche gemacht hat (zum Glück nicht onboard).

Muß mir also erst mal ne andere Graka organisieren, bevor ich da weitermachen kann.

Viele Grüße, Norman
 
Oben