Hallo Liste,
Ich will mein altes Bootmenue wieder haben! Irgendwie ist da jetzt alles ziemlich verschlimmbessert.
- Irgendwer meint, er müsse mir 10 verschiedene Bootoptionen da eintragen. Wie kommt der Softwareschreiber darauf, mir mein Bootmenue vollzuschreiben? Habe ich nicht gewollt, warum kriege ich so einen unbrauchbaren Unsinn?
- Die Einträge konnte man in früheren Bootmanagertagen schön editieren, rausschmeißen, was dazu tun und hat sich so sein Bootmenue zusammengezimmert. Das geht jetzt irgendwie nicht mehr, ich bin der Sklave irgendeines Programmierers geworden, der manuelle Eingriffe in seine Bootmaschine nicht mag. Wo ist der Bootmenueeditor hin, wer hat ihn geklaut?
- Die Bootmanagerinstallation endet bei mir nun mit einer vielsagenden Fehlermeldung. Die sagt nämlich gar nix außer dass ein Fehler passiert sei. Der Programmierer hat es nicht für nötig gehalten, dem Fehler ein wenig nachzugehen und was aussagekräftiges dazu abzusondern. Zum Beispiel warum wo jetzt was passiert ist. Wegen so blödsinnigen Fenstern hielt ich mal Windoof für das schlechtere Betriebssystem. Kriegen wir das jetzt auch hier? Oder muss ich damit rechnen, dass mir als Dummuser, der nur ein funktionierendes Betriebssystem braucht, jetzt pädagogisch wertvoll zugemutet werden soll, in die Innereien der Bootmanagerinstallation einzusteigen, um selber herauszufinden, warum jetzt wo welcher Fehler passiert ist?
mfg gerd
Am Mittwoch, den 14.10.2015, 20:57 +0200 schrieb Gerhard Schmidt:
Ich will mein altes Bootmenue wieder haben! Irgendwie ist da jetzt alles ziemlich verschlimmbessert.
Kann es sein, dass Du die letzten Jahre irgendwas verpasst hast?
- Irgendwer meint, er müsse mir 10 verschiedene Bootoptionen da eintragen.
Welche 10? Hast Du evtl. noch ein paar alte Kernel auf Lager?
Wie kommt der Softwareschreiber darauf, mir mein Bootmenue vollzuschreiben? Habe ich nicht gewollt, warum kriege ich so einen unbrauchbaren Unsinn?
Die Grub2-Entwickler haben dem Bootmanager die Fähigkeit gegeben nach vorhandenen Betriebsystemen (verschiedene Kernel zählen auch dazu) zu suchen. In Folge dessen wird Dir im Bootmenü alles das angezeigt, was auf Deinem System vorhanden ist. Hast Du bspw. mehrere, alte Linux-Kernel drin stehen, so deinstalliere diese einfach. Natürlich kann auch der ein oder andere Eintrag veraltet sein oder anderweitig nicht mehr stimmen. Dann hast Du die Möglichkeit via
grub-mkconfig -o /boot/grub/grub.cfg
die Bootloaderkonfiguration neu zu schreiben.
- Die Einträge konnte man in früheren Bootmanagertagen schön editieren,
rausschmeißen, was dazu tun und hat sich so sein Bootmenue zusammengezimmert. Das geht jetzt irgendwie nicht mehr, ich bin der Sklave irgendeines Programmierers geworden, der manuelle Eingriffe in seine Bootmaschine nicht mag. Wo ist der Bootmenueeditor hin, wer hat ihn geklaut?
Du suchst das Modul yast2-bootloader.
Alternativ kannst Du auch alles von Hand machen. /etc/default/grub und /etc/grub.d sind Deine Freunde. Natürlich kannst Du auch die /boot/grub/grub.cfg editieren - aber sobald der Bootloader neu geschrieben wird, bspw. bei einem Kernel-Update, gehen hier alle Deine Änderungen verloren, da die Datei neu generiert wird.
- Die Bootmanagerinstallation endet bei mir nun mit einer vielsagenden
Fehlermeldung. Die sagt nämlich gar nix außer dass ein Fehler passiert sei.
Bei welchem Vorgang ist der Fehler aufgetreten? Wie ist Deine Konstellation an vorhandenen Betriebssystemen? Also soll Linux das einzige OS sein, sind noch andere Distris installiert? Ist ein Windoof vorhanden und falls ja, in welcher Version? Welche Dateisysteme werden von Dir genutzt?
Der Programmierer hat es nicht für nötig gehalten, dem Fehler ein wenig nachzugehen und was aussagekräftiges dazu abzusondern. Zum Beispiel warum wo jetzt was passiert ist.
Zu dumm nur, dass die Leute, welche Grub entwickeln, andere sind als diejenigen, welche YaST entwickeln. So. Welchen von diesen meinst Du jetzt?
Am Donnerstag, 15. Oktober 2015, 20:10:31 schrieb Richard Kraut:
Am Mittwoch, den 14.10.2015, 20:57 +0200 schrieb Gerhard Schmidt:
Ich will mein altes Bootmenue wieder haben! Irgendwie ist da jetzt alles ziemlich verschlimmbessert.
Kann es sein, dass Du die letzten Jahre irgendwas verpasst hast?
Ja klar, habe ich definitiv. Das vorletzte Mal, dass ich Linux installiert habe, war Ende 2006, das letzte Mal März 2015. Also immer, wenn ich einen neuen Rechner kaufe. Solange die Maschine läuft, bleibt sie auch so. Mehr brauche ich nicht.
- Irgendwer meint, er müsse mir 10 verschiedene Bootoptionen da eintragen.
Welche 10? Hast Du evtl. noch ein paar alte Kernel auf Lager?
Nein, habe nur zwei Platten, auf einer ist Windoof, auf der anderen ist Suse. Auf der Suse-Platte habe ich noch ein paar uralte Backups, aber nur von /home. Im Angebot sind:
OpenSuse 13.1 dann je zwei Mal (Desktop und Wiederherstellungpunkt): 13.1 mit 3.16.7-24 13.1 mit 3.16.7-21 13.1 mit 3.16.7-13 13.1 mit 3.16.6-2 13.1 mit 3.11.10-25 13.1 mit 3.11.6-4 und dann noch: Windows 7 (loader) auf /dev/sda1 Windows 7 (loader) auf /dev/sda2
Wie kommt der Softwareschreiber darauf, mir mein Bootmenue vollzuschreiben? Habe ich nicht gewollt, warum kriege ich so einen unbrauchbaren Unsinn?
Die Grub2-Entwickler haben dem Bootmanager die Fähigkeit gegeben nach vorhandenen Betriebsystemen (verschiedene Kernel zählen auch dazu) zu suchen. In Folge dessen wird Dir im Bootmenü alles das angezeigt, was auf Deinem System vorhanden ist. Hast Du bspw. mehrere, alte Linux-Kernel drin stehen, so deinstalliere diese einfach.
Wie kommen die da hin? Habe ich nicht da hin gemacht.
Natürlich kann auch der ein oder andere Eintrag veraltet sein oder anderweitig nicht mehr stimmen. Dann hast Du die Möglichkeit via
grub-mkconfig -o /boot/grub/grub.cfg
die Bootloaderkonfiguration neu zu schreiben.
Habe ich schon gemacht, hatte in der Liste einen ähnlichen Fall gesehen und es genauso gemacht. Hat aber nix geholfen.
- Die Einträge konnte man in früheren Bootmanagertagen schön editieren,
rausschmeißen, was dazu tun und hat sich so sein Bootmenue zusammengezimmert. Das geht jetzt irgendwie nicht mehr, ich bin der Sklave irgendeines Programmierers geworden, der manuelle Eingriffe in seine Bootmaschine nicht mag. Wo ist der Bootmenueeditor hin, wer hat ihn geklaut?
Du suchst das Modul yast2-bootloader.
Das läuft doch schon im Yast. Bloss geht da nix editieren.
Alternativ kannst Du auch alles von Hand machen. /etc/default/grub und /etc/grub.d sind Deine Freunde. Natürlich kannst Du auch die /boot/grub/grub.cfg editieren - aber sobald der Bootloader neu geschrieben wird, bspw. bei einem Kernel-Update, gehen hier alle Deine Änderungen verloren, da die Datei neu generiert wird.
Möchte ich eigentlich nicht, dieses Fummeln in den Innereien. Fummele immer nur gerne an Sachen herum, die ich auch einigermaßen verstehe. Hat mir Suse so beigebracht (längere Forschungsarbeiten nach Upgrades auf neue Version).
- Die Bootmanagerinstallation endet bei mir nun mit einer vielsagenden
Fehlermeldung. Die sagt nämlich gar nix außer dass ein Fehler passiert sei.
Bei welchem Vorgang ist der Fehler aufgetreten?
Beim abschließenden Schreiben des Bootloaders mit Yast2 nach OK. Kommt so bis zu etwa 60%, dann kommt die Fehlermeldung. Gott sei Dank ist mein altes Bootmenue beim Neustart noch unverändert.
Wie ist Deine Konstellation an vorhandenen Betriebssystemen? Also soll Linux das einzige OS sein, sind noch andere Distris installiert? Ist ein Windoof vorhanden und falls ja, in welcher Version?
Siehe oben.
Welche Dateisysteme werden von Dir genutzt?
NTFS bei Windoof, Suse aus der Box.
Der Programmierer hat es nicht für nötig gehalten, dem Fehler ein wenig nachzugehen und was aussagekräftiges dazu abzusondern. Zum Beispiel warum wo jetzt was passiert ist.
Zu dumm nur, dass die Leute, welche Grub entwickeln, andere sind als diejenigen, welche YaST entwickeln. So. Welchen von diesen meinst Du jetzt?
Wie jetzt? Enden Programme heute nicht mehr klassisch, mit der Übergabe von Fehlernummern an aufrufende Programme? Und die wissen dann, was genau passiert ist. Da habe ich jetzt architekturmäßig echt was verpasst?
Soweit schon mal Danke für die Hilfe und die Tips.
mfg gerd
Am Freitag, 16. Oktober 2015, 00:51:51 schrieb Gerhard Schmidt:
Am Donnerstag, 15. Oktober 2015, 20:10:31 schrieb Richard Kraut:
Hast Du bspw. mehrere, alte Linux-Kernel drin stehen, so deinstalliere diese einfach.
Wie kommen die da hin? Habe ich nicht da hin gemacht.
Vermutlich weil zypper bei Dir so konfiguriert ist, dass es alte Kernelversionen behält. Das ist IMHO auch gut so, da Du dann einen alten Kernel starten kannst, falls Dein System nach einem Kernelupdate nicht mehr sauber bootet. AFAIK kann man mittlerweile auch konfigurieren, wie viele Kernelversionen behalten werden sollen.
Deinstallieren kannst du die Kernel mit zypper. Die folgenden Beispiele sind mit der Option "-D" (dryrun). Damit kannst Du sehen, was zypper machen würde ohne die Änderung wirklich auszuführen. Für die reale Deinstallation musst Du die Option entfernen.
Alle Deine 3.11'er Kernel deinstallieren: zypper rm -D 'kernel*<3.16.6-2' Du kannst versuchen, ob dieses funktioniert: zypper rm -D 'kernel*<3.16'
Einen bestimmten Kernel deinstallieren: zypper rm -D 'kernel*=3.11.10-25.1'
In Deinem Fall alle Kernel außer dem aktuellen deinstallieren: zypper rm -D 'kernel*<3.16' 'kernel*=3.16.7-13' 'kernel*=3.16.7-21' Alle Angaben ohne Gewähr, also erst mit -D genau sehen, was deinstalliert würde.
Am Freitag, 16. Oktober 2015, 09:35:21 schrieb Ralf Arndt:
Deinstallieren kannst du die Kernel mit zypper. Die folgenden Beispiele sind mit der Option "-D" (dryrun). Damit kannst Du sehen, was zypper machen würde ohne die Änderung wirklich auszuführen. Für die reale Deinstallation musst Du die Option entfernen.
Alle Deine 3.11'er Kernel deinstallieren: zypper rm -D 'kernel*<3.16.6-2' Du kannst versuchen, ob dieses funktioniert: zypper rm -D 'kernel*<3.16'
Einen bestimmten Kernel deinstallieren: zypper rm -D 'kernel*=3.11.10-25.1'
In Deinem Fall alle Kernel außer dem aktuellen deinstallieren: zypper rm -D 'kernel*<3.16' 'kernel*=3.16.7-13' 'kernel*=3.16.7-21'
Alle Angaben ohne Gewähr, also erst mit -D genau sehen, was deinstalliert würde.
Das ist so meine Kommunikation mit zypper:
Passwort: linux-sl50:~ # zypper -D "kernel"<3.16"kernel"=3.16.7-13' 'kernel*=3.16.7-21'
-l ^C
linux-sl50:~ # zypper -D "kernel"<3.16"
-D "kernel" ? -help --help ^C
linux-sl50:~ #
Ich schließe daraus: der will was von mir wissen, ich weiß aber nicht was. Was er von mir kriegt, mag er offenkundig nicht. Aber er ist so stumm, er redet nicht mit jedem und schon gar nicht mit mir. Ob er also mag, was ich schreibe, liegt im Dunkeln, weil er ja nix sagt.
Das mit den vielen kernels nervt eigentlich nur dann, wenn ich vom Linux aus beim Herunterfahren direkt das Windoof starten will. Dann ist die Dropdown- Liste so lang, dass der Windoof-Eintrag ganz, ganz unten schlicht abgeschnitten wird.
Endlich mal eine total hilfreiche Einrichtung, und dann wird sie durch Zumüllung unbrauchbar. Schade.
mfg gerd
Am 17. Oktober 2015 um 22:18 schrieb Gerhard Schmidt linux@dg4fac.de:
linux-sl50:~ # zypper -D "kernel"<3.16"kernel"=3.16.7-13' 'kernel*=3.16.7-21'
Lernfrage: Was bewirkt ein ungequotetes < in der Shell?
man bash, Abschnitt REDIRECTION
Aber das liegt natürlich an den Programmierern (es gibt keine ProgrammiererInnen, nicht wahr?) von zypper. NOT.
Gruß Martin
Am Samstag, 17. Oktober 2015, 22:30:00 schrieb Martin Schröder:
Am 17. Oktober 2015 um 22:18 schrieb Gerhard Schmidt linux@dg4fac.de:
linux-sl50:~ # zypper -D "kernel"<3.16"kernel"=3.16.7-13' 'kernel*=3.16.7-21'
Lernfrage: Was bewirkt ein ungequotetes < in der Shell?
man bash, Abschnitt REDIRECTION
Sorry, aber ich habe blind das gemacht, was Ralf mir so aufgeschrieben hat. Ich habe in den letzten 10 Jahren die Bash nur zum Aufrufen meines Assemblers benutzt und sie nie ernsthaft für irgendetwas anderes gebraucht. Ich habe keine Ahnung von Redirections und habe das auch noch niemals gebraucht. Ich muss das jetzt nicht wirklich lernen, oder?
Aber das liegt natürlich an den Programmierern (es gibt keine ProgrammiererInnen, nicht wahr?) von zypper. NOT.
Was soll dieser Blödsinn jetzt? Ich habe einen Rat bekommen (danke dafür an Ralf), habe das so gemacht in der Hoffnung dass es mein Problem behebt, Hat es nicht, sondern ein Neues aufgeworfen. Was NOT heißen soll, erschließt sich mir nicht, ich will es aber auch gar nicht wissen.
mfg gerd
Am 17. Oktober 2015 um 23:06 schrieb Gerhard Schmidt linux@dg4fac.de:
benutzt und sie nie ernsthaft für irgendetwas anderes gebraucht. Ich habe keine Ahnung von Redirections und habe das auch noch niemals gebraucht. Ich muss das jetzt nicht wirklich lernen, oder?
Doch. Das sind Unix-Basics. Sonst kauf Dir halt einen Apfel.
Gruß Martin
Hi Martin,
Am 17.10.2015 um 23:08 schrieb Martin Schröder:
Am 17. Oktober 2015 um 23:06 schrieb Gerhard Schmidt linux@dg4fac.de:
benutzt und sie nie ernsthaft für irgendetwas anderes gebraucht. Ich habe keine Ahnung von Redirections und habe das auch noch niemals gebraucht. Ich muss das jetzt nicht wirklich lernen, oder?
Doch. Das sind Unix-Basics. Sonst kauf Dir halt einen Apfel.
Sorry, aber Du kannst nicht jemandem vorschreiben, was und wieviel gelernt werden muss. mal abgesehen davon, dass es auch einen Lösungsweg für ihn geben mag, wofür er die Bash nicht braucht. Er muss selber wissen, wie tief er in die Materie vordringen will.
Wenn ein Hilfesuchender sich an die Liste wendet und dann mangels Bash-Kenntnissen nicht mehr als Abschreiben mit einem Bash-Kommando anzufangen weiß, ist das ihre/seine Sache.
Es gibt als auch mehrere Hilfe-Postings. Warum sollte sie/er sich dann nicht das für sie/ihn wahrscheinlich hilfreichste heraussuchen? Mein Hilfsangebot ging Gerd auch zu tief -- ist für mich OK. Da schreibe ich dann auch nicht "Doch. Das sind Bootloader-Basics. Sonst kauf Dir halt einen Apfel."
Ich kann ihm nur den guten Rat geben, sich mal eingehender mit Bootloadern und dem Startprozess zu beschäftigen, und dass er ihn wohl nicht ohne die Config-Files und ein paar GRUB2-Kommandos verstehen wird, aber er selber muss entscheiden, ob das für ihn das Richtige ist und er Zeit in das Lernen investieren will und kann.
Außerdem lesen andere auch noch mit, für die meine Zeilen vielleicht hilfreich waren. Dann würde mich das freuen. Ich muss aber nicht unbedingt davon hören.
Ciao, Tom
Am Samstag, 17. Oktober 2015, 22:18:55 schrieb Gerhard Schmidt:
Am Freitag, 16. Oktober 2015, 09:35:21 schrieb Ralf Arndt:
Deinstallieren kannst du die Kernel mit zypper. Die folgenden Beispiele sind mit der Option "-D" (dryrun). Damit kannst Du sehen, was zypper machen würde ohne die Änderung wirklich auszuführen. Für die reale Deinstallation musst Du die Option entfernen.
Alle Deine 3.11'er Kernel deinstallieren: zypper rm -D 'kernel*<3.16.6-2' Du kannst versuchen, ob dieses funktioniert: zypper rm -D 'kernel*<3.16'
Einen bestimmten Kernel deinstallieren: zypper rm -D 'kernel*=3.11.10-25.1'
In Deinem Fall alle Kernel außer dem aktuellen deinstallieren: zypper rm -D 'kernel*<3.16' 'kernel*=3.16.7-13' 'kernel*=3.16.7-21'
Alle Angaben ohne Gewähr, also erst mit -D genau sehen, was deinstalliert würde.
Das ist so meine Kommunikation mit zypper:
Passwort: linux-sl50:~ # zypper -D "kernel"<3.16"kernel"=3.16.7-13' 'kernel*=3.16.7-21'
-l ^C
linux-sl50:~ # zypper -D "kernel"<3.16"
-D "kernel" ? -help --help ^C
Vergleiche bitte Deine Eingabe mit meinem Beispiel. Du hast "rm" ausgelassen. "rm" steht für "remove". Wenn Du zypper nicht sagst, _was_ es machen soll verweist es Dich auf die Hilfe.
Am Sonntag, 18. Oktober 2015, 11:36:28 schrieb Ralf Arndt:
In Deinem Fall alle Kernel außer dem aktuellen deinstallieren: zypper rm -D 'kernel*<3.16' 'kernel*=3.16.7-13' 'kernel*=3.16.7-21'
Vergleiche bitte Deine Eingabe mit meinem Beispiel. Du hast "rm" ausgelassen. "rm" steht für "remove". Wenn Du zypper nicht sagst, _was_ es machen soll verweist es Dich auf die Hilfe.
Kaum macht man es richtig, schon geht's. Leider löscht das nicht die Einträge in der Dropdown-Liste zum Rebooten, da sind die alten Kernel immer noch drin. Die sind nach wie vor so zahlreich, dass für Windoof kein Platz mehr ist. Auch nach dem Rebooten.
mfg gerd
Am Sonntag, 18. Oktober 2015, 13:04:50 schrieb Gerhard Schmidt:
Am Sonntag, 18. Oktober 2015, 11:36:28 schrieb Ralf Arndt:
In Deinem Fall alle Kernel außer dem aktuellen deinstallieren: zypper rm -D 'kernel*<3.16' 'kernel*=3.16.7-13' 'kernel*=3.16.7-21'
Vergleiche bitte Deine Eingabe mit meinem Beispiel. Du hast "rm" ausgelassen. "rm" steht für "remove". Wenn Du zypper nicht sagst, _was_ es machen soll verweist es Dich auf die Hilfe.
Kaum macht man es richtig, schon geht's. Leider löscht das nicht die Einträge in der Dropdown-Liste zum Rebooten, da sind die alten Kernel immer noch drin. Die sind nach wie vor so zahlreich, dass für Windoof kein Platz mehr ist. Auch nach dem Rebooten.
Hast Du nach der Kontrolle den Befehl _ohne_ die Option "-D" wiederholt?
Was liefert zypper se -si kernel
Am Sonntag, 18. Oktober 2015, 13:19:12 schrieb Ralf Arndt:
Am Sonntag, 18. Oktober 2015, 13:04:50 schrieb Gerhard Schmidt:
Am Sonntag, 18. Oktober 2015, 11:36:28 schrieb Ralf Arndt:
In Deinem Fall alle Kernel außer dem aktuellen deinstallieren: zypper rm -D 'kernel*<3.16' 'kernel*=3.16.7-13' 'kernel*=3.16.7-21'
Vergleiche bitte Deine Eingabe mit meinem Beispiel. Du hast "rm" ausgelassen. "rm" steht für "remove". Wenn Du zypper nicht sagst, _was_ es machen soll verweist es Dich auf die Hilfe.
Kaum macht man es richtig, schon geht's. Leider löscht das nicht die Einträge in der Dropdown-Liste zum Rebooten, da sind die alten Kernel immer noch drin. Die sind nach wie vor so zahlreich, dass für Windoof kein Platz mehr ist. Auch nach dem Rebooten.
Hast Du nach der Kontrolle den Befehl _ohne_ die Option "-D" wiederholt?
Nein, habe ich nicht. Da er mich gefragt hat, ob ich weitermachen möchte, habe ich mir gedacht, er erledigt das schon mit der Antwort "ja".
Was liefert zypper se -si kernel
Jetzt, nach dem erneuten Ausführen.
linux-sl50:~ # zypper se -si kernel Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository --+-----------------+---------+-----------------+--------+-------------------------------- i | kernel-desktop | package | 3.16.7-13.2 | x86_64 | (System Packages) i | kernel-desktop | package | 3.16.7-24.1 | x86_64 | Hauptaktualisierungs-Repository i | kernel-desktop | package | 3.16.7-21.1 | x86_64 | Hauptaktualisierungs-Repository i | kernel-desktop | package | 3.16.7-7.1 | x86_64 | Hauptaktualisierungs-Repository i | kernel-desktop | package | 3.16.6-2.1 | x86_64 | Haupt-Repository (OSS) i | kernel-firmware | package | 20141122git-5.1 | noarch | Hauptaktualisierungs-Repository linux-sl50:~ #
Jetzt ist im Bootauswahl-Menue auch wieder Platz für den Windoof-Eintrag. Aber ich fürchte, beim nächsten Update ist es dann doch wieder weg.
Also wird es wohl mein Schicksal, dieses immer mal wieder auszuführen.
Danke einstweilen für die geduldige Hilfe,
mfg gerd
Hallo Gerhard, hallo Leute,
Am Sonntag, 18. Oktober 2015 schrieb Gerhard Schmidt: ...
Jetzt ist im Bootauswahl-Menue auch wieder Platz für den Windoof-Eintrag. Aber ich fürchte, beim nächsten Update ist es dann doch wieder weg.
Also wird es wohl mein Schicksal, dieses immer mal wieder auszuführen.
Eigentlich sollte das automatisch gemacht werden.
Was sagt systemctl status purge-kernels.service ?
Falls da statt Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled; vendor preset: enabled) "disabled" (statt "enabled") steht, mach bitte systemctl enable purge-kernels.service
Das sollte in Zukunft die alten Kernel automatisch löschen.
Welche und wie viele Kernel behalten werden sollen, steht übrigens in /etc/zypp/zypp.conf - multiversion.kernels
Gruß
Christian Boltz
Am 18.10.2015 um 17:42 schrieb Christian Boltz:
Hallo Gerhard, hallo Leute,
Am Sonntag, 18. Oktober 2015 schrieb Gerhard Schmidt: ...
Jetzt ist im Bootauswahl-Menue auch wieder Platz für den Windoof-Eintrag. Aber ich fürchte, beim nächsten Update ist es dann doch wieder weg.
Also wird es wohl mein Schicksal, dieses immer mal wieder auszuführen.
Eigentlich sollte das automatisch gemacht werden.
Das hat bei mir noch nie richtig funktioniert, vielleicht versteh ich den Mechanismus einfach nicht richtig.
Gipfel der Fehlfunktion war einmal, dass er auf plötzlich nach einem Reboot ALLE installierten Kernel gelöscht hatte. Glücklicherweise hatte ich das noch rechtzeitig mitbekommen und den aktuellen Kernel nachinstallieren können. Ist allerdings schon ein paar Jährchen her dass das passiert ist - seit dem lasse ich in der Regel die Finger von diesem Automatismus.
Fakt ist, dass es bei mir nach wie vor nicht funktioniert auf meinem Notebook mit 13.1, er löscht da einfach gar nichts.
Bei mir steht übrigens die entsprechende Einstellung in zypp.conf auf multiversion.kernels = latest,latest-1,running
Gruß Manfred
Am Sonntag, 18. Oktober 2015, 14:21:53 schrieb Gerhard Schmidt:
Jetzt ist im Bootauswahl-Menue auch wieder Platz für den Windoof-Eintrag. Aber ich fürchte, beim nächsten Update ist es dann doch wieder weg.
Also wird es wohl mein Schicksal, dieses immer mal wieder auszuführen.
Das kannst Du in /etc/zypp/zypp.conf konfigurieren:
1. Das ist vermutlich bei Dir schon konfiguriert: multiversion = provides:multiversion(kernel) Sonst würden keine alten Kernel bei einem Update erhalten.
2. Damit kannst Du konfigurieren, welche/wieviele Kernel nach einem Update erhalten bleiben: multiversion.kernels = latest,latest-1,running Dieser Eintrag ist bei Dir vermutlich noch auskommentiert. Die Kommentare über dem Eintrag beschreiben die möglichen Optionen.
Am Sonntag, 18. Oktober 2015, 18:43:18 schrieb Ralf Arndt:
Am Sonntag, 18. Oktober 2015, 14:21:53 schrieb Gerhard Schmidt:
Jetzt ist im Bootauswahl-Menue auch wieder Platz für den Windoof-Eintrag. Aber ich fürchte, beim nächsten Update ist es dann doch wieder weg.
Also wird es wohl mein Schicksal, dieses immer mal wieder auszuführen.
Das kannst Du in /etc/zypp/zypp.conf konfigurieren:
- Das ist vermutlich bei Dir schon konfiguriert:
multiversion = provides:multiversion(kernel) Sonst würden keine alten Kernel bei einem Update erhalten.
- Damit kannst Du konfigurieren, welche/wieviele Kernel nach einem Update
erhalten bleiben: multiversion.kernels = latest,latest-1,running Dieser Eintrag ist bei Dir vermutlich noch auskommentiert. Die Kommentare über dem Eintrag beschreiben die möglichen Optionen.
Nein, der Eintrag ist exakt so vorhanden und nicht auskommentiert.
mfg gerd
Am Montag, 19. Oktober 2015, 00:43:00 schrieb Gerhard Schmidt:
Am Sonntag, 18. Oktober 2015, 18:43:18 schrieb Ralf Arndt:
Am Sonntag, 18. Oktober 2015, 14:21:53 schrieb Gerhard Schmidt:
Jetzt ist im Bootauswahl-Menue auch wieder Platz für den Windoof-Eintrag. Aber ich fürchte, beim nächsten Update ist es dann doch wieder weg.
Also wird es wohl mein Schicksal, dieses immer mal wieder auszuführen.
Das kannst Du in /etc/zypp/zypp.conf konfigurieren:
- Das ist vermutlich bei Dir schon konfiguriert:
multiversion = provides:multiversion(kernel) Sonst würden keine alten Kernel bei einem Update erhalten.
- Damit kannst Du konfigurieren, welche/wieviele Kernel nach einem Update
erhalten bleiben: multiversion.kernels = latest,latest-1,running Dieser Eintrag ist bei Dir vermutlich noch auskommentiert. Die Kommentare über dem Eintrag beschreiben die möglichen Optionen.
Nein, der Eintrag ist exakt so vorhanden und nicht auskommentiert.
Auf meinem Laptop mit 12.3 funktioniert das übrigens einwandfrei: er bietet mir neben dem aktuellen nur zwei ältere Kernel an. Also muss es wohl am 13.1 hängen.
Noch eine Besonderheit auf diesem PC: hier hatte ich auch zuerst 12.3 von der DVD draufgespielt, weil ich die 13.1-DVD nicht mehr gefunden habe, und habe dann online auf 13.1 umgestellt. Vielleicht könnte es da passiert sein.
mfg gerd
Am Freitag, den 16.10.2015, 00:51 +0200 schrieb Gerhard Schmidt:
Ja klar, habe ich definitiv. Das vorletzte Mal, dass ich Linux installiert habe, war Ende 2006, das letzte Mal März 2015. Also immer, wenn ich einen neuen Rechner kaufe. Solange die Maschine läuft, bleibt sie auch so. Mehr brauche ich nicht.
Standardmäßig installiert openSUSE jetzt eben den Grub2. Den Legacy Grub aka Grub1 kannst Du aber noch selber zur Installation auswählen. Im Repo ist er auf jeden Fall noch drin.
Windows 7 (loader) auf /dev/sda1 Windows 7 (loader) auf /dev/sda2
Ich dachte Du hast nur 1x Windows installiert?
Das läuft doch schon im Yast. Bloss geht da nix editieren.
S.o. Du kannst ja mal versuchen den alten Grub nach zu ziehen. Evtl. gibt es dann auch wieder mehr Möglichkeiten im YaST-Bootloader-Modul. Sollte Dein System aber bereits ein UEFI-Bios haben, wäre ich mit Grub1 vorsichtig. Meines Wissens nach, kann mich natürlich auch irren, ist dieser mit UEFI nicht kompatibel.
Beim abschließenden Schreiben des Bootloaders mit Yast2 nach OK. Kommt so bis zu etwa 60%, dann kommt die Fehlermeldung. Gott sei Dank ist mein altes Bootmenue beim Neustart noch unverändert.
Zur eigentlichen Installation des Bootloaders Grub2 kommt der Befehl 'grub-install' zum Einsatz. Dieser ist evtl. etwas auskunftsfreudiger als YaST. Die Hilfe-Info und die Manpage vorher mal ansehen.
Wie jetzt? Enden Programme heute nicht mehr klassisch, mit der Übergabe von Fehlernummern an aufrufende Programme? Und die wissen dann, was genau passiert ist. Da habe ich jetzt architekturmäßig echt was verpasst?
Dann meinst Du doch die YaST-Entwickler. Denn diese sollten die Rückgabe entsprechend korrekt in ihrem Tool verarbeiten und sinnvoll für den Nutzer ausgeben.
Hi Gerd und Richi,
Am 16.10.2015 um 00:51 schrieb Gerhard Schmidt:
Am Donnerstag, 15. Oktober 2015, 20:10:31 schrieb Richard Kraut:
Am Mittwoch, den 14.10.2015, 20:57 +0200 schrieb Gerhard Schmidt:
[...]
Alternativ kannst Du auch alles von Hand machen. /etc/default/grub und /etc/grub.d sind Deine Freunde.
Ob man mit denen warm wird, besonders mit den Skripten, wage ich zu bezweifeln. Man wüsste aber ganz gerne, wo YaST die Einstellungen, die man in den Konfig-Menüs macht, speichert. Wenn das Klartext wäre, könnte man vielleicht draufkommen, was Schwierigkeiten macht.
Natürlich kannst Du auch die
/boot/grub/grub.cfg editieren - aber sobald der Bootloader neu geschrieben wird, bspw. bei einem Kernel-Update, gehen hier alle Deine Änderungen verloren, da die Datei neu generiert wird.
In dem Fall wäre ein Backup der grub.cfg Gerds Freund. Ich bin mir aber gar nicht sicher, ob Gerd überhaupt je ein Distri-Update machen will, wenn sie einmal läuft -- sollte er allerdings, wenigstens die zur Reparatur von Sicherheitslücken. Da kann der Kernel auch dabei sein. Dann müsste er den Eintrag des neuen Kernels in seine grub.cfg manuell übernehmen.
Möchte ich eigentlich nicht, dieses Fummeln in den Innereien.
Dann solltest Du aber die simplen Standardvorschläge des Installers akzeptieren oder nur geringfügig anpassen.
Fummele immer nur gerne an Sachen herum, die ich auch einigermaßen verstehe. Hat mir Suse so beigebracht (längere Forschungsarbeiten nach Upgrades auf neue Version).
Darin liegt der Irrtum. Wenn man die Bootloader-Konfiguration mittels YaST macht, dann versteht man nur _vermeintlich_, was man da tut. Ich halte es für eine Stärke von Linux, dass man so tief ins Innere schauen kann, wie man möchte. Nicht, dass ich falsch verstanden werde: Computer sind dazu da, möglichst viel automatisch zu erledigen, sonst käme man vor lauter Tüfteln ja nicht mehr zur produktiven Arbeit. Aber wie bei jeder Technik, die ein Werk des Menschen ist, gibt es unter manchen Bedingungen, die man nicht getestet hat, doch Fehler und somit Fragen. Und da auch Fragen menschlich ist, sollte man diesen Fragen auch selber nachgehen können und Wissen erwerben, denn: Wissen macht unabhängiger!
Aber vielleicht hast Du im Vertrauen auf die SUSE-Automatiken auch die Warnung überlesen, dass diese Maßnahme ein sehr tiefer Eingriff in ein Linux-System ist und dazu führen kann, dass das System nicht mehr startet. Im schlimmsten Fall geht es nicht einmal von einer Install-DVD (Boot from Harddisk). Ich habe gerade so einen Fall, den ich hier aber nicht vertiefen will; nur soviel: GRUB 2 landet im Rescue-Modus (Prompt: "grub rescue>"), weil er aus unerfindlichen Gründen das Dateisystem, auf dem der Kernel, die grub.cfg und die *.mod-Files gespeichert sind, nicht erkennt. Dazu vielleicht später von mir noch einen eigenen Thread.
Was habe ich oben mit "vermeintlichem" Verständnis gemeint? Wenn Du die Konfiguration im Modul yast-bootloader mit einer anhand des GRUB-Manual vergleichst, dann weißt was ich meine. Dazu brauchst Du Dir gar nicht das komplette Manual durchlesen, ein paar Befehle reichen (freilich gibt es mehrere Ebenen des Verständnisses; so könnte man auch den GRUB2-Code durchsehen oder debuggen). Im Netz der Netze findest Du neben dem GRUB2-Manual auch das eine oder andere Beispiel einer grub.cfg. Darin findest Du häufig benutzte GRUB-Befehle. Schau Dir auch ein paar Beispiele von Startproblemen an, dann verstehst Du Deines vielleicht ganz schnell. Man kann ja auch von fremden Fehlern lernen.
Mit diesen Vorbereitungen kannst Du Dir selber eine grub.cfg basteln, die Du auch verstehst -- z.B. mit folgendem Grundgerüst für einen Boot-Menü-Eintrag:
menuentry "Mein Linux" {
# Ggf. GRUB-Module einlesen; nicht benötigte auskommentieren insmod ext2 # extN-Dateisysteme lesen insmod part_msdos # Alte Partitionstabelle im MBR, oder ... insmod part_gpt # ... GUID-Partitionstabelle insmod lvm # falls Kernel auf Logical Volume gespeichert # ..., und vielleicht noch andere
# Ort der GRUB-Dateien und des/der Kernel setzen set root=(hd0,3) # Startmaschinerie von GRUB auf der ersten Platte und # dort auf der 3. Partition. Man beachte die nicht # einheitliche Nummerierung f. Geräte und Partitionen!
# Kernel der Version n.n.n laden und starten (Root-FS auf sda3): linux /boot/vmlinuz-n.n.n root=/dev/sda3 ro quiet splash
# Initrd der gleichen Version n.n.n laden initrd /boot/initrd.img-n.n.n }
menuentry "Mein Windows" { # dazu möchte ich hier nichts schreiben; dazu findet man im Web und in # der Fachliteratur etliche Beispiele }
Wenn Du die Startmaschinerie auf einem eigenen Dateisystem, also nicht auf dem Root-FS, hast, dann musst Du bei den Kommandos linux und initrd die Pfad-Teile /boot weglassen. Allerdings musst Du dann nach "set root=" andere Gerätenummern angeben, nämlich die, wo sich Dein *Boot*-Dateisystem befindet, z.B.: set root=(hd0,1). Dann könnte (hd0,2) eine Swap-Partition zwischen dem Boot- und dem Root-Dateisystem, letzteres auf (hd0,3), sein. Also nicht "root=(hdX,Y)" und "root=<Device-ID oder UUID der Root-Partition=...>" nach einem Befehl "linux" verwechseln!
Alles, was in der von den Template-Skripten erzeugten grub.cfg vor dem ersten Menüeintrag steht und vom Template /etc/grub.d/00_header stammt, kannst Du ausprobieren, was gebraucht wird und was nicht. Letzteres auskommentieren.
Dieses Vorgehen entspricht zwar nicht der Intention von openSUSE, aber Du kannst Dir so eine verhältnismäßig einfache grub.cfg schreiben und musst nicht Riesen-Shell-Skripte studieren. Wenn Du keine eigene grub.cfg willst, kannst Du eigene Menüeinträge in die Template-Datei /etc/grub.d/40_custom schreiben. Aber frag mich nicht, wie Du dann die vorherigen Menüeinträge loswirst -- vielleicht die Datei 10_linux umbenennen ohne Zahlpräfix bzw. woanders sichern und in /etc/grub.d löschen.
- Die Bootmanagerinstallation endet bei mir nun mit einer
vielsagenden Fehlermeldung. Die sagt nämlich gar nix außer dass ein Fehler passiert sei.
Bei welchem Vorgang ist der Fehler aufgetreten?
Na, irgendwann beim Erzeugen der Bootloader-Konfiguration oder beim Schreiben des Bootloaders. Aber wann genau? Wer weiß das schon, denn der openSUSE-Installer bzw. das Modul yast-bootloader nennt leider wirklich keinen Grund, sondern bietet an, die Konfiguration zu wiederholen. Aber ohne die Ursache für den Fehlschlag zu kennen, probiert man mehr oder weniger ziellos herum.
Beim abschließenden Schreiben des Bootloaders mit Yast2 nach OK. Kommt so bis zu etwa 60%, dann kommt die Fehlermeldung.
Man wüsste auch gerne, was YaST gerade getan hat, wenn es den Fehler bemerkt. Dann käme man vielleicht selber auf die Fehlerursache.
Bei mir lief es neulich dann durch, als ich die Installation in den MBR gewählt habe. Ich frage mich, warum man für GRUB2 die Installation in den Boot-Sektor einer Partition (Root-Partition & Boot-Partition, falls vorhanden) überhaupt wählen kann, wenn das im GRUB2-Manual ausdrücklich nicht empfohlen wird (habe ich auch erst danach gelesen).
Gruß, Tom
Am Samstag, 17. Oktober 2015, 13:36:01 schrieb Thomas Michalka: [...}
Das geht mir jetzt zu tief ins Eingemachte. Da mein Bootmenue beim Einschalten des Rechners wunderbar aussieht und funktioniert, ist die Alternative aus meiner Sicht jetzt: einfach das Feature "Herunterfahren vom Linux und Booten meines anderen Betriebssystems" nicht mehr zu benutzen und es künftig als schön, aber leider unbrauchbar abschreiben. Da steht jetzt der Aufwand nicht mehr dafür.
Übrigens habe ich tatsächlich zwei Windoofs: das eine richtige und das unvermeidliche Windoof-Installationssystem. Das könnte ich da auch Rausschmeißen. Wenn es denn diesen schönen und überaus praktischen Bootmenue- Editor im Yast noch gäbe. Da konnte ich mit umgehen, das habe ich mir gerade noch zugetraut.
Zu meiner Weigerung mein System auf neuere Versionen umzustellen: immer wenn ich das in den letzten Jahren gemacht habe, ist irgendwas total schief gegangen. Einmal waren alle Email-Zugänge futsch konfiguriert, weil alle Pfade und die Konfigurationsdateien geändert worden waren. Ein andermal waren alle meine Drucker verschwunden. Und die ganze andere Software, die ich so häufig benutze (fpc, tgif, konqueror wegen ftp, dvd abspielen, usw. usf.), kostet mich einen ganzen Tag, bis alles wieder korrekt funktioniert. Dann kaufe ich mir lieber alle sechs oder sieben Jahre einen neuen Rechner und spiele die zweitälteste Distribution da drauf, die funktioniert dann immer ganz gut.
Habe halt hier ganz andere Bedingungen als ein SysAdmin, der fünfzig Maschinen am Laufen halten muss.
mfg gerd
-
Christian Boltz -
Gerhard Schmidt -
Manfred Kreisl -
Martin Schröder -
Ralf Arndt -
Richard Kraut -
Thomas Michalka (MLs)