[gelöst] Nach Verschieben von Partitionen: Grub im Eimer

christianhb · 2 Aug. 2009

Hallo zusammen,

ich habe Windows XP und Suse 11 parallel auf einer Platte installiert und benutze den Windows-Bootloader zum Starten. Gestern habe ich die Suse- und die Swap-Partition verschoben, um etwas mehr Platz zu schaffen und die Partitionen zu "verdichten". Nun sieht das ganze wie folgt aus:

Danach startete Suse natürlich nicht mehr weil die Partition nicht mehr an der erwarteten Position ist. Habe daraufhin mit der Installations-DVD gebootet und in einer Shell mit dem Befehl "dd" die ersten 512 Bytes der Root-Partition in eine extra Datei geschrieben, um diese erneut dem Windows-Bootloader vorzuwerfen (so wie ich es damals bei der Suse-Inst. auch gemacht hatte).

Dann allerdings schmiert Suse beim Booten ab (Meldung "kernel panic", "bad blocks"). Habe daraufhin das Reparatur-Tool von der Installations-DVD genutzt welches dann selbstständig die Probleme behoben hat (behauptet es zumindest), betroffen waren angeblich Bootloader und fstab.

Starte ich jetzt Suse, bekomme ich ein Grub-Prompt ohne irgendwelche Fehlermeldungen, aber Suse ist nicht in Sicht :-\
Von der Inst.-DVD kann ich weiterhin problemlos ins mein Suse von der Platte booten.

Meine /etc/fstab sieht wie folgt aus:

Code:

/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 swap                 swap       defaults              0 0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part1 /windows/C           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD160JJS08HJ1GLA11906-part1 /windows/D           ntfs-3g    users,gid=users,fmask=000,dmask=000,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD160JJS08HJ1GLA11906-part5 /windows/E           ntfs-3g    users,gid=users,fmask=000,dmask=000,locale=de_DE.UTF-8 0 0
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
/dev/sdb2            /data2               ext3       defaults              1 1
/dev/sdb2            /data3               ext3       defaults              1 1

Die Ausgabe des Befehls "df" ist wie folgt:

Code:

Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
udev                   1037008       124   1036884   1% /dev
/dev/sdb1             29366788  18718140  10648648  64% /windows/C
/dev/sda1             40957684  20669152  20288532  51% /windows/D
/dev/sda5            115322568  79906816  35415752  70% /windows/E
/dev/sdb2             22705980   9143884  12408632  43% /data2
/dev/sdb2             22705980   9143884  12408632  43% /data3

Mir ist übrigens auch schleierhaft, warum das Objekt "/dev/sdb2" in beiden Listen doppelt auftaucht...?

Hat irgendjemand eine Idee wo mein Problem ist (korrupte "bootsek.lin" aus dd oder Grub an sich im Eimer?) und wie ich es beheben kann?

Danke & Gruß
Christian

josef-wien · 2 Aug. 2009

Wenn Du in der fstab dieselbe Partition zweimal und an unterschiedlichen Einhängepunkten einhängst, ist sie eben auf 2 Arten ansprechbar. Dafür finde ich den Einhängepunkt / gar nicht.

christianhb schrieb:
Starte ich jetzt Suse, bekomme ich ein Grub-Prompt ohne irgendwelche Fehlermeldungen, aber Suse ist nicht in Sicht

Was heißt das im Klartext?

Was ergibt:

Code:

fdisk -l
cat /boot/grub/menu.lst
cat /boot/grub/device.map
cat /etc/grub.conf
ls -l /dev/disk/by-id/ | grep -v part

christianhb · 3 Aug. 2009

Ich habe fstab schon etwas korrigiert, dass "root" fehlte war mir auch aufgefallen. Die Datei sieht jetzt so aus:

Code:

/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 swap                 swap       defaults              0 0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part1 /windows/C           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD160JJS08HJ1GLA11906-part1 /windows/D           ntfs-3g    users,gid=users,fmask=000,dmask=000,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD160JJS08HJ1GLA11906-part5 /windows/E           ntfs-3g    users,gid=users,fmask=000,dmask=000,locale=de_DE.UTF-8 0 0
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
/dev/sdb2            /                    ext3       defaults              1 1

