/dev/sdb1 und /dev/sda1 = gleiche Partition
Hallo zusammen, ich habe es auf meinem System geschafft, dass /dev/sdb1 und /dev/sda1 die gleiche Partition ist. Inzwischen habe ich die Fehler zwar gefunden und behoben, so dass nun es wieder so ist wie es sein soll, aber im Nachhinein würde ich doch gerne Wissen wie es dazu kommen kann, dass Zwei verschiedene Devices zum gleichen Filesystem führen. /deb/sda1 = h0,0 = ata-ST3320620NS_5QF1Z1HL-part1 /dev/sdb1 = h1,0 = ata-SAMSUNG_HD103UJ_S13PJ1MQ715347-part1 Als der Fehler noch bestand sah in der mount tab zwar alles schön unterschiedlich aus: root@obelix (-bash) mount /dev/sdb1 on / type ext4 (rw,acl,user_xattr) <<== /dev/sdb2 on /export/disk2p2 type ext3 (rw) /dev/sda2 on /home type ext3 (rw) /dev/sda1 on /export/disk1p1 type ext4 (rw) <<== /dev/sda3 on /export/disk1p3 type ext3 (rw) jedoch Änderungen in /boot/grub/menu.lst wirken sich sofort auf das File /export/disk1p1/boot/grub/menu.lst aus. /boot/grub/menu.lst: title Hauptsystem 64Bit -- openSUSE 11.3 root (hd0,0) kernel /boot/vmlinuz root=/dev/disk/by-id/ata-ST3320620NS_5QF1Z1HL-part1 resume=/dev/disk/by-id/ata-ST3320620NS_5QF1Z1HL-part4 splash=silent quiet showopts vga=0x31a initrd /boot/initrd device.map #/dev/sdb1 /dev/sda1 (fd0) /dev/fd0 (fd0) /dev/fd0 (hd0) /dev/sda (hd0) /dev/sda (hd1) /dev/sdb (hd1) /dev/sdb /etc/fstab: /dev/disk/by-id/ata-SAMSUNG_HD103UJ_S13PJ1MQ715347-part1 / ext4 acl,user_xattr 1 1 /dev/disk/by-id/ata-ST3320620NS_5QF1Z1HL-part1 /export/disk1p1 ext4 defaults 1 2 Wenn man die obigen Dateien genau ansieht, habe ich beim Booten von /dev/sda1 gebootet (root=/dev/disk/by-id/ata-ST33206...) aber in der fstab dann /dev/sdb1 (ata-SAMSUNG...) nach / gemountet. Nur wie kommt die Gleichheit von /dev/sda1 und /dev/sdb1 zustande ? Danke für Erhellendes Werner Franke
Hallo, Am Tue, 25 Jan 2011, Werner Franke schrieb:
Inzwischen habe ich die Fehler zwar gefunden und behoben, so dass nun es wieder so ist wie es sein soll, aber im Nachhinein würde ich doch gerne Wissen wie es dazu kommen kann, dass Zwei verschiedene Devices zum gleichen Filesystem führen.
/deb/sda1 = h0,0 = ata-ST3320620NS_5QF1Z1HL-part1 /dev/sdb1 = h1,0 = ata-SAMSUNG_HD103UJ_S13PJ1MQ715347-part1
Zeig mal die Ausgabe von (eine Zeile): $ ls -l /dev/sd[ab]* \ /dev/disk/by-id/ata-ST3320620NS_5QF1Z1HL* \ /dev/disk/by-id/ata-SAMSUNG_HD103UJ_S13PJ1MQ715347* Wenn da was durcheinander kommt ... Am besten zeig mal per PM(!) von beiden obiges, die device.map, die menu.lst, die /etc/grub.conf und die fstab, jew. passende benamst nach dem System/der Platte auf denen sie liegen. Und welcher Grub im MBR ist. Ich kann ggfs. in meiner Antwort hier dann (ggfs. passend zensiert) zitieren. BTW: ist da evtl. ein grub2 im Spiel? -dnh -- "Jedesmal, wenn ich denke, ich bin ganz unten angelangt, kommt jemand und leiht mir eine Schaufel." -- Savion Glover -- 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
Hallo, Am 27.01.2011 03:31, schrieb David Haller:
Hallo,
Am Tue, 25 Jan 2011, Werner Franke schrieb:
Inzwischen habe ich die Fehler zwar gefunden und behoben, so dass nun es wieder so ist wie es sein soll, aber im Nachhinein würde ich doch gerne Wissen wie es dazu kommen kann, dass Zwei verschiedene Devices zum gleichen Filesystem führen.
/deb/sda1 = h0,0 = ata-ST3320620NS_5QF1Z1HL-part1 /dev/sdb1 = h1,0 = ata-SAMSUNG_HD103UJ_S13PJ1MQ715347-part1
Zeig mal die Ausgabe von (eine Zeile):
$ ls -l /dev/sd[ab]* \ /dev/disk/by-id/ata-ST3320620NS_5QF1Z1HL* \ /dev/disk/by-id/ata-SAMSUNG_HD103UJ_S13PJ1MQ715347*
Wenn da was durcheinander kommt ...
Am besten zeig mal per PM(!) von beiden obiges, die device.map, die menu.lst, die /etc/grub.conf und die fstab, jew. passende benamst nach dem System/der Platte auf denen sie liegen. Und welcher Grub im MBR ist. Ich kann ggfs. in meiner Antwort hier dann (ggfs. passend zensiert) zitieren.
Zusammenfassung nach ausführlichem Talk mit David Haller: Also im Nachhinein herauszufinden, was der genaue Grund ist, ist schwierig. Es bleibt eine Spekulation. Es dürfte ein Zusammenwirken von mehreren Punkten sein: - beim Booten wurde das Grub Menü von /dev/sdb1 (statt von /dev/sda1) gelesen, weil ich wahrscheinlich als /dev/sdb1 nach / gemountet war, den Grub von /dev/sdb1 mit YAST in den MBR geschrieben habe. Erwartet hatte ich aber dass er den Grub von /dev/sda1 liesst. - Im Menü (von /dev/sdb1) war beim Kernel der falsche root= Parameter enthalten war: root=/dev/sda1 sollte: root=/dev/sdb1 Falls das mal jemand anderes passieren sollte, so sollten folgende Dateien *genau* geprüft werden: - /boot/grub/menu.lst: passen root (h0,0) und root=/dev/sdaX zusammen - /boot/grub/device.map: passt "(h0) /dev/sda" zur obigen Zeile - /etc/grub.conf Wird der Grub auch wirklich in den MBR oder in die Root Partition geschrieben. setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0) # MBR setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,1) # Root P. Wie sieht es bei der anderen Partition (/dev/sdb1) aus. Da darf nicht das gleiche drinstehen. - /etc/fstab und letztlich muss de das Root Filesystem auch zu obigen Daten passen. Wenn ich dem Kernel "root=/dev/sda1" mitgebe, dann sollte auch in der fstab /dev/sda1 / ext4 defaults 1 1 enthalten sein. 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. Gruss Werner -
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
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
Am So, 06 Feb 2011 19:29:25 CET schrieb David Haller: Hallo David,
Ich verwende übrigens für die OS-und-boot Platte immer /dev/sda (bei SATA kann man die Kabel ja leicht umstecken,
Ich auch, aber E-Sata pfuscht dazwischen, das wird hier immer zu sda, wenn ich was anstecke. Al -- 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
Hallo Al, Am 06.02.2011 22:45, schrieb Al Bogner:
Ich auch, aber E-Sata pfuscht dazwischen, das wird hier immer zu sda, wenn ich was anstecke.
Ist der E-SATA-Anschluss 'on Board' oder über einen Adapter nach draußen geführt? Ich hab bei meinem Rechner die zweite Lösung und kann durch die Wahl des SATA-Anschlusses, an dem ich den E-SATA-Adapter auf dem Board anstecke, die Zuordnung regeln. Und dann gibt es im BIOS noch die Funktion, die Bootreihenfolge der angeschlossenen Platten festzulegen, also ob von SATA1, SATA2 etc gebootet werden soll. Evtl kannst du so bestimmen, dass E-SATA nicht automatisch zu sda1 wird. HTH -- Mit freundlichen Grüßen Detlef Wiese -- 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
participants (5)
-
Al Bogner
-
David Haller
-
Detlef Wiese
-
Thomas Michalka
-
Werner Franke