Auf zwei alten Headless-/Tastaturlos-Systemen lief Ubuntu-Server 16.04LTS (Alpha und Beta);
Der Zugriff erfolgt für beide Maschinen ausschließlich per SSH.
Das Alpha-System wurde offenbar während einer Aktualisierung beschädigt.
Booten per CD/DVD/UEFI ist keine Option. USB ist im Kernel aufgrund von Inkompatibilitäten deaktiviert, die dazu führen, dass die CPU mit 100 % auslastet.
Das Laufwerk von Alpha mit dem nicht bootfähigen System wird jetzt als zweites Laufwerk im System von Beta gemountet.
Alle Benutzerdateien wurden auf Betas Laufwerk gesichert.
Wie installiere ich einen Ubuntu-Server auf der zweiten (Alpha-)Festplatte der Beta, sodass die zweite Festplatte als primäres bootfähiges Laufwerk im Alpha-System neu installiert werden kann?
freundliche Grüße, Ben
Aktualisierung 25.01.2017:
debootstrap und diese URL (https://help.ubuntu.com/lts/installation-guide/i386/apds04.html) überwinden Sie die meisten Hürden des Prozesses, indem Sie Alphas Antrieb wie folgt zu Beta hinzufügen:
Alphas Laufwerk ist in Betas System unter /dev/hdb installiert. Betas Laufwerk ist /dev/hda.
Verbleibende Hürde:
Wie bringt man grub-install/grub-probe/grub-mkconfig dazu, /dev/hda zu ignorieren, wenn nach einem bootfähigen Kernel auf /dev/hdb gesucht wird?
Nachdem ich das Alpha-Laufwerk aus dem Alpha-System entfernt und neu gestartet habe, bootet das System nicht. Es gibt keine offensichtlichen Fehlerprotokolle auf dem Alpha-Laufwerk (nach Neuinstallation/Einbindung in Beta). Nach einigen Zyklen habe ich Folgendes gefunden:
Grub-Probe von grub-install erkennt den Kernel von Beta und verknüpft die UUIDs von diesem (/dev/hda) anstelle der von Alpha installierten unter /dev/hdb
-- obwohl der Benutzer gemäß den Anweisungen unter help.ubuntu.com/lts/installation-guide/i386/apds04.html in das Laufwerk von Alpha (/dev/sdb) chrootet ist
Mir gehen die Ideen aus, wie ich die Parameter grub-install/grub-probe/grub-mkconfig aufrufen kann, um /dev/hda zu ignorieren.
Vorerst werde ich die Grub-Datei mit den falsch referenzierten HD-UUIDs manuell bearbeiten: grub.cfg, wenn ich mich recht entsinne. Sagen Sie mir Bescheid, wenn es dafür eine standardmäßige, weniger riskante Methode gibt.