Wenn ihr findet, dass es sinvoller waere koennt ihr hier zustimmen:
https://features.opensuse.org/310665
nein ich find das nicht sinnvoll. für was soll das gut sein? bei hunderten von clients den alten kernel per hand rauspflücken. schönen dank auch.
übrigens kann man auch abstimmen wenn man es für totalen quatsch hält.
Ne, das meinte ich auch nicht. Ich habe mich schon wieder falsch ausgedrueckt. Es geht weder darum, Kernels per Hand zu entfernen, noch alle Kernels zu behalten (wie bei Fedora, Ubuntu oder Mandriva der Fall ist ) - das geht auch einfach und waere keine neue Feature - sondern nur den letzten oder vorletzen - das Wort hat mir schon gefehlt - nicht wegzuschmeissen so, dass es nach einem boesen Patch - wie letzlich mit dem usb Autosuspend oder dem ATI Bug - immer die Moeglichkeit gibt, den Kernel davor zu verwenden. Mehr nicht … wenn ich das richtig verstanden habe.
Hier ist der Thread : Keeping the current kernel when doing a kernel update through yast. Den Titel hier kann ich nicht editieren. Es sollte eigentlich “den aktuellen Kernel” heissen … oder sowas.
achso naja da wäre ich dafür, grundsätzlich die politik zu fahren, dass man auf den servern dass drauflässt was da ist, und nicht aus platzgründen oder weiß der teufel wrum alle “veralteten” pakete wieder herunterschmeißt. Solche unfälle dass pakete fehlerhaft sind, kommen öfter vor.
ich bastel gerade ein script, dass eine funktionierende konfiguration samt der pakete sichern soll.
l1zard wrote:
>
> achso naja da wäre ich dafür, grundsätzlich die politik zu fahren, dass
> man auf den servern dass drauflässt was da ist, und nicht aus
> platzgründen oder weiß der teufel wrum alle “veralteten” pakete wieder
> herunterschmeißt. Solche unfälle dass pakete fehlerhaft sind, kommen
> öfter vor.
>
> ich bastel gerade ein script, dass eine funktionierende konfiguration
> samt der pakete sichern soll.
>
>
Dumme Frage, hilft es dir da nicht, wenn du einfach bei den Einstellungen
für die Software-Repositories den Haken für “Heruntergeladene Pakete nicht
löschen” setzt?
noe hilft mir nicht, weil ja dann alle heruntergeladenen Pakete in /var/lib/zypp herumgammeln auch die, die momentan gar nicht installiert sind. ausserdem soll das script, wenn es einmal fertig ist ein backup wieder einspielen, die unterschiede zwsichen verschiedenen revisionen anzeigen usw. vielleicht hacke ich mir auch was in python oder c. mal sehen 
Ich habe auch mal dagegen gestimmt.
Wer das unbedingt will, kann es ja immer noch tun (zypp.conf) und vor allem man erspart der openSUSE-Community solche Threads hier (zufälligerweise sogar noch “ganz frisch”):
[gelöst] 2.ubuntu hat sich selbst installiert? - Linux: Linux-Forum](http://www.linux-forum.de/gel-st-2-ubuntu-hat-sich-selbst-installiert-1491468.html)
Das passt dann (vor allem auch wegen des durchschnittlichen Wissens von $ZIELGRUPPE) viel besser zu der Distro, um die es im verlinkten Thread geht.
Dann doch lieber “Hilfäääää schwarzer Bildschirm, Suse funzt nimmaaa!111elf”, weil der User statt seine fglrx/nvidia Pakete aus den Repos zu nehmen auf gute, alte Stümper^WHandarbeit gesetzt hat.
Was ist da so schlimm - standardweise- zwei Kernel statt nur einen zu haben?
Gibt’s da einen Grund so ne ********* zu reden!?
es ist ein sicherheitsrisiko! wir haben hier ca 100 clients mit opensuse 113 und nutzer die nicht so unbedarft sind. wenn ein exploit für einen kernel bekannt wird, will ich einfach nicht das der alte kernel genutzt werden kann, um evtl rootrechte zu erlangen und ausserdem will ich das nicht überall per hand rausflücken müssen.
Sonst gehts Dir aber noch gut?
Was ist daran so schlimm, Umgangsformen zu haben?
Nur weil nicht jeder Deiner Meinung ist, musst Du nicht gleich ein trotziges Kind reagieren, dem man seine Sandburg kaputt gehauen hat.
Auch wenn der Beitrag mit dem Link etwas scherzhaft formuliert war, das Grundproblem mit zig Threads “Was ist denn jetzt los, Hilfe, zwei Kernel, was ist kaputt?” wird auftauchen, das sieht man auch daran, daß der verlinkte Thread nur eines von vielen Beispielen ist (zugegebenermassen ein drastisches, aber da es gerade so frisch war, musste ich es einfach verlinken), wenn man mal ein wenig sucht, findet man so etwas massenweise bei Debian und seinen Derivaten in den entsprechenden Foren.
Eines löst ein alter Kernel nämlich auch nicht, wer von Hand an Kernel rumgebastelt hat (und genau diese Probleme machen >95% der “Probleme mit Kernelupdate”-Threads aus), der hat vielleicht noch “was zum Booten” (hat er in den meisten Fällen auch ohne dieses Backup, siehe die 95% oben), das Modul für den neuen Kernel kann er damit aber auch nicht bauen, wenn das Makefile (und das machen viele) /lib/modules/$(uname -r)/build verwendet, mit dem neuen Kernel kann er dieses Problem jedoch einfacher lösen, er wird ihn also booten müssen (OK, es sei denn, er kann das entsprechende Makefile modifizieren oder kennt sich mit make gut genug aus).
Noch viel witziger wird es z.B. bei der PUEL-Version von VirtualBox, sofern man als sinnvolle Option (für die es auch ausgerichtet ist) dkms mitverwendet, da fliegen dann zuerst die alten Module raus und die neuen können nicht automatisch gebaut werden, wenn der alte Kernel läuft, da nun ein /etc/init.d/vboxdrv setup versucht die -vorher gelöschten- Module für den alten Kernel zu bauen (wieder “uname -r”, dumm gelaufen) und keine Quellen/Header mehr für diesen nach einem regulären Online-Update vorhanden sind (die wurden schliesslich auch auf die neue Version gebracht).
Was wird dann bei solchen unangenehmen aber eindeutig lösbaren Problemen wohl passieren?
Man bootet nur noch den alten Kernel, weil der funktioniert ja noch und eventuelle Sicherheitsprobleme bleiben bestehen.
Was man also vielleicht zunächst an Sicherheit zu gewinnen scheint, hat so das eine oder andere Pferdefüßchen in petto, deshalb von mir NAK.
Viel sinnvoller wäre es, wenn mehr User die Kernel vor dem offiziellen Update über das entsprechende update-test Repo testen würden, also statt hier andere User anzupupen kannst Du ja darüber mal nachdenken.
Aber da ich mir auch schon denken kann, was diese Idee inspiriert haben könnte noch eine kleine Bemerkung zum Schluss.
Diesen “pöhsen ATI-Bug” beim letzten Update haben sich nur die User eingehandelt, die NICHT die offiziellen Pakete aus dem ATI-Repo sondern “Handarbeit” installiert hatten, die Pakete im ATI-Repo waren schon direkt zum Update in neuer Version und entsprechend gepatcht verfügbar.
Und ab nun wird von allen Seiten sachlich weiter diskutiert ok? 
Sofern noch Zwiegespräche nötig sind, macht den Rest bitte per PM.
Danke.
Wo wir gerade bei Pferdefüßen sind, da wäre noch einer (Schuhgröße 45 oder größer).
Welches ist der offizielle Weg den Kernel um externe Module zu erweitern?
Richtig, KMP-Pakete, sollen die auch alle doppelt installiert werden?
Wohlgemerkt, dazu muss man dem System (zypper/libzypp in dem Fall) aber dann auch sagen, wie es das machen soll, entweder mit Wildcards oder es muss sich diese bei jedem Update rauspicken (kann sich ja seit dem letzten Update etwas an den installierten kmp-Paketen geändert haben) und ebenfalls “aufheben”.
Nur “letzter Kernel soll erhalten bleiben” ist also nicht, wenn schon, denn schon.
Falls nicht, hat man sonst sehr schnell die Situation, daß entweder alte kmp-Pakete nicht zum neuen Kernel passen (ABI-Änderung) oder neue kmp-Pakete nicht für den alten Kernel verfügbar sind (für ein Update ohne ABI-Änderung sind kmp-Pakete geeignet, aber nicht für ein Downgrade, macht auch keinen Sinn) und dann hat man zwei Kernel und kann sich aussuchen, WAS auf dem jeweiligen Kandidat gerade nicht läuft, weil das Paketsystem durch dieses ganze “Hamstern” komplett durcheinander gebracht wurde.
Man würde dadurch also -OHNE Bug im neuen Kernel- riskieren, daß ein bewährtes System -für das es übrigens in puncto “weak-updates” bei keiner mir bekannten Distro ein auch nur annähernd vergleichbares Feature gibt- auf einmal nicht mehr funktioniert.
Immer noch der Meinung, daß das per se eine gute Idee ist und viele Dinge einfacher für die User macht?
Eines steht nämlich auch fest (siehe Ubuntu), je mehr man versucht etwas “Idiotensicher” zu machen, desto idiotischer muss man teilweise seine Konzepte umbiegen und dadurch für andere, weitaus kritischere Anwendungsfälle, neue Probleme hervorzaubern (siehe die angesprochene Sicherheitsproblematik).
Und abschließend noch eine “nicht-technische” Anmerkung:
Nur weil z.B. Ubuntu das so macht, damit auch der unbedarfteste User noch seinen alten Kernel (und dessen Sicherheitsprobleme) hat, muss eine Distribution, die eben nicht per se für “jeden Deppen” gedacht ist und auch für andere Bereiche eine gute Lösung anbieten will (wo man eben nicht will, daß auch “jeder Depp” den alten, unsicheren Kernel booten kann), es genau so machen.
Sonst wird man nämlich bald “jeden Depp” als Nutzer haben, auch hier siehe Ubuntu oder in noch viel größerem Maße Windows, diesen “Erfolg” gönne ich den genannten ehrlicherweise auch von ganzem Herzen.
Ich bin dagegen. Hab schon einige Posts gemacht in den englischen Foren, wie einfach man durch Anwendung einer LiveCD ein installiertes System übernehmen kan. In kurzem, Annahme ist das “/” auf /dev/sda1 ist:
Starten von LiveCD/USBdisk
Terminal öffnen, dann:
su (kein Passwort nötig)
mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
chroot /mnt
mount /proc
mount /sys
yast
Jetzt läuft Yast wie vom installierten System. Repos, alles ist da, also auch die Möglichkeit Kernels um zu wechselen. Hat mich bei Kernels von de HEAD: repo schon einigen Mahlen gerettet . Nach den Änderungen einen Reboot, und Robert ist dein Onkel.
wenn man unbedingt den alten kernel behalten will kann man ja mal folgendes vor einem update versuceh:
Hallo Welt, hallo openSUSEs!
Hm.
Also eine einigermaßen einfache Lösung, um einen neuen Kernel zu testen, inklusive eines schnellen Fallbacks, wenn ein neuer (Test-)Kernel nicht funktioniert, fände ich schon schön. Bislang habe ich einfach drei Kernel-Flavors installiert und zunächst jeweils nur einen ausprobiert, aber für das Optimum an “Usability” halte ich das nicht gerade. Und zuletzt als die Repositorys gerade beim Kernel-Update durcheinander geraten waren, hat mir dies auch nur bedingt geholfen.
Und meiner Meinung nach dürfte ein Test einer neuen Kernel Version besonders aussagekräftig sein, wenn er auch tatsächlich auf einem benutzen System stattfindet. Und dann möchte ich auch noch während des Tests bei Problemen erst einmal weiter arbeiten oder zumindest weiter surfen können, bevor ich eine Reparatur mit einer Live-CD machen muss. Anderen Benutzern mag es ähnlich gehen.
Ein automatischer Hinweis wie: “veraltet” an dem Eintrag der zum Booten einer alten Linux-Kernel-Version führt müsste auch für die Mitglieder der Randbereiche zum DAU (D***ster Anzunehmender User) nach einem regulären Kernel-Update reichen, um diese Benutzer auf mögliche Risiken beim Benutzen alter Kernels hinzuweisen.
Und so lange es keine funktionierenden (halb-)automatischen Updates ohne root-Passwort gibt, ist halte ich openSUSE eh nicht geeignet für Benutzer, die sich von vielen Einträgen im Auswahl-Menü von GRUB verwirren ließen. Leuten, die nur wollen, das Ihr System funktioniert, und sich nicht für Computertechnik interessieren, würde ich da eher zu Ubuntu oder zu einer Version mit bezahltem Support wieSUSE Linux Enterprise Desktop von Novell (SLED) raten. Da würde ich die Ausfallsicherheit der anderen Benutzer doch eher über das Unwohlsein der (durch 2 Einträge mehr) verwirrten Benutzer stellen.
Und gibt es tatsächlich so oft Aktualisierungen/Updates des Kernels, die sicherheitsrelevant sind? Ich dachte das, was zuletzt passierte (Patch für eine Sicherheitslücke, die schon länger bekannt war, aber sich aus Versehen wieder eingeschlichen hatte), wäre eher eine Ausnahme gewesen.
Nur meine persönliche unmaßgebliche Meinung, lasse mich gerne vom Gegenteil überzeugen.
Beste Grüße
pistazienfresser
Ein automatischer Hinweis wie: “veraltet” an dem Eintrag der zum Booten einer alten Linux-Kernel-Version führt müsste auch für die Mitglieder der Randbereiche zum DAU (D***ster Anzunehmender User) nach einem regulären Kernel-Update reichen, um diese Benutzer auf mögliche Risiken beim Benutzen alter Kernels hinzuweisen.
Naja, erfahrungsgemäß ist solchen Nutzern ziemlich egal, ob damit linux’sche Sicherheitsprinzipien unterlaufen werden. Hauptsache, die Kiste rennt irgendwie und man muss sich nicht bemühen, Probleme tatsächlich anzugehen (“Ist doch Linux, was soll da schon groß passieren?”).
Ich fand die hier vorgebrachten Argumente von Akoellh und Knurpht ziemlich überzeugend und habe deshalb dagegen gestimmt. Wer Panik hat, dass mit einem Kernel-update das System zerschossen wird, soll sich halt regelmäßig backups ziehen, auf die er im vermeintlichen Notfall zurückgreifen kann.
Ihr solltet aber bedenken, was man unter ‘standardmaessig’ versteht. Wenn nach einem Kernel Update, der aktuelle Kernel - so unsicher mag er auch gewesen sein - nicht systematisch geloescht wird, ist es fuer den Endbenutzer eher eine gute Sache. Dem Systemadministrator ist es auch egal, denn er weiss wie und wo er das Standardverhalten aendern kann … und er tut es sowieso.
Keine Sorge, genau DARUM geht es in meinen Ausführungen.
Du denkst “standardmässig macht man es den Usern, die nicht wissen, was sie tun, einfacher, wenn man den alten Kernel behält”, genau anders herum wird ein Schuh draus.
Nur wer weiß, was er tut, kann wirklich von diesem Feature profitieren, egal ob ein Kernelupdate “buggy” ist oder nicht (die “”, weil der letzte, große “Bug” beim Update für 11.3 eben keiner war, sondern ein Problem, welches sich der User selbst ins Nest legen musste), geht ein Kernelupdate den gewohnten Gang und die Kiste startet mit dem neuen Kern, dann holt man sich -wie ich mit einigen Beispielen, die mir auf die Schnelle einfielen, da findet sich sicher noch mehr- sehr viele neue, potentielle Probleme ins Boot, denn so “einfach” wie Du Dir das denkst, ist es eben bei weitem nicht.
Da die Risiken den Nutzen nicht nur zahlenmässig übersteigen, ist es eben eine nette Idee mit vielen Haken, meiner Meinung nach sind die Haken deutlich schwerwiegender als die Vorteile (oder soll ich sagen “der Vorteil”, denn bis auf den einen genannten sehe ich keinen).
Ich meine, standardmaessig, koennte man den Usern zumindest erlauben nach einem Sicherheitspatch neu booten zu koennen ohne, dass die Maus oder Tastatur klemmt (2.6.34.4-0.1) oder ein witchiger Kernel-Modul (z.B. fglrx) partout nicht kompiliert (2.6.34.7-0.2), und wenn shon fuer zwei Stunden or einen Tag so, dass sie sich nach einer Loesung oder einem Hack schlau machen koennen. (Ich weiss, wie die Loesungen aussehen, bitte schoen. Darum geht es nicht.)
Ob, deiner Meinung nach, diese Endbenutzer in der openSUSE Gemeinde willkommen sind, ist eine andere Frage. Also vieilleicht sollte man lieber die Frage so stellen.
Irgendwie finde ich es aber merkwuerdig, dass openSUSE so viel unsinniges tut, um Windows Dualbooter das Leben zu erleichtern - Ich habe mich oft dagegen geäußert - waehrend mit Kernel Updates so gnadenlos vorgegangen wird.
Akoellh wrote:
>
> Keine Sorge, genau DARUM geht es in meinen Ausführungen.
>
> Du denkst “standardmässig macht man es den Usern, die nicht wissen, was
> sie tun, einfacher, wenn man den alten Kernel behält”, genau anders
> herum wird ein Schuh draus.
>
> Nur wer weiß, was er tut, kann wirklich von diesem Feature profitieren,
> egal ob ein Kernelupdate “buggy” ist oder nicht (die “”, weil der
> letzte, große “Bug” beim Update für 11.3 eben keiner war, sondern ein
> Problem, welches sich der User selbst ins Nest legen musste), geht ein
> Kernelupdate den gewohnten Gang und die Kiste startet mit dem neuen
> Kern, dann holt man sich -wie ich mit einigen Beispielen, die mir auf
> die Schnelle einfielen, da findet sich sicher noch mehr- sehr viele
> neue, potentielle Probleme ins Boot, denn so “einfach” wie Du Dir das
> denkst, ist es eben bei weitem nicht.
>
> Da die Risiken den Nutzen nicht nur zahlenmässig übersteigen, ist es
> eben eine nette Idee mit vielen Haken, meiner Meinung nach sind die
> Haken deutlich schwerwiegender als die Vorteile (oder soll ich sagen
> “der Vorteil”, denn bis auf den einen genannten sehe ich keinen).
>
>
- 1
ich sehe das ebenso.
Je mehr da vermeintliche & vllt sogar auch gut gemeinte Features vorhanden
sind, um so mehr geht daneben … erst recht wenn der gemeine
durchschnittliche Anwender nicht damit weiß umzugehen. Ich schmeiße hier mal
als Beispiel Repositories in die Runde. Was man da manchmal zu sehen bekommt
stellt einen vor eine “schwere” Entscheidung, soll man staunen (darüber das
die Kiste trotz allem noch lief), lachen (über den Einfallsreichtum da nicht
passendes dennoch irgendwie zu “kombinieren”) oder eher heulen (weil der
betreffende so unliebsam und mitleidlos mit seiner Distribution um geht)
…
Die “SuS(i)E” sei mit euch, wo immer ihr seid