Die Ausgabe von fdisk -l ist

Code:

Platte /dev/sda: 160.0 GByte, 160041885696 Byte
255 Köpfe, 63 Sektoren/Spuren, 19457 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x302b302a

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1               1        5099    40957686    7  HPFS/NTFS
/dev/sda2   *        5100       19456   115322602+   f  W95 Erw. (LBA)
/dev/sda5            5100       19456   115322571    7  HPFS/NTFS

Platte /dev/sdb: 80.0 GByte, 80026361856 Byte
255 Köpfe, 63 Sektoren/Spuren, 9729 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0xaa78ca44

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1   *           1        3656    29366788+   7  HPFS/NTFS
/dev/sdb2            3657        6528    23069340   83  Linux
/dev/sdb3            6529        6790     2104515   82  Linux Swap / Solaris

Der Inhalt von /boot/grub/menu.lst ist

Code:

# Modified by YaST2. Last modification on Sa Nov 22 16:15:29 CET 2008
default 0
timeout 8
gfxmenu (hd0,1)/boot/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.0
    root (hd0,1)
    kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 resume=/dev/sdb2 splash=silent showopts
    initrd /boot/initrd

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title openSUSE 11.0 (Failsafe)
    root (hd0,1)
    kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off x11failsafe
    initrd /boot/initrd

title Windows Bootloader
rootnoverify (hd0,0)
  chainloader +1

Dort hatte ich gestern allerdings (hd1,2) jeweils in (hd1,1) geändert, denn die root-Partition ist nun die zweite auf der Platte, nicht mehr die dritte.

Der Inhalt von /boot/grub/device.map ist

Code:

(fd0)   /dev/fd0
(hd0)   /dev/sda
(hd1)   /dev/sdb

und der von /etc/grub.conf

Code:

setup --stage2=/boot/grub/stage2 (hd0) (hd1,2)
quit

Der Befehl ls -l /dev/disk/by-id/ | grep -v part ergibt

Code:

lrwxrwxrwx 1 root root  9  3. Aug 2009  ata-SAMSUNG_HD080HJ_S08EJ1KL905319 -> ../../sdb
lrwxrwxrwx 1 root root  9  3. Aug 2009  ata-SAMSUNG_HD160JJ_S08HJ1GLA11906 -> ../../sda
lrwxrwxrwx 1 root root  9  3. Aug 2009  scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319 -> ../../sdb
lrwxrwxrwx 1 root root  9  3. Aug 2009  scsi-SATA_SAMSUNG_HD160JJS08HJ1GLA11906 -> ../../sda

Hat er da doppelte Verweise auf die Platten oder missinterpretiere ich da was...?

Das Grub-Prompt erscheint, nachdem ich im Window-Bootloader meinen Suse-Eintrag ausgewählt habe, d.h. ich bekomme daraufhin nicht das normale graphische Grub-Menü zu sehen, sondern eine Art Konsolen-Prompt. Dort http://forums.scotsnewsletter.com/index.php?act=ST&f=14&t=5025 wird beschrieben wie man sich da behelfen kann, die dort aufgeführten Befehle ergeben bei mir aber nur Fehlermeldungen.

Ich würde ja gerne selber "experimentieren", aber mir ist nicht ganz klar wo das Problem ist: ist meine grub-Konfiguration an sich im Eimer oder habe ich mit dem dd-Befehl (siehe Eröffnungs-Post) eine falsche Partition angegeben? Oder ist es was ganz anderes?

lOtz1009 · 3 Aug. 2009

So mal für Ordnung:

Code:

/dev/disk/by-id/scsi-SATA_SAMSUNG_HD160JJS08HJ1GLA11906 = sda = hd0
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319 = sdb = hd1

root (hd0,1)

kann ja dann nicht sein, sondern eher hd(1,1).

kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 resume=/dev/sdb2

Ist doch auch Quatsch. Demnach wäre ja die resume=/.
Da sollte sich alles auf sdb bzw hd1 beziehen. So wie ich das sehe hat die 160GB nichts mit Linux zu tun oder? Allerdings blick ich grad nicht ganz durch, ist etwas durcheinander.

