Hallo, Weiß jemand, wie das bei Suse funktioniert? Wie lange dauert es von der Veröffentlichung eines neuen Kernels bis zur Verfügbarkeit über YOU? In der c't ist ja beschrieben, daß es ein Sicherheitsproblem mit dem alten Kernel gibt, das jetzt aber gefixt ist. Hat SuSe da noch eine extra Testzeit, die die Auslieferung neuer Kernel verzögert, oder was ist der Grund? Laut kernel.org ist 2.6.7 ja schon zwei Wochen verfügbar. Ich erhoffe mir vom neuen Kernel ein paar weniger Abstürze ... Viele Grüße Stefan -- Stefan Müller Universität Bremen/Fachbereich 10 Tel: (+49) (+421) 218-8601 Postfach 33 04 40 D-28334 Bremen http://www.cl.uni-bremen.de/~stefan/ http://www.cl.uni-bremen.de/~stefan/Babel/Interaktiv/
On Fri, Jul 02, 2004 at 12:34:05PM +0200, Stefan Müller wrote:
Hallo,
Weiß jemand, wie das bei Suse funktioniert? Wie lange dauert es von der Veröffentlichung eines neuen Kernels bis zur Verfügbarkeit über YOU? In der c't ist ja beschrieben, daß es ein Sicherheitsproblem mit dem alten Kernel gibt, das jetzt aber gefixt ist.
die bekannten Sicherheitslücken sind mit dem letzten YOU-Kernel 2.6.5-7.75
Hat SuSe da noch eine extra Testzeit, die die Auslieferung neuer Kernel verzögert, oder was ist der Grund?
Ja, das auch, aber typischerweise werden die Kernel mehr oder weniger gleichzeitig mit dem Bekanntwerden der Sicherheitslücken veröffentlicht. Dann sind sie schon durch die Tests durch.
Laut kernel.org ist 2.6.7 ja schon zwei Wochen verfügbar.
auf www.suse.de/security (oder so) gibt es eine FAQ dazu. Die security- fixes werden auf die alten Kernel rückportiert.
Ich erhoffe mir vom neuen Kernel ein paar weniger Abstürze ...
Ein Versionsupdate wirst du höchstwahrscheinlich erst mit der 9.2 bekommen. -- Stefan Seyfried
Hallo Stefan,
Ich erhoffe mir vom neuen Kernel ein paar weniger Abstürze ...
Ein Versionsupdate wirst du höchstwahrscheinlich erst mit der 9.2 bekommen.
D.h. Suse bleibt immer bei 2.6.5 und es werden nur sicherheitsrelevante Sachen zurückportiert? Das ist ja schade. Dann wird es also nichts mit Dothan und Suse 9.1. Für wann ist denn 9.2 geplant, wenn man das fragen darf? Viele Grüße Stefan PS Die security-Seite habe ich angeguckt, Informationen darüber, wie das mit den Updates gehandhabt wird, konnte ich aber nicht finden. Noch mehr Grüße Stefan -- Stefan Müller Universität Bremen/Fachbereich 10 Tel: (+49) (+421) 218-8601 Postfach 33 04 40 D-28334 Bremen http://www.cl.uni-bremen.de/~stefan/ http://www.cl.uni-bremen.de/~stefan/Babel/Interaktiv/
On 02.07.2004 22:11 Stefan Müller wrote:
Ein Versionsupdate wirst du höchstwahrscheinlich erst mit der 9.2 bekommen.
D.h. Suse bleibt immer bei 2.6.5 und es werden nur sicherheitsrelevante Sachen zurückportiert?
Das ist ja schade. Dann wird es also nichts mit Dothan und Suse 9.1.
Naja, es gibt ja trotzdem die Möglichkeit, sich einen eigenen Kernel zu erstellen, der dann wesentlich "neuer" ist, als ein gepatchter von SuSE. Eine gute Seite hierzu findest Du übrigens auf http://www.thomashertweck.de/kernel.html
Für wann ist denn 9.2 geplant, wenn man das fragen darf?
Bisher verhielt es sich immer so, dass man ziemlich nichts darüber erfahren konnte, wann ein neues Release herausgegeben wird. Ob sich das jetzt mit Novell ein wenig ändern könnte? Auf jeden Fall kann es manchmal schon eine Weile dauern und je nach Wichtigkeit solltest Du schauen, ob Du nicht - selbst einen neuen Kernel erstellst oder - mal eine andere Distribution testest oder - ??? Meinst Du denn tatsächlich, dass sich Deine Systemabstürze dem Kernel zuordnen lassen? Martin
Hallo Martin, Ja, dann werd ich mich heute wohl mal ans Basteln machen.
Meinst Du denn tatsächlich, dass sich Deine Systemabstürze dem Kernel zuordnen lassen?
Also ich kriege nach dem Resume ab und zu Abstürze. Es steht was von Kernel-panic da und irgendwas mit netzwerktreiber bn.c oder sowas. Der Fehler könnte behoben sein. Abgestürzte resums sind besonders nervig, weil `noresume' die Swap-Partition nicht richtig aufräumt. Nach dem Neustart, bildet sich das System ein, sein Speicher sei voll (512 MB und nur KDE gestartet) und hat auch noch was im Swap und swapt wie blöde. Nach einem abgestürzten resume muß ich also zweimal booten. Außerdem scheint das System beim Throtling abzustürzen. Es versucht auf die Platte zuzugreifen und bleibt dann mit leuchtender Plattendiode stehen. Ob das nun am Throttling/nicht erkannten Prozessor liegt, weiß ich aber nicht. Insgesamt würde ich das als ein nicht funktionierendes Betriebssystem bezeichnen und Suse sollte der Ehre halber da mal was nachschieben (auch ohne 50 € für die nächste Version). Der Kernel findet nur 64K Cache, ob das für die Performance relevant ist, weiß ich nicht, eigentlich müßte sich ja der Prozessor von selbst um seinen Cach kümmern, oder spielt das irgendwo im Linux-Code eine Rolle? Viele Grüße und Danke für die Seite Stefan -- Stefan Müller Universität Bremen/Fachbereich 10 Tel: (+49) (+421) 218-8601 Postfach 33 04 40 D-28334 Bremen http://www.cl.uni-bremen.de/~stefan/ http://www.cl.uni-bremen.de/~stefan/Babel/Interaktiv/
On Fri, Jul 02, 2004 at 10:11:02PM +0200, Stefan Müller wrote:
Ein Versionsupdate wirst du höchstwahrscheinlich erst mit der 9.2 bekommen.
D.h. Suse bleibt immer bei 2.6.5 und es werden nur sicherheitsrelevante Sachen zurückportiert?
Jein, es wurde ja auch von 2.6.4 auf 2.6.5 updated, aber das war ein Nebenprodukt der SLES9, die den 2.6.5 hat. Die 9.1-Updatekernels sind ähnlich den SLES9-Kernels. Aber nachdem die SLES9 nun für 5 Jahre maintained werden muss, wird es vermutlich nicht so schnell Versions- updates geben (dann müssen sämtliche Zertifizierungen wiederholt werden etc.).
Das ist ja schade. Dann wird es also nichts mit Dothan und Suse 9.1.
Wo ist denn das Problem? Die Dothans die ich hier habe, haben kein Problem. CPUfreq geht mit dem "acpi" Modul und sonst habe ich auf den Maschinen noch kein Problem gesehen, das ich mit einem neueren Kernel hätte lösen können.
Für wann ist denn 9.2 geplant, wenn man das fragen darf?
Im Herbst. So weit ich weiss hat sich nichts an der "2 Releases pro Jahr"- Frequenz geändert.
PS Die security-Seite habe ich angeguckt, Informationen darüber, wie das mit den Updates gehandhabt wird, konnte ich aber nicht finden.
Ich bin gerade offline, aber ich suche die URL mal raus. Gruss, Stefan -- Stefan Seyfried
On Sat, Jul 03, 2004 at 10:04:09AM +0200, Stefan Müller wrote:
Hallo Martin,
Ja, dann werd ich mich heute wohl mal ans Basteln machen.
Meinst Du denn tatsächlich, dass sich Deine Systemabstürze dem Kernel zuordnen lassen?
Also ich kriege nach dem Resume ab und zu Abstürze. Es steht was von Kernel-panic da und irgendwas mit netzwerktreiber bn.c oder sowas. Der Fehler könnte behoben sein.
hm, bn.c gibts in den Kernelquellen nicht. Wenn du die kernel-panic genau (inklusive stackdump) abschreiben kannst, oder zumindest genau die Funktion nennen kannst, dann hilft das beim Fixen des Bugs ungemein, denn dann können die Experten genau feststellen, woran es lag.
Abgestürzte resums sind besonders nervig, weil `noresume' die Swap-Partition nicht richtig aufräumt. Nach dem Neustart, bildet sich
Das sollte nicht sein. Entweder sie wird nicht aufgeräumt (bug), dann hast du aber gar keinen Swap, oder sie wird mittels "mkswap" neu formatiert.
das System ein, sein Speicher sei voll (512 MB und nur KDE gestartet) und hat auch noch was im Swap und swapt wie blöde.
Du hast nicht zufällig mehr als eine Swap-Partition? Weil die Swap-Partition ge-'mkswap'-t wird, somit "wie neu" ist (die ist nach einem vermurksten resume nämlich "richtig" kaputt, sprich sie kann nicht eingebunden werden, weil sie keine gültige Signatur hat. Darum ist folgender Code in /etc/init.d/boot.swap: get_swap_id() { local line; fdisk -l | while read line; do case "$line" in /*Linux\ swap) echo "${line%% *}" esac done } check_swap_sig () { local part="$(get_swap_id)" local where what type rest p c while read where what type rest ; do test "$type" = "swap" || continue c=continue for p in $part ; do test "$p" = "$where" && c=true done $c case "$(dd if=$where bs=1 count=6 skip=4086 2>/dev/null)" in S1SUSP|S2SUSP) mkswap $where esac done < /etc/fstab } der das wieder fixed. Insofern kann ich mir das nicht ganz erklären.
Nach einem abgestürzten resume muß ich also zweimal booten.
Außerdem scheint das System beim Throtling abzustürzen. Es versucht auf die Platte zuzugreifen und bleibt dann mit leuchtender Plattendiode stehen. Ob das nun am Throttling/nicht erkannten Prozessor liegt, weiß ich aber nicht.
Lass doch mal das Throttling aus (ist bei einem Dothan eh nicht nötig, der hat ja richtige Stromsparfunktionen). Dann siehst du, ob es am Throttling liegt.
Insgesamt würde ich das als ein nicht funktionierendes Betriebssystem bezeichnen und Suse sollte der Ehre halber da mal was nachschieben (auch ohne 50 € für die nächste Version).
Nun ja, wenn das alles ist, was nicht funktioniert: suspend ist ganz klar als experimentell und nicht unterstützt markiert, und wenn es einen fix für den Throttling-Bug (so es denn einer ist) gibt, dann wird der auch früher oder später in einen YOU-Kernel einfliessen.
Der Kernel findet nur 64K Cache, ob das für die Performance relevant ist, weiß ich nicht, eigentlich müßte sich ja der Prozessor von selbst um seinen Cach kümmern, oder spielt das irgendwo im Linux-Code eine Rolle?
Das weiss ich nicht, ich vermute aber, daß das dem Kernel relativ egal sein wird. Insgesamt riecht mir das ganze ein wenig nach einem Vermurksten BIOS, aber das ist natürlich immer schwer zu beweisen. Gruss, Stefan -- Stefan Seyfried
Hallo,
Das sollte nicht sein. Entweder sie wird nicht aufgeräumt (bug), dann hast du aber gar keinen Swap, oder sie wird mittels "mkswap" neu formatiert.
das System ein, sein Speicher sei voll (512 MB und nur KDE gestartet) und hat auch noch was im Swap und swapt wie blöde.
Du hast nicht zufällig mehr als eine Swap-Partition?
Nö.
Weil die Swap-Partition ge-'mkswap'-t wird, somit "wie neu" ist (die ist nach einem vermurksten resume nämlich "richtig" kaputt, sprich sie kann nicht eingebunden werden, weil sie keine gültige Signatur hat. Darum ist folgender Code in /etc/init.d/boot.swap:
get_swap_id() { local line; fdisk -l | while read line; do case "$line" in /*Linux\ swap) echo "${line%% *}" esac done }
check_swap_sig () { local part="$(get_swap_id)" local where what type rest p c while read where what type rest ; do test "$type" = "swap" || continue c=continue for p in $part ; do test "$p" = "$where" && c=true done $c case "$(dd if=$where bs=1 count=6 skip=4086 2>/dev/null)" in S1SUSP|S2SUSP) mkswap $where esac done < /etc/fstab }
der das wieder fixed. Insofern kann ich mir das nicht ganz erklären.
Vielleicht liegt es ja wirklich daran, daß die Partition zu groß ist: /dev/hda5 596 857 2104483+ 82 Linux swap Suse hatte sich auch beim allerersten Partitionieren beschwert (Formatieren fehlgeschlagen), beim zweiten Versuch ging es dann. Nach einem gescheiterten resume hat er dann beim Booten gesagt, daß er resume-Information gefunden hat und trotz Oprion noresume auch die Punkte angezeigt, die er sonst beim resume anzeigt. Leider scheint das nicht in /var/log/messages zu stehen, konnte jedenfalls nichts finden.
Lass doch mal das Throttling aus (ist bei einem Dothan eh nicht nötig, der hat ja richtige Stromsparfunktionen). Dann siehst du, ob es am Throttling liegt.
Ja, wie gesagt, ohne Throttling lief alles. Ich habe aber gehört, daß jemand anders andere Abstürze hatte, die auf die Netzwerkkarte zurückzuführen sind und erst nach einigen Stunden Betrieb auftraten. Ich wüßte nicht, wie man den Fehler eindeutig zuordnen sollte. Mit 2.6.7 scheint alles zu gehen.
Der Kernel findet nur 64K Cache, ob das für die Performance relevant ist, weiß ich nicht, eigentlich müßte sich ja der Prozessor von selbst um seinen Cach kümmern, oder spielt das irgendwo im Linux-Code eine Rolle?
Das weiss ich nicht, ich vermute aber, daß das dem Kernel relativ egal sein wird.
Es ist auch L1 64 kb und L2 2MB, insofern ist die Anzeige dann wohl okay.
Insgesamt riecht mir das ganze ein wenig nach einem Vermurksten BIOS, aber das ist natürlich immer schwer zu beweisen.
Das kann sein. Übrigens hatte ich vor dem Kernel-Update den Effekt, daß das System nach dem Ausschalten manchmal nicht hochgefahren ist. Die LEDs haben alle geleuchtet, und dann hat sich der Rechner wieder ausgeschaltet. Das war dann auch nach zwischenzeitlichem Arbeiten mit Windows so. Mitunter mußte ich zwei- bis sechsmal einschalten, bis die Kiste hochgefahren ist. Das ist jetzt beim neuen Kernel (2.6.7) weg. Ich finde es ziemlich verblüffend, daß man mit Software irgendwelche so low-leveligen Sachen anrichten kann, die dann auch Stromabschalten und Betriebssystemwechsel überstehen. Jetzt scheint das Problem aber behoben zu sein. Bin froh, daß ichs hingekriegt habe. Viele Grüße Stefan -- Stefan Müller Universität Bremen/Fachbereich 10 Tel: (+49) (+421) 218-8601 Postfach 33 04 40 D-28334 Bremen http://www.cl.uni-bremen.de/~stefan/ http://www.cl.uni-bremen.de/~stefan/Babel/Interaktiv/
On Sun, Jul 04, 2004 at 11:23:31AM +0200, Stefan Müller wrote:
Du hast nicht zufällig mehr als eine Swap-Partition?
Nö.
ok.
Vielleicht liegt es ja wirklich daran, daß die Partition zu groß ist:
/dev/hda5 596 857 2104483+ 82 Linux swap
Suse hatte sich auch beim allerersten Partitionieren beschwert (Formatieren fehlgeschlagen), beim zweiten Versuch ging es dann.
Seltsam, mir ist zwar nichts bekannt, ich hatte aber auch noch nie soviel Plattenplatz übrig, um dermassen große Swap-Partitionen anzulegen :-)
Nach einem gescheiterten resume hat er dann beim Booten gesagt, daß er resume-Information gefunden hat und trotz Oprion noresume auch die Punkte angezeigt, die er sonst beim resume anzeigt. Leider scheint das
Ja, das ist eine der "interessanten" Stellen im swsusp-Code. Bei "noresume" wird die Swap-Partiton trotzdem zurückgelesen (wobei im dümmsten Fall auch noch Fehler auftreten können...) und danach aber verworfen. Das wollte ich immer mal fixen, aber habe es bisher nicht gemacht (ist auch mehr kosmetisch).
nicht in /var/log/messages zu stehen, konnte jedenfalls nichts finden.
Da es sich um einen "normalen" Bootvorgang handelt und das stattfindet, bevor der syslogd gestartet ist, wird es eher in /var/log/boot.msg zu sehen sein.
Mit 2.6.7 scheint alles zu gehen.
Soweit ich weiss, ist in 2.6.7 wieder eine neuere Version der ACPI-CA, insofern ist es gut möglich, daß da Fortschritte gemacht wurden.
Es ist auch L1 64 kb und L2 2MB, insofern ist die Anzeige dann wohl okay.
Insgesamt riecht mir das ganze ein wenig nach einem Vermurksten BIOS, aber das ist natürlich immer schwer zu beweisen.
Das kann sein. Übrigens hatte ich vor dem Kernel-Update den Effekt, daß das System nach dem Ausschalten manchmal nicht hochgefahren ist. Die LEDs haben alle geleuchtet, und dann hat sich der Rechner wieder ausgeschaltet. Das war dann auch nach zwischenzeitlichem Arbeiten mit Windows so. Mitunter mußte ich zwei- bis sechsmal einschalten, bis die Kiste hochgefahren ist. Das ist jetzt beim neuen Kernel (2.6.7) weg.
Das würde auch auf verbesserte ACPI-Funktionen schliessen lassen. ACPI ist viel mehr als nur "Energiesparen", ein großer Teil der Hardwarekonfi- guration wird von ACPI beeinflußt. Wenn du dann noch ein suboptimales BIOS hast, das beim Einschalten nicht alles richtig initialisiert, dann ist es gut möglich, daß Einstellungen, die vor dem shutdown "verstellt" wurden auch nach dem Neustart noch nicht korrekt sind.
Ich finde es ziemlich verblüffend, daß man mit Software irgendwelche so low-leveligen Sachen anrichten kann, die dann auch Stromabschalten und Betriebssystemwechsel überstehen. Jetzt scheint das Problem aber behoben zu sein.
Es kam früher relativ häufig vor, daß manche Hardware nur richtig funktionierte, nachdem zuerst Windows und dann Linux gebootet wurde. Insbesondere Hardware, für die keine Dokumentation verfügbar ist und die Treiber daher "erraten" werden müssen, machte da manchmal Schwierigkeiten. -- Stefan Seyfried
On Sat, Jul 03, 2004 at 08:44:45PM +0200, Stefan Seyfried wrote:
PS Die security-Seite habe ich angeguckt, Informationen darüber, wie das mit den Updates gehandhabt wird, konnte ich aber nicht finden.
Ich bin gerade offline, aber ich suche die URL mal raus.
Ok, es ist nicht auf der SUSE-Security-Seite, sondern in der susefaq: http://susefaq.sourceforge.net/faq/software.html Aber von Roman, oberste Autorität :-) -- Stefan Seyfried
participants (3)
-
Martin Röhricht -
Stefan Müller -
Stefan Seyfried