openSuSI - Booten von einer anderen Disk

[pibi]

Hallo zusammen

nachdem ich erfolgreich meinen Laptop und meine Arbeitsstation, auf der ich diese Mail schreibe, von der openSuSI 12.3 (bzw. 12..2) auf die 13.1 geupdated habe, habe ich heute einen Versuch gestartet, meinen secondary Server ebenfalls zu updaten.

Der Server (ML370) enthaelt sechs Disks, wovon zwei identisch sind. Per "dd" habe ich die aktuelle System-Disk auf die zweite kopiert und alle Eintrage im Grub1 und der korrespondierenden fstab angepasst. Leider wird aber immer noch das /usr von der urspruenglichen Disk verwendet, obwohl die fstab auf eine andere Disk zeigt.

"Frueher" ging dies problemlos. Ist etwa wieder dieser daddelige systemd dafuer verantwortlich und muss irgendwie ueberredet werden? Stichwort "mkinitrd"?

Gruss Pit.

[pibi]

Immer muss man alles selber machen;-))

So wie ich das hier (http://lizards.opensuse.org/2011/08/03/mounting-usr-in-the-initrd/) verstehe, muss ich also anscheinend die initrd neu bauen. Wie war das Leben mit sysvinit doch so angenehm und unkompliziert;-)

Gruss Pit.

[Rain_maker]

Nur hat das mit Deinem Lieblingsfeind systemd wieder einmal nichts zu tun, dieses Problem hättest Du auch mit sysvinit.

Aber auch das habe ich Dir an anderer Stelle schon einmal in nahezu epischer Breite erklärt.

http://www.linuxforen.de/forums/showthread.php?t=276012

Greetz,

RM

[pibi]

Nur hat das mit Deinem Lieblingsfeind systemd wieder einmal nichts zu tun, dieses Problem hättest Du auch mit sysvinit.Jaja, Du hast ja recht;-)

Heute abend habe ich einen Versuch gestartet, die initrd neu zu bauen. Leider bin ich gescheitert, weil die /boot/System.map nicht vorhanden war. Wie komme ich am Einfachsten an die, ohne den ganzen Make-Circle durchlaufen zu muessen? Ich verwende den Standard-Kernel, wie er aus den Repository installiert wurde. Kann ich dieses File irgendwie wieder herstellen?

Gruss Pit.

[Rain_maker]

Leider bin ich gescheitert, weil die /boot/System.map nicht vorhanden war.

Die gibt es auch nicht, nur mit Kernelversion im Namen.


ls -1 /boot/System.map*
/boot/System.map-3.11.10-10.gb897c7d-desktop
/boot/System.map-3.12.7-1.g2424219-desktop

Vorgehensweise mittels chroot sollte Dir ja mittlerweile bekannt sein, ggf. erneut fstab und Booteinträge für Grub gegenprüfen und dann muss das auch klappen.

Vielleicht geht es auch ohne chroot, aber mit chroot und dem Mounten der benötigten Partitionen ins chroot (/boot und /usr nicht vergessen!), wird die sicherste Methode sein,

Ich mache dieses Systemverschieben recht oft, da ich meine vorgefertigte Minimalinstallation auf einem (ebenfalls bootfähigen) Stick habe und das dann auf das jeweilige Zielsystem bügle und die paar notwendigen Anpassungen mache und fertig.

Das ist zwar ohne eigenes /usr aber das ist unwichtig, denn chrooten und initrd neu bauen ist trotzdem der letzte, wichtige Schritt.

[pibi]

Die gibt es auch nicht, nur mit Kernelversion im Namen.Schon klar. Das Problem war einfach, dass ich die System.map* aus Platzgruenden geloescht habe, weil meine /boot-Partition vollgelaufen war. Nun habe ich ein "zypper update" gefahren. Dabei wurde auch wieder die System.map* inkl. neuer Kernel-Version installiert. Morgen starte ich einen neuen Versuch, die initrd mit diesen Angaben neu zu bauen.

Danke einstweilen und Gruss
Pit.

[pibi]

Durch Aufrufen des "zypper update" wure eine neue gueltige System.map.... generiert. Damit konnte ich schlussendlich die initrd neu bauen. Allerdings waren ein paar Boot-Versuche noetig, bis alle Optionen korrekt gesetzt waren und das Booten sowohl mit dem alten wie auch dem neuen System via Grub problemlos funktioniert hat. Fuer Anfaenger ohne Know-How fast nicht machbar.

Gruss Pit.