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

Probleme mit Grub und Windows nach Umzug mit dd

mic77

Newbie
Hallo,

ich habe die Win-Partition von einer alten Platte mit dd auf sda2 kopiert. Jedoch startet Grub Win nicht. Ich erhalte keine Fehlermeldung, sondern sehe nur die Parameter für Win in Grub. Weiß jemdand Rat? Ich habe keine Ahnung und habe leider auch nichts gefunden. Meine einzige Idee ist, das die Win-Partition zu weit auf der Platte liegt. Aber dennoch muss einen Weg geben.

sda2 läßt sich ganz normal mounten.

Nebenbei, ist es möglich das CD-Rom in Grub, wie das Floppy, einzubinden?

Danke

fdisk -l
Platte /dev/sda: 250.0 GByte, 250059350016 Byte
255 heads, 63 sectors/track, 30401 cylinders
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 1 3917 31463271 83 Linux
/dev/sda2 3918 7834 31463302+ c W95 FAT32 (LBA)
/dev/sda3 7835 30401 181269427+ f W95 Erw. (LBA)
/dev/sda5 7835 30401 181269396 83 Linux

Platte /dev/sdb: 203.9 GByte, 203928109056 Byte
255 heads, 63 sectors/track, 24792 cylinders
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

Gerät boot. Anfang Ende Blöcke Id System
/dev/sdb1 1 262 2104483+ 82 Linux Swap / Solaris
/dev/sdb2 263 22455 178265272+ 83 Linux
/dev/sdb3 22456 24792 18771952+ 83 Linux

device.map
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb

menu.lst
# Modified by YaST2. Last modification on Do Mär 1 18:00:59 CET 2007
default 0
timeout 3
gfxmenu (hd0,0)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.2
root (hd0,0)
kernel /boot/vmlinuz-2.6.18.2-34-default root=/dev/sda1 vga=0x31a resume=/dev/sdb1 splash=silent showopts
initrd /boot/initrd-2.6.18.2-34-default

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

grub.conf
setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
quit
 

TomcatMJ

Guru
Hi!
Code:
title Windows
root (hd0,1)
makeactive
chainloader +1
dürfte vermutlich besser dein Windows starten können sofern du vorher deinen Bootsektor im windows per Wiederherstellungskonsole mit fixboot und fixmbr wiederhergestellt hast und danach aus einem Linux-Rescue-System mit dem hier schon öfters besprochenen Weg über mounten deiner Linux-Root-Partition und
Code:
grub-install --rooct-directory=/<pfad wohin du dein Linux-Root gemountet hast> hd0
deinen Grub reinstaliert hast.

Bis denne,
Tom
 

wolf_xxl

Newbie
Hallo,
ich glaub das Problem verstanden zu haben. Windows startet nicht aber die Optionen (rootnoverify (hd0,0)) erscheinen. Grub findet die Platte, aber Windows startet nur von einer Master- nicht von einer Slaveplatte. Der Tipp:

title windows
root (hd1,0)
makeactive
chainloader +1
map (hd0) (hd1)
map (hd1) (hd0)

wobei die einzelnen Parameter angepasst werden müssen. Die Bereiche "map" gaukeln Windows den Startbereich der ersten Platte vor.
 

admine

Ultimate Guru
wolf_xxl schrieb:
Hallo,
ich glaub das Problem verstanden zu haben. Windows startet nicht aber die Optionen (rootnoverify (hd0,0)) erscheinen. Grub findet die Platte, aber Windows startet nur von einer Master- nicht von einer Slaveplatte. Der Tipp:

title windows
root (hd1,0)
makeactive
chainloader +1
map (hd0) (hd1)
map (hd1) (hd0)

wobei die einzelnen Parameter angepasst werden müssen. Die Bereiche "map" gaukeln Windows den Startbereich der ersten Platte vor.

Quatsch :!:
/dev/sda ist für Grub (hd0) laut device.map => es muss nichts gemappt werden.

TomcatMJ hatte das Problem der falschen Partitionsangabe schon richtig erkannt.
 
OP
M

mic77

Newbie
Der Fehler mit der falschen Partition ist echt peinlich. Ich hatte es umgestellt aber wohl nicht gespeicher usw.

Bevor ich jedoch mit der Windows-CD den MBR fixe, will ich die Root-Partition sichern. Ich habe mit Win in der Hinsicht keine guten Erfahrungen gemach. Der Festplatten-Check hatte mal meine Root kaputtrepariert.

Wenn ich die Root sichere darf diese doch nicht gemouted sein? Sicheren will ich wieder mit dd.

Michael
 

TomcatMJ

