Es sammelen sich eben auch unter siduction recht schnell unmengen von kernel an. Bei deren beseitigung ist dann immer langwieriges zuschauen, warten, warten, bis zum nächsten zu deinstallierenden kernel und der obligatorischen beantwortung der frage, ob diese entfernt werden soll ... wahrlich nicht computerisiert.
Will nicht einer der hier versammelten script-cracks sich einen vorzugsplatz in den ewigen linux/debian/siduction-jagdgründen dadurch verdienen, dass er diesen kernel-remover irgendwie in einen loop packt, der die jeweils +noch+ vorhanden kernel zählt und solange ein "ja" übergibt, bis nur noch ein weiterer kernel zum derzeit laufenden übrig ist?
Naja, welcher soll denn das sein? Ich möchte vielleicht den 2.6.28 behalten zusätzlich zum Aktuellen. Alternativ wär das vielleicht eine Idee (mit Abfrage am Anfang ob auto oder manuell)
greetz
devil
+1
Gruß
ayla
(mit zur Zeit deren 11) :)
@ devil: Vielleicht eine Liste zum anhaken?
Quote from: "devil"Naja, welcher soll denn das sein?
Das geht doch vollkommen an meiner bitte vorbei. Natürlich musst/sollst du vorher wie bisher notwendig die zum löschen vorgesehenen kernel auswählen. Aber das problem besteht doch darin, dass man, obwohl ja schon aktiv ausgewählt hat, jede einzelne deinstallation ********nochmals********* UND jeweils ********einzeln******* bestätigen muß.
QuoteIch möchte vielleicht den 2.6.28 behalten zusätzlich zum Aktuellen.
Das sollst du in meinem modell ja dürfen. Ich möche ja nicht die *Auswahl* automatisieren, sondern die *deinstallation der vorab ausgewählten kernel*.
Edit://
Es ist doch auch jetzt schon so, dass der der kernel-remover einen kernel entfernt, und vor der deinstalltion des nächsten *ausgewählten* kernel dennoch abfragt, ob dieser deinstalliert werden soll. Und an dieser stelle soll der loop automatisch ein "ja" übergeben ... bis nur noch ein (zusatz-)kernel übrig ist. Ich verstehe diese zusätzliche abfrage ja als eine sicherheitsabfrage, die den user davor bewahren soll ohne rettenden ersatzkernel dazustehen. Und solange diese sicherheitsabfrage nicht komplett wegfällt wäre es schön diese eben irgendwie auf wirklich nur eine einzige abfrage zu reduzieren. Zu rettung reicht eben ein zusatzkernel.
Quote from: "ayla"
@ devil: Vielleicht eine Liste zum anhaken?
verwende ich nen anderen kernel-remover? Die auswahlliste gibt es doch. Nur muß ich anschliessend doch jeden einzelnen kernel nochmals einzeln zur deinstallation freigeben.
Und dabei ist es auch vielleicht nicht unbedingt notwendig daß grub bei jedem einzelnen Kernel aktualisiert wird wie bisher sondern nur einmal am Ende?
Edit: @ Michaa7, jo, hatte ich vergessen, aber vielleicht eine Positivliste -> Ich möchte behalten statt ich möchte deinstallieren.
Quote from: "michaa7"dass er diesen kernel-remover irgendwie in einen loop packt, der die jeweils +noch+ vorhanden kernel zählt und solange ein "ja" übergibt, bis nur noch ein weiterer kernel zum derzeit laufenden übrig ist?
Wieso nicht auf den zweiten lauffähigen Kernel verzichten und einfach ein
kernel-remover -f abwerfen und sich entspannt zurücklehnen?!
Diese option kannte ich nicht, und wenn man dies gleich beim neuinstall eines kernels durchführt behält man sogar noch nen sicherheitsgurt/kernel, was ja grundsätzlich nicht so ganz sinnfrei ist ... oder haut die "-f" option den eben neu installierten kernel auch mit weg?
Danke für deinen hinweis!
Also ich fänd die idee nicht doof, das es automatisch ohne nachfragen durchläuft und die vorher ausgewälten Kernel entfernt. Zum Schluss sollte dann aber wenigstens noch eine DONE-Meldung kommen ... ;)
Es steht jedem frei, das Script zu ändern, so funktioniert Opensource ja.
Quote from: "michaa7"Quote from: "ayla"
@ devil: Vielleicht eine Liste zum anhaken?
verwende ich nen anderen kernel-remover? Die auswahlliste gibt es doch. Nur muß ich anschliessend doch jeden einzelnen kernel nochmals einzeln zur deinstallation freigeben.
Das Thema ist doch, dass zwischen dem entfernen der einzelnen Kernel eine halbe bis eine Minute Zeit vergeht. Die Bestätigungsmeldungen kommen zeitlich dann in dem Abstand und fallen dann (bei 8 Kerneln, so 5 Minuten lang ständig in das rein, was man eigentlich macht.
Die Idee, hier den Computer für sich arbeiten zu lassen finde ich gut und revolutionär!
Quote from: "michaa7"oder haut die "-f" option den eben neu installierten kernel auch mit weg?
Sorry, das weiss ich nicht, weil ich nicht auf die Idee käme, mir irgendwie an den Kerneln rumnesteln zu lassen, solange ich noch nicht getestet habe, ob der aktuellste auch wirklich funktioniert. :)
Obwohl ... schlussendlich tut auch ein kurzes chroot zum Reparieren nicht weh.
chroot - tststs... immer diese unbekannten Fachwörter
"unbekannte Fachwörter"?
RTBM: http://manual.siduction.org/de/sys-admin-gen-de.htm#pw-lost
Quote from: "michaa7"oder haut die "-f" option den eben neu installierten kernel auch mit weg?
Ja, das tut's! Aber der aktuell laufende Kernel bleibt dir ja erhalten, und normalerweise funktioniert der ja, denn der läuft ja gerade :wink:
Ich hau meine alten Kernel gnadenlos weg und hatte damit noch nie ein Problem (zumindest nicht seitdem ich was auf Debian Sid fahre).
Und mit chroot kannte ich mich mal gut aus, das war mit ein Grund, warum ich vom Chamäleon zu irgendeiner Bughunter gewechselt bin. Am Ende konnte man sich drauf verlassen, dass nach einem Kernelupdate nix mehr ging.
Quote from: "vindeliker"Quote from: "michaa7"oder haut die "-f" option den eben neu installierten kernel auch mit weg?
Ja, das tut's! Aber der aktuell laufende Kernel bleibt dir ja erhalten, und normalerweise funktioniert der ja, denn der läuft ja gerade :wink:...
ok, dann gilt ab heute die regel:
erst
kernelremover -f
dann
d-u (mit potentiell neuem kernel)
Schreib halt jemand nen Bug in den Bugtracker auf Chili, dann muß sich jemand damit befassen.:)
greetz
devil
die, wie im core meeting log nachzulesen war, ins auge gefasste erweiterung des kernel-remover um die "--yes" option ist so wie im log beschrieben überflüssig. cryptosteves diesbezügliche anmerkung ging in der diskussion auch unter, weshalb ich das hier anmerke.
Eine "--yes"-option wäre allenfalls wünschenswert, um automatisiert die zuvor ausgewählten, und nur diese kernel ohne ständige neue nachfrage zu löschen. Es blieben also alle anderen nicht zum löschen markierten kernel erhalten.
Das löschen aller kernel bis auf den laufenden ist derzeit bereits mit der "-f" option möglich. Dies entspricht jedoch dem im core meeting für die --yes-option angedeuteten/vorgesehenen verhalten, die *so* also überflüssig wäre.