Für deine fstab:

Code:

/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part3 swap                 swap       defaults              0 0

für Swap

Code:

/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 /                      ext3       acl,user_xattr        1 1

für /

Für die menu.lst

Code:

kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part2 resume=/dev/disk/by-id/scsi-SATA_SAMSUNG_HD080HJS08EJ1KL905319-part3

:???:

GLAUBE ICH.

christianhb · 3 Aug. 2009

Besten Dank für Deine Mühe, aber das "GLAUBE ICH" lässt mich momentan noch etwas davor zurückschrecken, das alles so direkt 1:1 zu übernehmen.

Ich würde gerne die Zusammenhänge verstehen. Was (fstab, menu.lst, device.map) guckt sich wer (Grub, Kernel) zuerst an? Erst wenn ich dadurch steige, will ich gezielt was verändern.

Du hast recht, die 160er hat nix mit Linux zu tun, obwohl sie natürlich unter /windows sicht- und schreibbar sein soll.

christianhb · 3 Aug. 2009

OK, hab Deine Vorschläge eingetragen und ich lande immer noch in der Grub-Konsole.
Ebenso habe ich mit dd die ersten 512 Bytes von der OS-Platte für den Windows-Bootloader neu kopiert, brachte keine Abhilfe.

Wenn ich nur die Zusammenhänge verstünde...

Anonymous · 4 Aug. 2009

christianhb schrieb:
Ich würde gerne die Zusammenhänge verstehen. Was (fstab, menu.lst, device.map) guckt sich wer (Grub, Kernel) zuerst an? Erst wenn ich dadurch steige, will ich gezielt was verändern.

Die Zusammenhänge verstehen ? Bitte auch da kann dir geholfen werden. Einstieg hier (nicht ganz aktuell in Kleinigkeiten, aber das Prinzip ist immer noch das Gleiche) aber nicht beschweren, wenn du dann hinterher erst recht nichts mehr verstehst, das ganze Prinzip ist sehr komplex.

Was bis jetzt nach diesen Änderungen gelaufen ist, ist erst mal nur das das System wahrscheinlich erstmal wieder einigermaßen gerichtet ist. Der Bootloader ist nach wie vor immer noch defekt. Was uns (zumindestens mich) wohl ein bischen abschreckt, du hast uns noch nicht genauer erklärt was du verschoben hast. Hast du die Rootpartition von der Platte sda auf sdb verschoben??? oder nur auf der Platte hin und her??? Und hast du Windows zwischen den Platten verschoben??? Wo stand ursprünglich der Grub-Bootloader???

Das Problem das ich sehe und was mich etwas abschreckt, ist nicht Grub an sich. Der ist schnell konfiguriert und würde auch schnell funktionieren. Allerdings konfiguriert dieser innerhalb des Bootloader an 2 bestimmten Stellen BIOS-Adressen, die auf bestimmte Adresse einer bestimmten Platte hinweisen. Wenn du zB den Grub in deiner Rootpartition neu konfigurierst, dann wird er eventuell darein schreiben, "selbe Platte" + "Block so und so" könnte aber auch anstatt schreiben, "BIOS-Plattenport" + "Block so und so" was er zB in dem Moment machen muss, wenn der Bootloader sich nicht auf der selben Platte befindet wie das Verzeichnis /boot/grub.

Wenn du diesen Bootloader jetzt kopierst und von der anderen Platte aus von Windows booten läßt, könnte es eventuell sein "selbe Platte" + "Block so und so" geht in die Hose, weil BIOS noch die andere Platte als aktuelle Platte kennt und somit den Block auf der falschen sucht. Habe ich so noch nicht probiert währe aber durchaus denk- und erklärbar. Man müsste hier wirklich genau wissen was der Windowsloader da genau macht, wenn er einen anderen Bootloader auf einer anderen Platte startet. Jemand der sich damit ein bisschen auskennt würde das so wohl gar nicht erst versuchen. Grub über den Windowsloader zu konfigurieren macht man so nun auch nicht unbedingt jede Woche, so das wir zwar prinzipiell wissen wie es geht, aber nicht alle Fallstricke kennen geschweige schon über alle drüber gestolpert sind.

