Ich habe gestern per Synaptic den Kernel 3.19 und die beiden zugehörigen Header-Pakete installiert. Als ich die Kiste heute morgen booten wollte, konnte ich das LVM-Passwort nicht eingeben, es kam keine Tastatureigabe an. Zunächst habe ich versucht heraus zu bekommen, on die Tastatur funktioniert: nach einem Reset öffnete sich das grub-Auwahlmenü und ich konnte den Auswahlbalken auf und ab bewegen und das OS mit dem 3.19er auswählen. Anschließend war die Tastatur tot. Erst als ich den Vorgänger-Kernel auswählte, ließ die Maschine sich booten. Nun stellt sich die Frage, wie ich entweder den 3.19er bootfähig bekomme, oder ihn wieder runter schmeiße und wenn ja, wie.
Gast
#4243386
Synaptic bietet die Ctrl-E (Force Version) Option an. Also linux-image markieren und mit genannter Funktion auf vorherige Version setzen. Grub wird automagisch angepasst.
Gast
#4243395
Uhu U. schrieb: > oder ihn wieder runter schmeiße Ganz allgemein: Mehrere Systeme auf einer HD finden selten ein gutes Ende. Sichere jetzt, was noch zu retten ist, bevor Du weitere Experimente machst.
Gast
#4243401
oszi40 schrieb: > Uhu U. schrieb: >> oder ihn wieder runter schmeiße > > Ganz allgemein: Mehrere Systeme auf einer HD finden selten ein gutes > Ende. Sichere jetzt, was noch zu retten ist, bevor Du weitere > Experimente machst. <Maximaler Diplomatie-Modus> Kompletter Quatsch </Maximaler Diplomatie-Modus>
Gast
#4243411
> Kompletter Quatsch
Stimmt. Helden brauchen keine Backups.
Gast
#4243416
oszi40 schrieb: >> Kompletter Quatsch > > Stimmt. Helden brauchen keine Backups. Quatsch bezog sich selbstverständlich auf den ersten Teil deiner Aussage und das weisst du auch, aber du möchtest gerne trollen!
oszi40 schrieb: > Uhu U. schrieb: >> oder ihn wieder runter schmeiße > > Ganz allgemein: Mehrere Systeme auf einer HD finden selten ein gutes > Ende. Sichere jetzt, was noch zu retten ist, bevor Du weitere > Experimente machst. oszi40 schrieb: >> Kompletter Quatsch > > Stimmt. Helden brauchen keine Backups. Das hat überhaupt gar nichts mit Backup oder "mehreren Systemen auf einer Platte" zu tun. Es ist offenbar genau ein System vorhanden! Da wurde ein Kernel Update gemacht (analogie: update von windows 7/8 auf windows 10). Nach diesem Update funktioniert etwas nicht mehr und es wird gefragt wie man das behebt oder rückgängig machen kann (Downgrade von Win 10 zurück auf win 7/8). Was genau hat das jetzt bitte mit "mehreren Systemen auf einer Platte" und "experimenten" zu tun? Wenn man keine Ahnung hat... Uhu U. schrieb: > Nun stellt sich die Frage, wie ich entweder den 3.19er bootfähig > bekomme, oder ihn wieder runter schmeiße und wenn ja, wie. In die Konsole booten, da sollte dass dann mit dem Paketmanager gehen. https://wiki.debian.org/HowToUpgradeKernel
Norbert schrieb: > Also linux-image markieren und mit genannter Funktion auf vorherige > Version setzen. Das erschließt sich mir leider nicht. Kannst du es näher erklären? Hier: https://answers.launchpad.net/ubuntu/+source/synaptic/+question/201803 kommt der Frager am Schluss zu der Erkenntnis, dass Synaptic nicht auf ältere Versionen zurück setzen kann. Im Boot-Verzeichnis habe ich zwei Versionen: initrd.img-3.13.0-24-generic initrd.img-3.19.0-26-generic Ich müsste also grub dazu bewegen, den 3.19er zu ignorieren. Dann bleibt das Problem mit den Kernel-Headern.
Hi, also so ganz verstehe ich Dein Problem nicht. Wenn Du den alten Kernel booten kannst: Was hindert Dich daran, anschließend den neuen Kernel samt Headern mit Synaptic wieder herunterzuschmeißen? Gruß Andreas
Gast
#4243453
Also, wie in den Bildern gezeigt:
Gast
#4243464
Weitere Möglichkeit wenn du beide kernel behalten möchtest:
1 | |
set default="0"
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian
--class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (recovery mode)'
--class debian --class gnu-linux --class gnu --class os {
menuentry "Debian GNU/Linux, with Linux 2.6.32-5-amd64 (on /dev/sda1)"
--class gnu-linux --class gnu --class os {
menuentry "Debian GNU/Linux, with Linux 2.6.32-5-amd64 (recovery mode)
(on /dev/sda1)" --class gnu-linux --class gnu --class os {
Dann (als root):1 | |
und den Eintrag: GRUB_DEFAULT= auf den gewünschten Menüeintrag setzen: zB. GRUB_DEFAULT="Debian GNU/Linux, with Linux 2.6.32-5-amd64 (on /dev/sda1)" Dann (auch als root):
1 | |
Norbert schrieb: > Also, wie in den Bildern gezeigt: Die Option "Force Version" ist hier ausgegraut und lässt sich nicht aktivieren. Ich vermute, dass das Problem an der Verschlüsselung mit LVM hängt. Der 3.19 ist im jetzigen Zustand einfach unbrauchbar.
Angehängte Dateien:
Uhu U. schrieb: > Im Boot-Verzeichnis habe ich zwei Versionen: > initrd.img-3.13.0-24-generic > initrd.img-3.19.0-26-generic > > Ich müsste also grub dazu bewegen, den 3.19er zu ignorieren. Oder ihn halt runterwerfen. apt-get remove linux-image-3.19.0-26-generic > Dann bleibt das Problem mit den Kernel-Headern. Was für ein Problem hast du denn mit den Kernel-Headern?
Rolf M. schrieb: > Was für ein Problem hast du denn mit den Kernel-Headern? Die für den neuen Kernel passen natürlich nicht für den alten und wenn ich irgend ein Paket generieren will, das die Kernel-Header braucht, dann gehts schief - oder sehe ich das falsch?
Mittlerweile habe ich den Kernel und die Header einfach per Synaptic gelöscht. Es bootet wieder der alte Kernel, ohne dass irgendwelche zusätzlichen Eingaben notwendig wären. Ob es mit den Headern irgendwo haken wird, wird sich zeigen...
Uhu U. schrieb: > Die für den neuen Kernel passen natürlich nicht für den alten und wenn > ich irgend ein Paket generieren will, das die Kernel-Header braucht, > dann gehts schief - oder sehe ich das falsch? Für was brauchst du die denn, außer zum bauen von Kernelmodulen außerhalb des Kernels?
Rolf M. schrieb: > Für was brauchst du die denn, außer zum bauen von Kernelmodulen > außerhalb des Kernels? Gegenfrage: Warum sind sie bei Updates immer dabei?
Weil Du sie mal installiert hast. ;-) Rolf: Davon abgesehen: Kernelmodule werden z.B. von VM Box gebaut. Es gibt schon Gründe, die Header zu installieren auch wenn man keine Kernel selbst baut. Du kannst Dir doch die Header passend zum Kernel installieren und die nicht benötigten Header wieder deinstallieren. Wo ist das Problem? Ich habe gerade auch mal den 3.19.0-22 Kernel auf Mint 17 installiert. Lustigerweise bootet mein PC dann auch nicht mehr (kein LM). Also wieder runtergeworfen. Ich vermute mal, es liegt nicht am Kernel selbst, sondern an der .deb die Grub nicht korrekt konfiguriert, da der Kernel laut log noch nicht einmal anfängt zu booten. Habe aber momentan keine Zeit das herauszufinden. Gruß Andreas
Andreas B. schrieb: > Weil Du sie mal installiert hast. ;-) > > Rolf: > Davon abgesehen: Kernelmodule werden z.B. von VM Box gebaut. Ja. > Es gibt schon Gründe, die Header zu installieren auch wenn man keine Kernel > selbst baut. Wenn man den Kernel selber bauen will, bringen einem die Header auch gar nix. Da braucht man eh die ganzen Kernel-Sourcen, die ihre Header ja selbst mitbringen. > Ich habe gerade auch mal den 3.19.0-22 Kernel auf Mint 17 installiert. > Lustigerweise bootet mein PC dann auch nicht mehr (kein LM). Also wieder > runtergeworfen. Auf meinem Kubuntu-PC läuft gerade ein 3.19.0-23, der keine Probleme macht. Ich habe auch schon den -26 installiert, aber seither noch nicht neu gebootet. > Ich vermute mal, es liegt nicht am Kernel selbst, sondern an der .deb die > Grub nicht korrekt konfiguriert, da der Kernel laut log noch nicht einmal > anfängt zu booten. Kam bei der Installation denn eine Fehlermeldung?
Ich benutze zwar kein *buntu sondern Arch, aber ich habe mit dem 3.15er Kernel angefangen und jeden Kernel mitgenommen (auch aus dem Testing-Repo) und hatte nie probleme. Bin jetzt beim 4.1.5er. Schaut mal hier: http://ubuntuhandbook.org/index.php/2015/03/upgrade-kernel-3-19-3-ubuntulinux-mint/
1 | |
2 | |
Habt ihr das gemacht?