Guru
mic77 schrieb:
Bevor ich jedoch mit der Windows-CD den MBR fixe, will ich die Root-Partition sichern. Ich habe mit Win in der Hinsicht keine guten Erfahrungen gemach. Der Festplatten-Check hatte mal meine Root kaputtrepariert.
Dir ist aber lar, daß der Festplattencheck ein Dateisystemcheck ist,der nur auf FAT unD NTFS-Dateisystemen funktioniert und nicht identisch mit den beiden Komamndozeilenbefehlen fixbmr und fixboot ist die ja nur den MBR und den Bootsector Windows-konform wiederherstellen?
Wenn du mit dem Festplattencheck auf etwas anderes als FAT oder NTFS-Dateisysteme losgehst ist es kein Wunder, daß die Dateisysteme der damit geprüften Nicht-FAT und Nicht-NTFS Partitionen geschreddert werden.
Nutz einfach nur() fixmbr und fixboot dazu und gehe oben genannte Prozedur zum reinitialisieren eines ordnungsgemäßen Grub und es sollte wieder funktionieren. Dabei wird dein Root-Filesystem gar nicht angetastet, nur der Botomanager wird ja zuerst überschrieben und dann durch die Reinitialisierung des GRUB dann auch repariert (gemäß dem was du dann ja schon in der menu.lst vorher angepasst/korrigiert haben solltest).
Wenn ich die Root sichere darf diese doch nicht gemouted sein? Sicheren will ich wieder mit dd.
Nö, dazu solte das Rootfilesystem nicht gemountet sein. Jedoch ist dd nicht unbedingt dazu geeignet ein Backup zu machen,da du dazu ja eine Festplatte benötigst auf der mehr Platz ist als dein Rootfilesystem insgesamt benötigt(inklusive der leeren Bytes), da würde ich an deiner Stelle eher zu mkcdrec oder der Kombination Mindi/Mondo greifen, denn damit bekommst du platzsparendere Backups als mit dd allein hin, die zudem auch gleich auf DVD oder CD-Rohlinge ausgelagert werden können.
Durch dd werden einfach nur 1:1 Datenimages der gesamten Partition ungeachtet des Dateisystems oder des darin tatsächlich verbrauchten Platzes gemacht, die dann aufgrund der Plattengeometrie dann auch wieder nur auf einer Platte mit einer 100% identischen Geometrie sauber rückspielbar wären, und manchmal sind selbst Platten derselben Modellbezeichnung je nach Hardware-Revision mit unterschiedichen Geometrien versehen, wodurch schon so mancher Restore-Versuch von mit dd erstellten Backups auf neue Platten vereitelt wurde.

Bis denne,
Tom
 
OP
M

mic77

Newbie
Den Festplattencheck hat Windows von sichaus auf die root erweitert. Seid dem schwitze ich immer Blut wenn das wieder anspringt. Aber bitte nicht fragen warum das so war, ist halt passiert.

Danke für die Info bezüglich dd. Aber da meine Root nur 32GB groß ist und auch gerade auf sATA umgestellt habe, sind noch rund 200GB an Plattenplatz frei. Eine 32GB-Datei stellt doch kein Problem da?

Außerdem dachte ich, dd schreibt keine freien Sektoren mit. Dafür ist doch dd_rescue da, oder?

Michael
 

TomcatMJ

Guru
mic77 schrieb:
Danke für die Info bezüglich dd. Aber da meine Root nur 32GB groß ist und auch gerade auf sATA umgestellt habe, sind noch rund 200GB an Plattenplatz frei. Eine 32GB-Datei stellt doch kein Problem da?
Na dann sollte das wirklich kein Probem darstellen....zumindest nicht wenn du eine standardmäßige Formatierung mit ext2/ext3 oder Reiserfs bei der Partitionierung mit YaST gemacht hast oder XFS bzw. JFS nutzt (Stichworte: Blocksize und Inodes und deren Grenzen)....
Außerdem dachte ich, dd schreibt keine freien Sektoren mit. Dafür ist doch dd_rescue da, oder?
Nö, dd erstelt eine Bitweise Kopie des Inhalts einer Datei oder eines Devices (und somit auch einer Partition). Dagegen dient dd_rescue auch bei defekten Stellen weiter zu machen wo dd abbrechen würde aufgrund von Lesefehlern. Dabei werden bei dd_rescue-Nutzung trotz mehrfacher Leseversuche, deren Anzahl man übrigens auch per Parameter einstellen kann, immer noch defekte Stellen/Sektoren mit 0 als Wert ersetzt da der Ausgangswert ja nicht lesbar war udn somit hat man wenigtens etwas von den daten dann sichern können trotz der eventuellen Defekte, es dient also primär der Datenrettung und nicht nur dem reinen Sichern bzw. 1 zu 1 Kopieren wie dd es hingegen als Primäraufgabe hat. Mit dd_rescue dauert es natürlich auch länger als mit dd, weswegen dd_rescue wirklich nur bei defekten Medien als Datenrettungsoption Sinn machen kann (es normal statt dd zu nutzen wenn das Ausgangsmedium intakt ist wäre eine ziemliche Zeitverschwendung*g*).

Da hoffe ich nun mal etwas Licht ins Dunkel gebracht zu haben über die Funktionsweisen von dd und dd_rescue ;-)
Bis denne,
Tom
 
Oben