Ich würde zB so vorgehen um allen Problemen von vorne herein so weit wie möglich aus dem Weg zu gehen

* den Windowsbootloader mittels dd kopieren,
* dann den Grub dort an genau diese Stelle installieren,
* dann den Grubbootloader testen,
* wenn er funktioniert diesen kopieren und Windows unterschieben
* dann den kopierten Windowsbootloader wieder zurückschreiben.
* testen

Und selbst hier ist noch eine Falle, Grub versucht per default den 2. Schritt und zwar die konfigurierte "FILESYSTEM_stage1-5" Datei in die Nähe bzw unmittelbar hinter den Bootloader in einen in vielen Dateisystemen unbenutzen Bereich zu kopieren. Wenn er dort genügend Platz dafür findet, wird er das auch machen. Das müsste man am aller Besten hier auch noch verhindern.

Also recht kompliziert. Und je mehr Ahnung man von der ganzen Geschichte hat, um so komplizierter wird man es hier warscheinlich machen, nur um wirklich sicher zu gehen. Du hast das damals als du es eingerichtet hast bestimmt nicht halb so kompliziert gemacht und es hat wohl trotzdem funktioniert. Desshalb währe es eben nicht schlecht erstmal zu wissen in wieweit du jetzt dein System zusammen- oder durcheinander gewürfelt hast, eventuell kann das einige, zumindestens meiner Bedenken, zerstreuen.

robi

josef-wien · 4 Aug. 2009

christianhb schrieb:
ist meine grub-Konfiguration an sich im Eimer oder habe ich mit dem dd-Befehl (siehe Eröffnungs-Post) eine falsche Partition angegeben?

Ich würde sagen, daß mindestens eine dieser Aussagen zutrifft.

Zuerst führe die Änderungen in fstab und menu.lst laut lOtz vom 3. August 2009, 19:36 Uhr, durch. Danach starte von der openSUSE-DVD das Rettungssystem, melde Dich als root an (ohne Paßwort) und installiere GRUB in den Bootsektor Deiner Linux-Partition:

Code:

grub
find /boot/grub/stage1
root    <== hierher kommt das, was find liefert, vermutlich: root (hd1,1)
setup   <== hierher kommt ebenfalls das, was find liefert:   setup (hd1,1)
quit

Und dann kopierst Du genau den Bootsektor, den find geliefert hat, für Deinen Windows-Bootmanager (auch wenn ich nicht verstehe, warum Du den Weg "Windows --> GRUB" gehst).

christianhb schrieb:
Was (fstab, menu.lst, device.map) guckt sich wer (Grub, Kernel) zuerst an? Erst wenn ich dadurch steige, will ich gezielt was verändern.

Mit Deinem Windows-Bootmanager startest Du auf dem Umweg über die von Dir erzeugte Datei den Bootsektor Deiner Linux-Partition. Wie es weitergeht, hat robi gerade geschrieben. Die device.map wird nur benötigt, wenn Du im laufenden System GRUB-Aktivitäten ausführst, und dient als Übersetzung zwischen Linux- und GRUB-Diktion. Beim Boot-Vorgang spielt sie nicht mit, hier richtet sich GRUB ausschließlich nach der vom BIOS vorgegebenen Festplattenreihenfolge.

