staging.inyokaproject.org

Hallo,

ist wieder im Wiki.

Danke für die Überarbeitung.

Gruß, noisefloor

barcc schrieb:

1. In dieser Version hat Chrissss einen Befehl zu Entfernen von alten Kernelpaketen eingefügt. Ich finde, dass der Befehl ziemlich sinnfrei ist:

• Der Befehl ist zu komplex, um nützlich zu sein. Leute die solche Befehle verstehen können, sollen sie sich selbst zusammenschrauben, und die anderen sollen lieber die normale Vorgehensweise verwenden.

• Der normale Weg ist einfach genug.

• Es ist keine gute Idee mit apt-get -y purge die Nachfragen beim Deinstallieren zu übergehen.

• So einen Befehl könnte man auf einer Seite "Obskure Shell-Kommandos" unterbringen. 😉

→ Ich empfehle die vorige Version wiederherzustellen.

Genau deswegen schaut man ja in einem Wiki nach, um sich Arbeit zu ersparen. Ich fand den Befehl sehr praktisch und vermisse ihn in dem Artikel. Einfach kopieren, ausführen und fertig. Wäre schön wenn ihn wieder jemand rein setzen könnte.

GM Alex schrieb:

barcc schrieb:

1. In dieser Version hat Chrissss einen Befehl zu Entfernen von alten Kernelpaketen eingefügt. Ich finde, dass der Befehl ziemlich sinnfrei ist:

• Der Befehl ist zu komplex, um nützlich zu sein. Leute die solche Befehle verstehen können, sollen sie sich selbst zusammenschrauben, und die anderen sollen lieber die normale Vorgehensweise verwenden.

• Der normale Weg ist einfach genug.

• Es ist keine gute Idee mit apt-get -y purge die Nachfragen beim Deinstallieren zu übergehen.

• So einen Befehl könnte man auf einer Seite "Obskure Shell-Kommandos" unterbringen. 😉

→ Ich empfehle die vorige Version wiederherzustellen.

Genau deswegen schaut man ja in einem Wiki nach, um sich Arbeit zu ersparen. Ich fand den Befehl sehr praktisch und vermisse ihn in dem Artikel. Einfach kopieren, ausführen und fertig. Wäre schön wenn ihn wieder jemand rein setzen könnte.

Die Man-Page sagt zu der Option -l des Befehls dpkg (eigentlich dpkg-query) folgendes: "Die Ausgabe ist für menschliche Leser gedacht und nicht leicht maschinenlesbar.". Der Befehl verwendet also die Ausgabe eines Befehl, dass nicht als maschinenlesbar vorgesehen ist, verarbeitet diese mit einem ca. 100 Zeichen langen regulären Ausdruck und verwendet das Ergebnis um möglicherweise wichtige Pakete ohne Nachfrage zu deinstallieren. Einen solchen Befehl würde ich jedenfalls nicht auf meinen Rechner loslassen und deswegen war ich der Meinung, dass der Befehl nicht ins Wiki gehört.

Hier eine (meiner Meinung nach) bessere Version, die allerdings noch länger ist:

sudo apt-get purge $(dpkg-query -W -f='${Status}\t${Package}\n' "linux-*" | sed -nr '/^[^\t]* installed\t.*[0-9]/s/^[^\t]*\t//p' | grep -v $(uname -r | sed "s/-[^0-9]\+$//")) 

Allerdings würde ich auch diesen Befehl nicht ins Wiki übernehmen. Ich habe den Befehl zwar getestet, aber folgende Fragen sind immer noch offen:

• Sind die Regulären Ausdrücke zuverlässig oder wurden irgendwelche Spezialfälle übersehen?

• Haben zukünftige Paketnamen das gleiche Schema?

• Ist es wirklich sinnvoll, alle alten Kernel zu löschen, oder zumindest den nächstälteren zu behalten?

Ich finde, man sollte nur Befehle verwenden, wo man nachvollziehen kann, was sie tun und wo man sicher sein kann, dass sich nicht unvorhergesehenes oder "bösartiges" tun. Oder aber genauer erklären, was der Befehl macht.

Gut, vielleicht bin ich ja übervorsichtig...

Hallo,

