Hej,Frieder108,
...
nano /etc/apt/sources.list
das sollte wohl /etc/fstab heißen, oder?
Gruß black tenkate
Anmeldungsdatum: Beiträge: 10958 |
Hej,Frieder108,
das sollte wohl /etc/fstab heißen, oder? Gruß black tenkate |
Anmeldungsdatum: Beiträge: 8989 |
upps, ja natürlich - Danke 👍 nano /etc/fstab ist selbstverfreilich richtig ☺ |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1093 |
Hat jetzt mit der Chroot-Methode funktioniert. Hier https://de.wikipedia.org/wiki/Grand_Unified_Bootloader#GRUB_2 ist sehr gut beschrieben was wohin gespeichert wird. In den MBR kommt eine boot.img, die core.img in den versteckten Bereich. Damit Grub auf die /etc/grub/grub.cfg überhaupt zugreifen kann braucht es Module um das Dateisystem überhaupt lesen zu können:
In dem Wikpedia-Link steht als 3. Schritt /boot/grub. In der bisherigen Single-Boot-Umgebung war das sda1. Und jetzt? Da ich zuletzt die Chroot-Methode für das Xubuntu angewendet habe wird vermulich im 3. Schritt /boot/grub auf sda2 aufgerufen. Das heißt im Schluss, dass ich mittels der Chroot-Methode sowohl Anpassungen im Ordner /boot/grub als auch an der core.img im verborgenen Bereich vorgenommen habe, da ja sonst weiterhin /boot/grub in sda1 aufgerufen würde. Die richtigen Bootmenü-Einträge stehen demnach nur in der grub.cfg auf sda2, in der grub.cfg auf sda1 (dem Kubuntu) stehen die alten. Richtig? Ich will das jetzt ungern einfach so probieren ohne zu wissen ob was passiert: Würde ich vom Kubuntu aus nochmal 'update-grub' ausführen, müsste er auch die anderen OS auf den jetzt wieder angeschlossenen OS finden und diese in die grub.cfg auf sda1 eintragen. Da aber als 3. Schritt Daten von sda2 geladen werden dürfte das keinen Einfluss auf das Bootmenü haben? So etwas hatte ich mal auf meinem Notebook und ich konnte es mir nie erklären. |
Anmeldungsdatum: Beiträge: 8989 |
warst du zwischenzeitlich in dem nicht startenden Xubuntu via Chroot drin und hast dort das update-grub ausgeführt? und falls ja, warum hast du uns die Ausgabe nicht gezeigt? Das wäre so neben der neuen Und was das Kubuntu anbelangt, ich dachte, du willst das löschen und das nicht startende Xubuntu zum Hauptsystem zu machen - hab ich das falsch verstanden? |
Anmeldungsdatum: Beiträge: 10958 |
Hej Fried-rich, OT
ach was, das funktioniert auch komplett ohne, jedenfalls bei den zig Installationen eines /OT Gruß black tencate |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1093 |
Irgendwann soll es mal gelöscht werden, aber aktuell noch nicht. Xubuntu hat noch zuviele Problemchen - die hatte Kubuntu auch, aber andere 🙄 Chroot wurde ausgeführt und es bootet jetzt. Daher hab ich nichts gepostet. Ich würde nur gern verstehen was da passiert. Abweichend von dem was black_tencate geschrieben hat ist mein Stand der, dass Grub im 2. Schritt (nach boot.img im MBR) core.img im verboregenen Bereich lädt und sich darin Module befinden die für den Zugriff auf eine Partition nötig sind. Selbst wenn keine zusätzliche Software geladen werden muss, muss hier hinterlegt sein wo /boot/grub liegt. Muss ja nichts zwangsweise sda1 sein. Daher vermute ich ändert die Chroot-Methode nicht nur die grub.cfg sondern auch den "Grub-Teil" im verborgenen Bereich. Ist das so richtig? Demnach wäre die "Grub-Arbeitsschritte" in meinem Fall: MBR (boot.img) → verborgener Bereich (core.img) → /boot/grub auf sda2 (der Partition mit Xubuntu). Wenn ich mit die grub.cfg auf der Xubuntu-Partition und die grub.cfg auf der Kubuntu-Partition ansehe sieht es genau so aus: auf der Xubuntu-Partition hab ich das aktuelle Boot-Menü (ich habe hier per grub-costumizer die Einträge umsortiert und umbenannt) und in der auf der Kubuntu-Partition die bisherigen Einträge. Frage: Kann man sich dieser "Verweis" zwischen Schritt 2 und 3 irgendwie anzeigen lassen, wenn man eine unbekannte Systemkonfiguration hat? Irgendwo muss es ja stehen. In einer vom Bootinfoscript erstellen Textdatei steht das hier: Grub2 (v1.99) is installed in the MBR of /dev/sde and looks at sector 1 of the same hard drive for core.img. core.img is at this location and looks in partition 97 for . (sdae ist jetzt da alle HDDs wieder angeschlossen sind die SSD mit Kubuntu und Xubuntu). Haargenau den gleichen Text hab ich aber auch bei meiner anderen SSD und einer HDD auf der vor ewigen Zeit mal ein inzwischen wieder gelöschtes Linux installiert war. Überall steht "partition 97". |
Anmeldungsdatum: Beiträge: 15929 |
Hallo Fried-rich, Wer benutzt so was: grub-costumizer ........Probleme leider vorprogrammiert. Gruss Lidux |
Anmeldungsdatum: Beiträge: 10958 |
Hej Fried-rich,
So so, und warum stehen dann die verschiedenen Module im Verzeichnis /boot/grub? Ein 'nacktes' grub-Menü funktioniert ohne diese Module, darfst Du mir ruhig glauben. Erst, wenn Du z.B. ein Hintergrundbild laden möchtest, ist das nicht mehr im core.img enthalten (insmod jpeg) und muß zur Laufzeit hinzugeladen werden. Ebenso eine andere Auflösung.
da liegst Du richtig. Aber mal ein Hinweis: grub mit MBR ist ein Auslaufmodell, beschäftige Dich lieber mit EFI. Gruß black tencate |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1093 |
Ist es möglich auszulesen "wohin" Grub nach dem laden der core.img springt? Das wäre manchmal schon interessant zu wissen. |
Anmeldungsdatum: Beiträge: 8989 |
Hast du das "update-grub" im nichtstartenden Xubuntu gemacht? Solange die UUID in Und damit die sudo update-grub ##hier mit sudo
machen → das bringt dich aber auch erst dann weiter, wenn im Xubuntu endlich die |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1093 |
@ Frieder108 Mein System startet ja, das ist nicht das Problem. Das Chroot-Methode unter dem Xubuntu war die Lösung, hatte ich aber ein paar Beiträge weiter oben und vor ein paar Tagen schon geschrieben. Die UUID stimmen auch. Ich möchte aber gerne verstehen was passiert und wieso es geklappt hat. Man wird ja vermutlich wieder mal in die Situation kommen. Daher nochmal meine letzte Frage:
|
Anmeldungsdatum: Beiträge: 8989 |
ach so - dann beachte doch bitte die Forenregeln und markier doch den Thread bitte als "gelöst", dann muss man nicht mehr weiter über Lösungen nachdenken. Für deine Frage nach Grub 2 findest du unter dem Link bestimmt eine Lösung - Grub wird gesteuert durch |
Anmeldungsdatum: Beiträge: 10958 |
Hej Fried-rich,
naja, springt hättest Du schon auch noch in Gänsefüßchen setzen sollen *scnr*.
Gruß black tencate |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1093 |
Ja, der Text im BootInfoScript lautet jetzt so:
Was auch immer "." sein soll wonach er sucht. Und Partition 97? 😲 Ich hab auch mal auf einer Festplatte einen Test gemacht. Hier 2 Partitionen erstellt, danach mein Kubuntu und mein Xubuntu per rsync reinkopiert. Dann in beiden fstab die UUIDs geändert und dann für beide Systeme mit Chroot Grub eingerichtet. Interessanterwiese bootete Kubuntu danach problemlos (aber genauso langsam wie auf meiner SSD), Xubuntu aber nicht. Ein Blick in die betreffende grub.cfg (unter Kubuntu) zeigte, dass hier noch die alte UUID eingetragen war. Wieso diese beim Kubuntu geändert wurde und beim Xubuntu nicht erschließt sich mir nicht. Den Artikel seh ich mir mal an. @ lionlizard Da jetzt grds. erstmal mein System läuft kann ich mich an die Feinarbeit machen. Du hast mal geschrieben:
Was heißt das? Ich kenne das nur in Verbindung mit verschlüsselten Systemen - was ich aber nicht habe. Auch hatte ich manchmal schon einen Eingabeprompt "Initramfs", wenn beim booten etwas nicht funktionierte. |
Anmeldungsdatum: Beiträge: 15929 |
Hallo Fried-rich, Dann hast du jeweils für beide Systeme einen Grub2 installiert, d.h. einen in sda und den zweiten in die / Partition des Systems. Somit wird erst der eine Bootloder geladen und nach Auswahl der nächste mit den entsprechenden Verzögerungen. Gruss Lidux |