Der Inhalt von grub.conf (diese Datei wird nur von YaST verwendet) scheint schon älter zu sein, denn da wurde GRUB für das System auf (hd1,2) in den MBR der Platte (hd0) installiert (von der Du aber vermutlich den PC nicht startest). Sicherheitshalber solltest Du das auf "setup --stage2=/boot/grub/stage2 (hd1,1) (hd1,1)" ändern, sonst hast Du eventuell nach dem nächsten Aufruf der YaST-Bootmanager-Einrichtung wieder ein Problem (http://www.linupedia.org/opensuse/SuSE_und_Grub).

Nachtrag:

lOtz schrieb:
root (hd0,1)

Zum Vergrößern anklicken....

kann ja dann nicht sein, sondern eher hd(1,1).

"hd0" in der menu.lst stimmt, das ist die Platte, von der das BIOS den Boot-Vorgang einleitet. Daß diese Platte dann im laufenden System zu sdb wird, liegt eher nicht daran, daß der Gerätename (/dev/sdb) nicht dauerhaft ist, sondern bei jedem Systemstart neu festgelegt wird, sondern ich vermute, daß es sich um 2 unterschiedliche Anschlußarten handelt, und da hängt die Vergabe des Gerätenamens in erster Linie von der Modulreihenfolge in der initrd ab. Auf jeden Fall ist bei dieser Konstallation besondere Vorsicht bei der Installation von GRUB angebracht (daher auch zuerst das "find", um die richtige Platte zu finden). Bei Verwendung der YaST-Bootmanager-Einrichtung kannst Du das Risiko verkleinern, wenn Du in der device.map an Stelle der Gerätenamen die Geräte-ID (dev/disk/by-id/...) einträgst bzw. wenn Du die Modulreihenfolge in der initrd änderst, ganz ausschalten kannst Du es hier nicht.

Die BIOS-Reihenfolge kannst Du z. B. mit

Code:

hwinfo --disk | egrep "Device Files:|BIOS id:"

feststellen.

christianhb · 4 Aug. 2009

robi schrieb:
Was uns (zumindestens mich) wohl ein bischen abschreckt, du hast uns noch nicht genauer erklärt was du verschoben hast. Hast du die Rootpartition von der Platte sda auf sdb verschoben??? oder nur auf der Platte hin und her??? Und hast du Windows zwischen den Platten verschoben??? Wo stand ursprünglich der Grub-Bootloader???

Ich habe in der Reihefolge

1) Mehrfach die Größe der C-Partition von Windows geändert (verkleinert, vergrößert), erst nur zu Testzwecken und dann endgültig
2) Die Suse-Partition und die Swap-Partition gelöscht
3) Ein paar Tage alte Sicherungen der Suse-Partition und der Swap-Partition mit einem Imaging-Tool so auf die Platte kopiert wie es oben in der Grafik zu sehen ist.

Alle Betriebssystem-Partitionen sind auf derselben Platte verblieben! Im Endeffekt hat sich "nur" (räusper) die Größe von C und die Reihenfolge der Partitionen geändert: erst [Win, Swap, Suse], nun [Win, Suse, Swap].

Gibt es nicht irgendwo ein Log von grub wo man sehen kann welches Problem er genau hat?

Werde nachher mal josef's Vorschlag ausprobieren...

christianhb · 4 Aug. 2009

OK, es geht zumindest etwas voran. Das Ausführen von Josefs Vorschlägen fürht zumindest dazu, dass ich nicht mehr an die Grub-Konsole gelange.

Stattdessen kommt nach Auswahl des Suse-Eintrags in meinem Windows-Bootloader nun erst die Meldung

hd(1,1)/boot/message: file not found

Wenige Sekunden später kommen die Meldungen

root (hd1,1) : File system type unknown, partition type 0xf

Error 17: cannot mount partition

Was mir nun völlig schleierhaft ist, denn hd(1,1) ist doch nun ganz offensichtlich die Suse-Partition oder ich check weniger als je zuvor

josef-wien · 4 Aug. 2009

christianhb schrieb:
Was mir nun völlig schleierhaft ist

Dann hast Du meinen Nachtrag nicht gelesen.

christianhb · 6 Aug. 2009

Doch, ich habe ihn nur nicht richtig gelesen

Danke an alle die mir hier geholfen haben!

[gelöst] Nach Verschieben von Partitionen: Grub im Eimer

christianhb

Newbie

josef-wien

Ultimate Guru

christianhb

Newbie

lOtz1009

Moderator

christianhb

Newbie

christianhb

Newbie

Anonymous

Gast

josef-wien

Ultimate Guru

christianhb

Newbie

christianhb

Newbie

josef-wien

Ultimate Guru

christianhb

Newbie