Ich finde, man sollte nur Befehle verwenden, wo man nachvollziehen kann, was sie tun und wo man sicher sein kann, dass sich nicht unvorhergesehenes oder "bösartiges" tun. Oder aber genauer erklären, was der Befehl macht.

+1 - Bei Befehlen mit 100+ Zeichen eben schwierig nachzuvollziehen...

Gruß, noisefloor

noisefloor schrieb:

Hallo,

nein, nicht direkt. Der Kernel ist in der Tat "nur" das Paket "linux-image-...", die Header brauchst du nicht. Die Header sind auch keine Abhängigkeit des Kernels.

Die Header werden aber von diversen anderen Progs benutzt und werden oft beom Kompilieren benötigt. Daher werden Sie wohl immer mit installiert.

Wenn der passende Kernel aber gelöscht ist und die

sudo apt.get autoremove 

ausführst werden die passenden Header i.d.R. gelöscht.

Gruß, noisefloor

Sollte der Abschnitt nicht vielleicht doch angepasst werden? Es scheint so als würden die Header doch nicht mit entfernt werden. Siehe:

sudo apt-get autoremove linux-image-2.6.32-22-generic 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Status-Informationen einlesen... Fertig
Die folgenden Pakete werden ENTFERNT:
  linux-image-2.6.32-22-generic

sudo apt-get autoremove linux-headers-2.6.32-22 linux-image-2.6.32-22-generic
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Status-Informationen einlesen... Fertig
Die folgenden Pakete werden ENTFERNT:
  linux-headers-2.6.32-22 linux-headers-2.6.32-22-generic linux-image-2.6.32-22-generic

Es steht ja explizit dabei, dass die Header automatisch mit entfernt werden. Ist eigentlich schon jemand auf die Idee gekommen genau für den Fall ein Skript zu schreiben? N Kernel werden behalten, der Rest wird deinstalliert...

Hallo,

eine Kernelinstallation zu Skripten hat ein relativ hohes Risiko. Weil: wenn das Skript automatisiert durchlaufen soll ist man ggf. rel. schnell bei apt-Paramrter-f (=force) und dann ist das Risiko auch nicht mehr sooo weit entfernt, dass man versehentlich alle Kernel löscht...

Also bei sowas würde ich immer die manuelle Methode bevorzugen, so dass du alle Warnungen etc. von apt siehst.

Gruß, noisefloor

Im Gegensatz zu den Image-Paketen häufen sich die Header-Pakete gar nicht erst an, weil schon beim Aktualisieren die alten entfernt werden. In der Hinsicht ist der Artikel tatsächlich ungenau. Anders ist es natürlich bei manuell installierten Kerneln, da muss man die Header selbst entfernen.

edit: Wiki-Artikel geändert, ich hoffe, das passt.

Bezüglich dem Backports-Abschnitt hätte ich folgende Information:

Unter Lucid 10.04 (LTS) gibt es auch ein Metapaket namens linux-image-generic-lts-backport-maverick in den Standard-Paketquellen. Beide Paketquellen beinhalten dieselben Kernelversionen, vermutlich in Kopie: 2.6.32 und 2.6.35. Das Metapaket namens linux-image-generic-lts-backport-maverick existiert jedoch nur in den Standardquellen. Vermutlich reicht dieses aus, um die 2.6.35-er-Kernel regelmäßig zu bekommen.

Wer weiß genaueres bzw. kann dementieren oder bestätigen, so dass man das Ergebnis in den Artikel einpflegen kann?

Hallo Benno-007,

der Hinweis auf proposed sollte aus dem Backports-Abschnitt entfernt werden. Proposed sind keine Backports, siehe dazu im Artikel Paketquellen (Abschnitt „lucid-proposed“). Was das Paket linux-image-generic-lts-backport-maverick betrifft, weiß ich auch nicht viel mehr, aber da das Paket in den offiziellen Paketquellen sogar in main ist und damit von Canonical gewartet wird, könnte man in dem Artikel schon was dazu schreiben.

Gruß, barcc

Servus ☺

könnte es nicht sein, das dieses Paket einfach nur falsch benannt wurde oder irrtümlich bei den updates deponiert wurde? Die Paketsuche zeigt, das es ausschließlich bei Lucid-updates zu finden ist.

