Schau mal ins BIOS, wie die Boot-Reihenfolge der Laufwerke ist. Eventuell liegt dein Grub ja auf der SSD.
[gelöst] yaVDR ansible - veralteter Kernel trotz Update ...
-
-
Im BIOS bei der Bootreihenfolge scheint die SSD gar nicht auf! (siehe auch #13)Da war (und ist) immer eingestellt: ATAPI, USB dann (die einzig auswählbare) HDD.Meine Mädls sind vom Schwimmen zurück und der VDR geht nicht - HILFE!Sorry, Fehlalarm - die SSD IST im BIOS auswählbar und wenn ich von der boote, kommt wieder das altbekannte GRUB-Menü, wo ich unter "Ubuntu 18 erweitert" die Versionen 51 und 45 auswählen kann. (Lustigerweise kam das auch immer bevor ich die SSD ab- und wieder angesteckt habe, obwohl die HDD im BIOS immer schon als Bootplatte eingestellt war.)
Wenigstens läuft yaVDR-ansible wieder und die Mädls können ihre Sendungen schauen
D.h. mein Bootloader (GRUB) liegt auf der SSD und trotzdem boote ich seit jeher ins Ubuntu 18 der HDD?!
Kannst du mir bitte bei den "gröberen Umbauten" helfen?
Edit:
Ich denke, ich müsste den Bootloader, der jetzt offenbar auf der SSD liegt, irgendwie auf die HDD bekommen. Dann kann ich im Notfall immer noch von der HDD unseren alten yaVDR 0.6 und die derzeit verwendete yaVDR-ansible booten (die beiden werden ja im GRUB-Menü angeboten).
Und dann müsste ich auf der SSD komplett neu in die root-Partition installieren und dabei einen komplett neuen Bootloader für diese Neu-Installation auf die SSD schreiben lassen.
Stimmt das so?
Und da könnte man dann GRUB so adaptieren, dass auch von der HDD gebootet werden könnte, ohne, dass ich die im BIOS die Bootplatte ändern muss?Und wo sind die Stolpersteine bzw. wie kriege ich den jetzigen Bootloader (mit funktionierendem Ubuntu 14/VDR 2.2 und 18/VDR 2.4) auf die HDD gesichert?
-
Was sagt sudo debconf-show grub-pc auf der yaVDR 0.6 Installation?
Ich würde dann mal versuchen sudo dpkg-reconfigure grub-pc auszuführen (bei den Abfragen für die Kernel-Argumente kann man den aktuellen Stand beibehalten) und dafür sorgen, dass der Bootloader auf der HDD (vermutlich /dev/sda) installiert wird. Dann noch mal im WFE den Timeout für Grub setzen und Speichern.
Bootet er dann mit dem Grub-Auswahlmenü von der HDD (SSD ggf. mal testweise abstecken)?
-
Wenn ich dich richtig verstehe, geht es jetzt mal darum, den jetzigen Stand auf der HDD zu erhalten und so herzurichten, dass ich von der HDD alleine nach Ubuntu 14 und 18 booten kann - so wie jetzt, aber ohne Bootloader von der SSD.
Ich werde später mal yaVDR 0.6 booten; inzwischen mal die Ausgabe unter Ubuntu 18:
Code
Alles anzeigengrub2/no_efi_extra_removable: false grub-pc/install_devices_empty: false grub2/unsigned_kernels_title: grub2/kfreebsd_cmdline_default: quiet splash grub-pc/partition_description: grub2/device_map_regenerated: grub2/linux_cmdline: grub-pc/install_devices_failed_upgrade: true grub-pc/hidden_timeout: false grub-pc/postrm_purge_boot_grub: false grub-pc/install_devices_disks_changed: grub-pc/timeout: 10 * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1048353 grub-pc/mixed_legacy_and_grub2: true grub-pc/disk_description: grub2/linux_cmdline_default: grub-pc/chainload_from_menu.lst: true grub2/unsigned_kernels: grub2/kfreebsd_cmdline: grub2/update_nvram: true grub-pc/kopt_extracted: false grub-pc/install_devices_failed: false
Da steht seltsamerweise auch schon die 3-TB-Festplatte (WD30EFRX) drin und nicht die SSD.
Und die Sache mit "dpkg-reconfigure grub-pc" dann schon unter Ubuntu 18 ausführen, aber auf Festplatte (SDA) schreiben, oder?Wollte den Befehl eigentlich nur ausprobieren, um zu sehen, welche Möglichkeiten ich da habe, aber da war nichts mit Testlauf.
War wohl (wieder mal) zu voreilig
Code
Alles anzeigeni386-pc wird für Ihre Plattform installiert. grub-install: Warnung: Diese GPT-Partitionsbezeichnung hat keine BIOS-Boot-Partition, Einbettung würde unmöglich sein. grub-install: Warnung: Einbettung ist nicht möglich. GRUB kann in dieser Konfiguration nur mittels Blocklisten installiert werden. Blocklisten sind allerdings UNZUVERLÄSSIG und deren Verwendung wird daher nicht empfohlen.. Installation beendet. Keine Fehler aufgetreten. Sourcing file `/etc/default/grub' GRUB-Konfigurationsdatei wird erstellt … Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-58-generic initrd-Abbild gefunden: /boot/initrd.img-4.15.0-58-generic Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-55-generic initrd-Abbild gefunden: /boot/initrd.img-4.15.0-55-generic Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-54-generic initrd-Abbild gefunden: /boot/initrd.img-4.15.0-54-generic Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-52-generic initrd-Abbild gefunden: /boot/initrd.img-4.15.0-52-generic Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-51-generic initrd-Abbild gefunden: /boot/initrd.img-4.15.0-51-generic Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-45-generic initrd-Abbild gefunden: /boot/initrd.img-4.15.0-45-generic Ubuntu 14.04.5 LTS (14.04) auf /dev/sda5 gefunden Ubuntu 14.04.6 LTS (14.04) auf /dev/sdb1 gefunden erledigt
Beim Auswahldialog habe ich "die Festplatte" (sda1) angekreuzt gelassen .
Die Warnungen beunruhigen mich - gut ist hingegen, dass jetzt offenbar die aktuellsten Kernelversionen auch gefunden wurden.
Die Ausgabe von "sudo debconf-show grub-pc" sieht jetzt - trotz offenbar willkürlicher Reihenfolge - leicht anders aus (... disks_changed ... linux_cmdline_default ...):
Code
Alles anzeigengrub-pc/install_devices_empty: false grub2/update_nvram: true grub2/device_map_regenerated: grub-pc/install_devices_disks_changed: * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1048353 * grub2/linux_cmdline_default: quiet splash grub-pc/disk_description: grub2/kfreebsd_cmdline_default: quiet splash grub2/kfreebsd_cmdline: grub-pc/hidden_timeout: false grub2/unsigned_kernels_title: grub-pc/chainload_from_menu.lst: true grub2/unsigned_kernels: grub-pc/install_devices_failed_upgrade: true * grub2/linux_cmdline: grub-pc/timeout: 10 grub2/no_efi_extra_removable: false grub-pc/install_devices_failed: false grub-pc/postrm_purge_boot_grub: false grub-pc/kopt_extracted: false grub-pc/partition_description: grub-pc/mixed_legacy_and_grub2: true
Ich werde später versuchen, die SSD abzuhängen und nur von der HDD zu booten - müsste ja theoretisch klappen.
Oder habe ichs jetzt schon wieder vergeigt? Traue mich fast gar nicht zu rebooten.
-
Hast du schon mal versucht deine SSD Installation auf /dev/sdb via Supergrub zu booten und dann grub-install /dev/sda von da aus aufzurufen?
-
Hast du schon mal versucht deine SSD Installation auf /dev/sdb via Supergrub zu booten und dann grub-install /dev/sda von da aus aufzurufen?
Nein, das habe ich noch nicht probiert. Was ist "Supergrub" und was würde das bewirken?
Aber bevor ich mit der SSD weitermache, möchte ich den jetzigen Stand (der ja offenbar auf der HDD liegt) "sichern".
Ich konnte zwischenzeitlich - via F11 - von der Festplatte booten und es kommt wieder kein Grub-Menü, sondern Ubuntu 14 wird sofort gestartet.
Code
Alles anzeigengrub-pc/hidden_timeout: false grub-pc/postrm_purge_boot_grub: false grub2/device_map_regenerated: grub-pc/mixed_legacy_and_grub2: true grub-pc/chainload_from_menu.lst: true grub-pc/timeout: 10 grub-pc/partition_description: grub2/linux_cmdline: grub2/linux_cmdline_default: vmalloc=256m quiet splash noresume nohz=off acpi_enforce_resources=lax grub2/kfreebsd_cmdline: grub-pc/install_devices_empty: false * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1048353 grub-pc/install_devices_disks_changed: grub-pc/kopt_extracted: false grub-pc/install_devices_failed: false grub-pc/disk_description: grub2/kfreebsd_cmdline_default: quiet splash grub-pc/install_devices_failed_upgrade: true
Werde jetzt nochmal prüfen, ob Ubuntu 18 noch "normal" funktioniert, wenn ich wieder von SSD (BIOS) booten lasse.
-
Hi,
wenn du von der HDD startest und dann yavdr0.6 läuft, kannst du im Webinterface die Wartezeit vom Grub-Menü erhöhen (default ist da 0 Minuten). Dann sollte beim nächsten Start auch ein Grub-Menü zu sehen sein.
Gruß Thomas
-
wenn du von der HDD startest und dann yavdr0.6 läuft, kannst du im Webinterface die Wartezeit vom Grub-Menü erhöhen (default ist da 0 Minuten). Dann sollte beim nächsten Start auch ein Grub-Menü zu sehen sein.
Werd ich beim nächsten Reboot nach yaVDR 0.6 übers Webinterface ausprobieren. Obwohl in der grub-Datei schon ein "timeout" von "10" angegeben ist und auch wenn ich die Shift-Taste drücke oder gedrückt halte, erscheint kein Grub-Menü.
Der Start über die SSD funktioniert nach wie vor.
Noch jemand eine Idee, wie ich den Bootloader/Grub von der SSD auf die Festplatte bekomme?
Kann ich nicht "einfach" den fehlenden Eintrag von der grub-Datei der SSD kopieren und auf der HDD in die grub-Datei zusätzlich manuell eintragen und danach sudo update-grub ausführen? -
Nein, das habe ich noch nicht probiert. Was ist "Supergrub" und was würde das bewirken?
Aber bevor ich mit der SSD weitermache, möchte ich den jetzigen Stand (der ja offenbar auf der HDD liegt) "sichern".
Supergrub ist ein Program, dass du auf einen USB Stick packst und dann damit Partitionen/Systeme booten kannst, wenn du sonst nicht mehr drankommst.
Siehe: https://www.supergrubdisk.org/…/super-grub2-disk-stable/
-
Hallo,
du kannst auch von dem Installationsstick booten, von dem du Ubuntu 18.04 installierst hat. Dort wählst du beim Start den Rescue-Mode aus und wechselst in die Konsole von /dev/sdb1 (sollte die ansible-Partition sein).
Dort führst du
aus, das installiert Grub in den MBR der ersten HDD. Dann machst du noch ein
und beim nächsten booten solltest du alle Kernel auf allen Partitionen sehen können. Das alles unter der Voraussetzung, das du 18.04 klassisch als MBR-Installation gemacht hast.
Megal
-
Ich habe jetzt in yaVDR 0.6 gebootet und im Webif das Timeout (von 4) auf 10 gestellt und gespeichert.
Ändert aber leider gar nichts am Verhalten: wenn ich von HDD boote, kommt kein Grub-Menü sondern sofort "Ubuntu 14".
Kann das an der Zeile GRUB_DEFAULT=saved in der /etc/default/grub (unter yaVDR 0.6 auf der HDD) liegen?
Danke für die Erklärung flyingrobi ! Supergrub werde ich mir bei Gelegenheit anschauen - vorerst möchte ich aber noch mit Bordmitteln weiterkommen ...
Das alles unter der Voraussetzung, das du 18.04 klassisch als MBR-Installation gemacht hast.
Hmmmm ... glaube eher, dass auf der SSD eine (U)EFI-Installation ist (HDD war eher klassisch MBR) und bevor ich jetzt noch mehr zerschieße ...
Wie kann ich denn zuverlässig herausfinden, welche Installation ich gemacht habe?
Edit:
Habe von der CD gebootet und im Rettungsmodus /dev/sdb1 als Root genommen und dann in die Konsole gewechselt.
Dort wurde grub-install /dev/sda leider so beantwortet:
CodeInstalling for i386-pc platform. grub-install: Warnung: Diese GPT-Partitionsbezeichnung hat keine BIOS-Boot-Partition, Einbettung würde unmöglich sein. grub-install: Fehler: Einbettung ist nicht möglich, jedoch für die Installation auf mehreren Laufwerken erforderlich.
Soll das jetzt heißen, dass sdb (SSD) eine GPT-Partition ist und keine BIOS-Boot-Partition hat oder sda (HDD)?
Und wie kann ich jetzt im Mischbetrieb (offenbar mit EFI und BIOS), grub von der SSD auf die Festplatte schreiben?
-
Das sieht nach UEFI aus (GPT-Datenträger). Deshalb findet der Grub auf HDD 1 auch keine Partition auf der SSD.
Eine Neuinstallation von Ubuntu 18.04 auf der SSD wäre das einfachste, dabei aber darauf achten, klassisch MBR zu installieren, damit du die 14.04 Installation auch mit benutzen kannst.
-
Wenn du deine jetzige ansible-Installation behalten willst, könntest du das Dateisystem z.B. mit fsarchiver sichern, die SSD mit einer MBR-Partitionstabelle versehen, eine ext4-Partition anlegen und die Sicherung dorthin einspielen. Dann nochmal das Prozedere mit install-grub machen. Sollte schneller gehen als eine Neuinstallation.
-
Hmmm ... es gibt also aktuell keine Möglichkeit, die Festplatte so herzurichten, dass ich von ihr (ohne SSD) ins jetzige Ubuntu 18 starten kann?
(Und zur Not auch noch nach yaVDR 0.6 bzw. yaVDR 0.5, die beide auf der Festplatte liegen müssten).
Dann hätte ich die Platte zur Not als "Backup" und könnte auf der SSD machen, was ich will.
Die Neu-Installation auf der SSD habe ich sowieso vor, aber eben erst, wenn sichergestellt ist, dass die Festplatte mit dem aktuellen Status (und yaVDR 0.6) stabil alleine läuft.
Im Endstadium möchte ich dahin kommen, dass
- yaVDR-ansible (nach Neu-Installation) auf der SSD läuft (lieber GPT) mit der /srv-Partition von der HDD (MBR)
- automatisch von der SSD gebootet wird, aber ich ggf. im Bootmenü (F11) auch von der HDD (yaVDR 0.6 bzw. "ansible-alt") booten kann
Hat vielleicht noch jemand eine Idee, wie ich Grub von der GPT-SSD auf die MBR-HDD bekomme?
-
Auf dieser Seite https://wiki.ubuntuusers.de/EFI_Modus_umstellen/ steht u.a. folgendes:
Zitat
... ein Mischbetrieb aus EFI-Modus mit BIOS-Modus wird von GRUB 2 nicht unterstützt! ...Auf der Seite findest du vielleicht etwas, was die helfen könnte.
-
Sieht, bis auf den bösen Satz, den du schon zitiert hast, so aus als könnte ich die SSD nachträglich auf BIOS-Mode umstellen, um dann den Bootloader/Grub doch noch von der SSD auf die HDD zu installieren.
Aber das muss doch einfacher bzw. risikoärmer gehen!
Mal angenommen, ich hätte nur die HDD mit yaVDR 0.6, 0.5 und Ansible drauf. Die muss man doch auch ohne grub von der SSD irgendwie zum Laufen bringen können, oder? Irgendwie muss ich doch die fürs Booten notwendigen Einstellungen (die ich ja von SSD "abschreiben" könnte) auf die HDD bekommen und sie damit alleine lauffähig zu machen - war ja vor meiner verhunzten SSD-Einbauaktion auch so.
-
Das Problem ist, das eine Platte einen MBR und die andere eine GPT hat. Grub unterstützt beide, allerdings nicht gleichzeitig auf einem System, der will entweder MBR oder GPT. Man könnte natürlich auch versuchen, die HDD 1 auf UEFI umstellen (vorher unbedingt ein Backup aller Partitionen machen).
-
Also technisch ist das so nicht richtig, man kann sehr wohl per Master Boot Record von einer SSD/HDD mit GPT starten, das schließt sich nicht aus.
Eine ganze Zeit in der Vergangenheit war das sogar nötig, Windows bzw. auch andere konnten noch nicht wirklich UEFI, aber die Platten bzw. Partitionen waren schon zu groß für MBR Partitionstabellen ... UEFI Boot erwartet hingegen zwingenderweise eine SSD/HDD mit GPT und natürlich die kleine FAT32 Hilfspartition (#EF00) für das EFI Helferlein.
Das größere Problem ist, das es sich bei grub und grub-efi um zwei grundsätzlich unterscheidliche "Installationsarten" handelt, die prinzipbedingt nicht nebeneinander existieren können/dürfen, obwohl eigentlich aus dem gleichen Stall.
automatisch von der SSD gebootet wird, aber ich ggf. im Bootmenü (F11) auch von der HDD (yaVDR 0.6 bzw. "ansible-alt") booten kann
Obwohl es viele Verfechter und Freunde gibt, ist dieses parallel booten per Bios oder Bootmanager-Auswahl nie problemfrei oder elegant gewesen, noch wird es das je werden. Mental zeugt das m.E. nur von geringer Entscheidungsfreude, man kann sich nicht immer alles im Leben offen halten bzw. muss das eben g'scheit lösen. In Deinem Fall eben mit zwei Geräten oder mit dem harten physikalischen Austausch der Boot-Medien nach Bedarf in einem Gerät.
Du kannst schon von beiden Platten in einem Gerät per BIOS Boot-Auswahl starten, musst dann halt immer erst UEFI de-aktivieren im BIOS Setup um von der MBR HDD booten zu können.
Aber mal ehrlich wie oft machst Du das? Und eigentlich willst Du doch auch nur ein VDR Gerät haben, auf das Du Dich verlassen kannst. Da würde ich doch auch als letztes im grub menu irgendwie zwei unterscheidliche Installationen mischen wolllen. Einen 10er drauf, damit sehen wir Dich bald wieder mit einem neuen Thread hier ...
Regards
fnu
-
Oder einfach sowas:
https://www.amazon.de/dp/B007X5F4ZQ
Ich denke, ich hätte schon lange mit einer frischen Platte sauber neu installiert und die alte als Backup weggelegt...
-
Ihr seid echt witzig, Jungs! Natürlich möchte ich komplett neu auf der SSD installieren, aber erst wenn sichergestellt ist, dass die HDD alleine lauffähig ist und meine 3 Mädls weiterhin TV schauen können, während ich auf der SSD herumbastle.
Erfahrungsgemäß brauche ich dafür immer einige Tage bis alles wieder rund läuft und wenn die mal 1 Tag nicht fernsehen können, bricht der 3. Weltkrieg aus
Wenn ich komplett fertig bin und der "neue" mal ca. 3 Monate problemlos läuft, möchte ich sowieso alles bis auf /srv von der Festplatte löschen.
Du kannst schon von beiden Platten in einem Gerät per BIOS Boot-Auswahl starten, musst dann halt immer erst UEFI de-aktivieren im BIOS Setup um von der MBR HDD booten zu können.
Hmmm ... ich habe im BIOS noch nie UEFI deaktiviert, wenn ich von der HDD (Ubuntu 14) gebootet habe. Kann das der Grund sein, warum kein GRUB-Menü angezeigt wird?
Oder einfach sowas:
Dockingstation hätte ich übrigens zu hause (darüber mache ich die Backups meines Windows-Rechners). Kann aber gerade nicht erkennen, was mir das dafür bringen soll.
Falls es wirklich unmöglich sein sollte, die HDD eigenständig mit drei möglichen Bootoptionen (yaVDR 0.5, 0.6 und Ansible) zum Laufen zu bringen, muss ich es eh riskieren und - wie von Seahawk beschrieben - komplett neu auf der SSD installieren. Und ja, dann werde ich sicherlich VORHER hier fragen, bevor ich mir wieder was für die Zukunft verbaue.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!