Hallo, Am Fri, 04 Feb 2011, Thomas Michalka schrieb:
Werner Franke schrieb:
Unübersichtlich wird es, wenn nicht wie hier nur mit /dev/sda1 sondern auch mit /dev/disk/by-id/ata-ST3320620NS_5QF1Z1HL-part1 gearbeitet wird. Da wird eine Unstimmigkeit leicht übersehen. Deswegen möglichst immer durchgehend mit einem Typ Label / UUIDs / by-id / by-path arbeiten.
Ich habe mich an diese Geräte-IDs (by-id) inzwischen so gewöhnt, dass ich es gut fände, wenn der grub die Geräte-IDs lesen und verwenden könnte. Dann gäb's nämlich keine Missverständnisse mehr, ob man irgendwo (hd0) bzw. (hd0,x) oder (hd1) bzw. (hd1,x) eintragen muss.
Schreib's einfach passend in die /boot/grub/device.map, also z.B.: (hd0) /dev/disk/by-id/ata-{HERSTELLER1}_{MODELL1}_{SERIENNR1} (hd1) /dev/disk/by-id/ata-{HERSTELLER2}_{MODELL2}_{SERIENNR2}
Eine andere Sache in dem Zusammenhang verstehe ich nicht: ich musste den MBR mit grub wiederherstellen, aber das wollte mit der chroot-Methode aus dem oS-Rettungssystem nicht gelingen:
$> mount /dev/sdb9 /mnt $> mount -t proc none /mnt/proc $> mount -o bind /dev/ /mnt/dev $> chroot /mnt # bin jetzt in dem startbar zu machenden System $> mount /dev/sdb5 /misc $> grub-install.unsupported --recheck --root-directory=/misc /dev/sdb
Die grub files und menu.lst für den MBR stehen in einer eigenen Minipartition unter /misc/boot/grub, die unter /misc gemountet wird. In der Ausgabe stand immer die Fehlermeldung (sinngemäß): "File stage1 not read correctly."
Wieso mountest du sdb5 nicht unter /boot? Oder zumindest /misc/boot unter /boot (mount -o bind /misc/boot /boot). Ausserdem muß wenn du so "schlicht" grub-install verwendest auch die /etc/grub.conf passen! Vermutlich lag's auch bei dir daran (bei Werner stand da auch was anderes drin als er dachte).
Kann das daran liegen, dass es in der chroot-Umgebung die zweite Platte nicht mehr gibt und hier /dev/sdb zu /dev/sda (Ausgabe von mount) geworden ist? fdisk -l gibt weiterhin beiden Platten mit der alten Zuordnung /dev/sda (120.0 GB) und /dev/sdb (500.0 GB) aus. Das muss man dann wohl für dieses Vorhaben ignorieren, oder?
Du mußt halt gucken, ob /dev/sda usw. auch passen, ansonsten eben in /dev/disk/ gucken, was sinnvoller verwendbar ist. Ich verwende übrigens für die OS-und-boot Platte immer /dev/sda (bei SATA kann man die Kabel ja leicht umstecken, mit den PATA Kabeln war's doch einiges schwieriger, v.a. auch von der Länge). Und alle anderen Platten bzw. Partitionen werden per Label eingebunden. Das hat sich übrigens erst vor kurzem beim letzten Umzug bewährt, ich mußte nix an fstab, grub.conf, menu.lst usw. ändern (da ich so partitioniert hatte, daß die /-Partition die gleiche Nummer (sda6) bekam wie zuvor), sondern einfach die neue Platte einbauen, partitionieren, formatieren, Daten von der alten per rsync drauf, mount /proc, /sys, /dev, chroot, grub-install, runterfahren, Kabel zw. alter und neuer Platte umstöpseln, booten, mit rsync noch die seit dem ersten rsync neuen Daten von der alten Platte auf die neue holen, et voila, da überall in fstab, menu.lst usw. eben /dev/sda6 drin steht ... IIRC hab ich die Vorbereitung der neuen Platte noch nichtmal mit nem Festeinbau (hier eh per Schiene) sondern in nem USB/eSATA "QuickDeck" erledigt in das die Platte einfach reingeschoben wird. D.h. bei mir entfiel dann sogar einmal neu booten um die Platte einzubauen.
Mit der System Rescue CD 1.6.0 konnte ich den MBR wiederherstellen, aber ohne chroot, denn ich wollte bewusst die grub files der Rettungsdistri und auf keinen Fall irgendwelche von oS stammende Dateien verwenden:
$> mount /dev/sdf5 /misc $> grub-install --root-directory=/misc /dev/sdf
Nix gut. Denn so sucht grub dann vermutlich auf dem falschen Device, denn je nachdem in welcher Reihenfolge die Module für die Controller geladen werden, werden eben /dev/sdX unterschiedlich. Wenn man z.B. von USB bootet wird die USB-Platte vom BIOS auch umhergeschoben, was also z.B. normal unter Linux als /dev/sdk auftaucht ist beim von von der externen Platte auf einmal /dev/sdg. SUSE hat nun AFAIK ahci fest im Kernel, d.h. Platten an Controllern im AHCI Mode sollten zu erst drankommen, die anderen danach. Bei deiner CD ist ahci evtl. nicht fest drin, und schwuppdiwupp tauschen die Controller die Plätze.
War seltsamerweise sdf, obwohl nur zwei physische Platten drin sind. Hat aber gut funktioniert. In der device.map stand halt drin: (fd0) /dev/fd0 (hd0) /dev/sde (hd1) /dev/sdf
s.o. Die device.map passt vermutlich nicht, wenn du von Platte bootest.
Wohl deshalb gelang mir eine MBR-Wiederherstellung auch nicht mit der Super Grub Disk, weil die anscheinend auch die grub files der installierten Distri verwenden will. Eine Überprüfung der Installation des grub-Packets mit rpm --verify ergab keinen Fehler. Seltsam ist das ganze für mich besonders, weil die Erstinstallation von oS 11.0 seinerzeit ja auch mit diesem Grub geklappt hat.
s.o. Da gab's keinen Konflikt wg. unterschiedlicher Controllerreihenfolge. HTH, -dnh -- An application/evil MIME type is defined for Web- or email-carried mischief. Other MIME types can be embedded inside of evil sections; this permit easy encoding of word processing documents with macro viruses, etc. -- RfC 3514 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org