Hallo Werner, 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. Gestern hatte ich das kleine Problem, dass die Platte, von der ich später booten wollte, als /dev/sdb im System bekannt war. Beim Schreiben des grub in den MBR wird dann (hd1) verwendet. Aber für das Booten muss man darauf achten, dass in der menu.lst für alle Systeme auf dieser Platte "(hd0,x)" (ich habe mehrere OSs in Multiboot-Konfiguration) steht. 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." 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? 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 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 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. Gruß, Tom -- 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