Bevor wir das ins Wiki schreiben, sollte man IMHO bzgl des Namens bei den Paketbauern einmal nachfragen.

Gruß
kaputtnik

barcc schrieb:

der Hinweis auf proposed sollte aus dem Backports-Abschnitt entfernt werden. Proposed sind keine Backports, siehe dazu im Artikel Paketquellen (Abschnitt „lucid-proposed“).

das ist schon fast fahrlässig im Kernel-Artikel auf die proposed-Quellen zu verweisen ohne entsprechende Warnbox

siehe auch hier: Paketquellen (Abschnitt „lucid-proposed“)

imho gehört dieser Hinweis da wieder ganz raus

kaputtnik schrieb:

könnte es nicht sein, das dieses Paket einfach nur falsch benannt wurde oder irrtümlich bei den updates deponiert wurde? Die Paketsuche zeigt, das es ausschließlich bei Lucid-updates zu finden ist.

glaube kaum, daß eine falsche Benennung oder eine falsche Deponierung derart lange nicht aufgefallen wäre. Nachdem entschieden wurde neuere Kernel für die LTS-Version zurückzuportieren musste dann ja auch ein neuer Name für das entsprechende Paket her damit man unterscheiden kann ob es sich um den "normalen" Kernel handelt oder um den zurückportierten.

allzu viele Infos dazu findet man leider nicht: https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS

Naja, es ist eindeutig ein zurückportierter Kernel, egal wie der Name oder die Quelle ist. Insofern ein Sonderfall. Fahrlässig wäre es eher, die ganzen Anfänger mit den Standard-Kerneln zu quälen, nur weil die Wiki-Richtlinien vielleicht zu streng sind. Warnbox ist ok, aber drauf hinweisen sollte man.

Und da das besprochene Paket sogar Backports heisst und in lucid-updates ist, braucht man den Warnkasten nur für die allgemeinen Hinweise zu Proposed und Backports. Der allgemeine Hinweis ist aufgrund der Allgemeingültigkeit und der anderen supporteten Ubuntu-Versionen sehr hilfreich. Das ist die einzige wirkliche Kernelalternative, wenn es Probleme gibt. Mainline kann man wegen WLAN & co. vergessen.

Ich habe mir das übrigens nicht ausgesucht, dass die Backport-Kernel unter Proposed (und teils lucid-updates) liegen und nicht unter Backports - aber umso mehr sollte man sowas leicht auffindbar dokumentieren.

Benno-007 schrieb:

Naja, es ist eindeutig ein zurückportierter Kernel, egal wie der Name oder die Quelle ist. Insofern ein Sonderfall. Fahrlässig wäre es eher, die ganzen Anfänger mit den Standard-Kerneln zu quälen, nur weil die Wiki-Richtlinien vielleicht zu streng sind. Warnbox ist ok, aber drauf hinweisen sollte man.

auch beim zurückportierten Kernel gibt es Vorabversionen die in proposed liegen und die proposed Quellen haben auf einem Produktivsystem nichts zu suchen

Und da das besprochene Paket sogar Backports heisst und in lucid-updates ist, braucht man den Warnkasten nur für die allgemeinen Hinweise zu Proposed und Backports. Der allgemeine Hinweis ist aufgrund der Allgemeingültigkeit und der anderen supporteten Ubuntu-Versionen sehr hilfreich. Das ist die einzige wirkliche Kernelalternative, wenn es Probleme gibt. Mainline kann man wegen WLAN & co. vergessen.

inzwischen bin ich sogar der Auffassung daß selbst eine Warnbox zuwenig ist, der Hinweis die proposed-Quellen zu aktivieren ist fahrlässig!

Ich habe mir das übrigens nicht ausgesucht, dass die Backport-Kernel unter Proposed (und teils lucid-updates) liegen und nicht unter Backports - aber umso mehr sollte man sowas leicht auffindbar dokumentieren.

mach Dich vielleicht erstmal kundig für was die proposed-Quellen gedacht sind, man kann sich den 2.6.35er-Kernel in Lucid auch installieren ohne die proposed-Quellen. Ein Hinweis auf die zurückportierten Kernel ist sicher gut im Artikel, aber bitte nicht aus den proposed-Quellen.

Habe deswegen den Abschnitt Backports aus dem Artikel entfernt.