kernel-remover und deinstallationsorgie

[michaa7]

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?

[devil]

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

[ayla]

+1

Gruß
ayla

(mit zur Zeit deren 11)

@ devil: Vielleicht eine Liste zum anhaken?

[michaa7]

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ß.

Ich 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.

[michaa7]

@ 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.

[ayla]

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.

[cryptosteve]

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

Code Select Expand

kernel-remover -f abwerfen und sich entspannt zurücklehnen?!

[michaa7]

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!

[reddark]

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  ...

[towo]

Es steht jedem frei, das Script zu ändern, so funktioniert Opensource ja.

[mylo]

@ 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!

[cryptosteve]

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.

[agaida]

chroot - tststs... immer diese unbekannten Fachwörter

[cryptosteve]

"unbekannte Fachwörter"?

RTBM: http://manual.siduction.org/de/sys-admin-gen-de.htm#pw-lost

[vindeliker]

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.