Hallo, ich habe hier ein ziemlich fatales Problem nach dem letzten Kernel-Update auf 2.6.18.2-34-default. Hintergrund. Auf dem Rechner läuft (bzw. lief) openSUSE 10.2 mit aktuellen Patches. /boot liegt auf /dev/sda2 / liegt auf einem Logical Volume (also eine Konfiguration, die in diesem Sinne so ähnlich ist, wie auf http://de.opensuse.org/SW-RAID_und_LVM beschrieben). Dies ist eine Konfiguration, die es schon lange einwandfrei tut - und auch schon einige Kernelupdates überstanden hat. Nach dem letzten Kernelupdate hat sich der Rechner erstmal geweigert, zu booten - die LVM-Volumes wurden nicht gefunden. Na prachtvoll ... Jedenfalls war auch zu sehen, daß die Datei /boot/grub/menu.lst komplett neu geschrieben war - alle (!) alten Einträge, auch die von mir hinzugefügten, waren damit weg. Langer Rede, kurzer Sinn - ich habe also eine neue Installation gemacht, das Update fand im Rahmen der Installation statt. Diesesmal habe ich ein neues LV angelegt in der Annahme, daß ich dann mit einer neu installierten /boot und der alten Rootpartition wieder booten könnte (nach entsprechendem Eintrag in der menu.lst). Halbwegs richtig. Ich kann meine alte Installation jetzt wieder booten, allerdings bleibt der Bootvorgang beim Starten des crond hängen. Hmmm? Bleibt absolut hängen, daher kann ich auch nicht weiter debuggen. Nun also booten in den Runlevel 2. Geht. Init 3 - geht auch, schmeißt aber HAUFENWEISE Fehlermeldungen. ein rpm -qa | grep 2.6.28.8 gibt mir drei Pakete: kernel-xen, kernel-source und kernel-default. ein rpm-qa | grep 2.6.18 | grep 34 gibt mir 7 Pakete, nämlich für drbd, madwifi, tpctl, wlan (xen), drbd (xen) und nvidia-gfx. uname -a sagt mir, daß ich kernel 2.6.28.2-34-default gebootet habe. Offensichtlich hat zwar der Kernel sein Update bekommen, nicht jedoch nicht die ganzen Module - oder? Nun kann ich also entweder eine rudimentäre Installation booten, die Zugriff aufs Netz hat - oder meine alte Installation, solange ich in den niederen Runlevels bleibe. Diese hat jedoch veraltete Module, so daß nichtmal das Netzwerk läuft (Karte wird zwar benannt, aber es gibt kein Device) - und so kann ich auch kein Update fahren. Wer denkt sich denn sowas aus? Nein - eigentlich ist das nicht meine Frage, sondern: Wie komme ich da raus? In der Installation steckt ziemlich viel Konfig-Arbeit, die ich nur ungern von vorne machte ... Nun - hat mal jemand einen Tip? Wie kann ich das Update machen? Ich könnte es wahrscheinlich ermöglichen, nochmal den alten Kernel damit zu booten, aber dann wird ja wieder das Update nicht angezogen (und wieder die gesamte Konfig zerschossen) - oder? Gruß Richard Kampmann PS: Schon lange frage ich mich, warum es keine Konfig gibt, die einem das alte Partitionsschema erspart (d.h. PV ist /dev/sda und fertig). Grub müßte damit klarkommen und es müßte eine entsprechende initrd geben ... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Richard, Am Dienstag, 13. März 2007 23:56 schrieb Richard Kampmann:
Langer Rede, kurzer Sinn - ich habe also eine neue Installation gemacht, das Update fand im Rahmen der Installation statt. Diesesmal habe ich ein neues LV angelegt in der Annahme, daß ich dann mit einer neu installierten /boot und der alten Rootpartition wieder booten könnte (nach entsprechendem Eintrag in der menu.lst).
Halbwegs richtig. Ich kann meine alte Installation jetzt wieder booten, allerdings bleibt der Bootvorgang beim Starten des crond hängen. Hmmm? Bleibt absolut hängen, daher kann ich auch nicht weiter debuggen.
Nun also booten in den Runlevel 2. Geht. Init 3 - geht auch, schmeißt aber HAUFENWEISE Fehlermeldungen.
ein rpm -qa | grep 2.6.28.8 gibt mir drei Pakete: kernel-xen, kernel-source und kernel-default. ein rpm-qa | grep 2.6.18 | grep 34 gibt mir 7 Pakete, nämlich für drbd, madwifi, tpctl, wlan (xen), drbd (xen) und nvidia-gfx. uname -a sagt mir, daß ich kernel 2.6.28.2-34-default gebootet habe.
Offensichtlich hat zwar der Kernel sein Update bekommen, nicht jedoch nicht die ganzen Module - oder?
schaut so
Nun kann ich also entweder eine rudimentäre Installation booten, die Zugriff aufs Netz hat - oder meine alte Installation, solange ich in den niederen Runlevels bleibe. Diese hat jedoch veraltete Module, so daß nichtmal das Netzwerk läuft (Karte wird zwar benannt, aber es gibt kein Device) - und so kann ich auch kein Update fahren.
Wer denkt sich denn sowas aus? Nein - eigentlich ist das nicht meine Frage, sondern:
Wie komme ich da raus? In der Installation steckt ziemlich viel Konfig-Arbeit, die ich nur ungern von vorne machte ...
Nun - hat mal jemand einen Tip? Wie kann ich das Update machen? Ich könnte es wahrscheinlich ermöglichen, nochmal den alten Kernel damit zu booten, aber dann wird ja wieder das Update nicht angezogen (und wieder die gesamte Konfig zerschossen) - oder?
Ich würde versuchen die Distri die zu dem halb installierten System gehört als Rettungssystem zu booten, das System (komplett inkl. aller notwendigen partitionen) irgendwo hin zu mounten und da rein zu chrooten, dann sollte man die paar pakete nachinstallieren können die da grundsätzlich faul sind. Die Systemreparatur sollte das zwar auch können aber ich würds von hand machen. Dabei kann es sein das du im chroot keinen Zugriff auf das CD LW hast, es würde helfen die fraglichen Pakete vor dem chroot schon irgendwo innerhalb des zielsystems abzulegen. Danach dann die Partitionen wieder unmounten und das System wieder von der CD aber diesmal mit Installiertes System booten bis zu einer Konsole starten und das mk_initrd fahren, dann sollte sich das System wieder starten lassen. Installiertes System booten geht bis zum default runlevel, den könntest du in der inittab schon beim nachinstallieren der Pakete entsprechend runtersetzen um einen evtl. notwendigen turnaround zu verkürzen. btw: wenns dann wieder halbwegs läuft hat smart eine wunderschöne Option die Installation auf Konsistenz zu prüfen und zu korrigieren ... zumindest was die Abhängigkeiten der rpms angeht. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Falk,
Ich würde versuchen die Distri die zu dem halb installierten System gehört als Rettungssystem zu booten, das System (komplett inkl. aller notwendigen partitionen) irgendwo hin zu mounten und da rein zu chrooten, dann sollte man die paar pakete nachinstallieren können die da grundsätzlich faul sind. Die Systemreparatur sollte das zwar auch können aber ich würds von hand machen. Dabei kann es sein das du im chroot keinen Zugriff auf das CD LW hast, es würde helfen die fraglichen Pakete vor dem chroot schon irgendwo innerhalb des zielsystems abzulegen.
Danach dann die Partitionen wieder unmounten und das System wieder von der CD aber diesmal mit Installiertes System booten bis zu einer Konsole starten und das mk_initrd fahren, dann sollte sich das System wieder starten lassen.
OK. Ich habe also das Rettungssystem von der DVD gebootet. Dann das alte Root gemountet und mit chroot zum aktuellen Root gemacht. Nun - smart hat ein paar Pakete nachgezogen, aber nur ein paar Applikationen. Sonst angeblich nichts zu tun. Yast Online-Update: Keine Patches. Yast Upgrade hat einen Haufen Packages gemeldet, dann aber letztlich nichts heruntergeladen. Auch ein Yast Install meldet keinen Handlungsbedarf bei der Paketüberprüfung. OK. Also ein Rebootversuch ins System, um zu schauen, wie weit es geht. Ein normaler Reboot bleibt nach wie vor beim Start des cron hängen. Grmpft. Aber ein Boot in Runlevel 2 geht und ein init 3 geht dann auch. Naja - jede Menge Fehlermeldungen - besonders iptables wird angemeckert, ein Netzwerk ist auch nicht zu bekommen. Dann auf dieser Ebene nochmal eine Prüfung mit smart: "check" gibt keine Ausgabe "fix" sagt "No problems to resolve!" "stats" aber sagt: Installed Packages: 1308 Total Packages: 8301 Total Provides: 32282 Total Requires: 6688 Total Upgrades: 9512 Total Conflicts: 1616 Tja. Hmmm. Aber Smart will auch mit "upgrade" nichts tun ("no interesting upgrades available"). Wie auch immer das zusammenpaßt. Und solange ich kein Netz habe, brauche ich ein weiteres Update ja auch nicht zu probieren. Ein mk_initrd beschwert sich über einen Haufen module "Is modules.dep up to date?". Auch ein depmod -a ändert daran nichts. Also ein erneutes Booten ins Rescue system und das gleiche Spiel: Nix neues mit smart und YOU oder Yast System Upgrade. So langsam komme ich an den Punkt, wo eine Neuinstallation weniger Arbeit ist. <FRUST ON> Dennoch glaube ich, daß da ein übler Bug in der Distribution ist - wenn die Situation, /boot auf einer Partition und / auf einem LV zu haben, durch ein einfaches Kernel-Update dazu führen kann, daß man neu installieren muß, darf das nicht zugelassen werden - jedenfall nicht ohne Warnung. Ich erinner mich aber, daß das als mögliche Kombination schon früher genannt wurde - und in dem von mir benannten Link auch beschrieben wurde. Und immerhin hat es ja auch mindestens ab 10.0 bei mir funktioniert. Ich habe etwas den Eindruck, daß es seit einiger Zeit zugunsten neuer Features ein Quaitätsproblem gibt ... <Frust OFF>
Installiertes System booten geht bis zum default runlevel, den könntest du in der inittab schon beim nachinstallieren der Pakete entsprechend runtersetzen um einen evtl. notwendigen turnaround zu verkürzen.
Naja - das kann man ja auch im Grub-Bootmenue wählen ...
btw: wenns dann wieder halbwegs läuft hat smart eine wunderschöne Option die Installation auf Konsistenz zu prüfen und zu korrigieren ... zumindest was die Abhängigkeiten der rpms angeht.
Tja - wäre schön. Kenne ich natürlich, benutze ich auch gerne (nicht vergessen: Channels müssen gepflegt sein). Hilf hier aber nix. Und da das Netzwerk nur da ist, wenn ich im Rescue-System boote und nicht, wenn ich das System selber boote ... Also - noch eine Idee? Gruß Richard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Richard, Am Do 15.März 2007 12:12:04 schrieb Richard Kampmann:
OK. Ich habe also das Rettungssystem von der DVD gebootet. Dann das alte Root gemountet und mit chroot zum aktuellen Root gemacht.
Nun - smart hat ein paar Pakete nachgezogen, aber nur ein paar Applikationen. Sonst angeblich nichts zu tun.
hm du hast aber schon vorher die Pakete von denen du weist das sie abweichen (die mit den kernelmodulen) von hand aktualisiert?!? Durchaus auch mit Gewalt --force Und smart würde ich im chroot auch noch nicht anfassen erst wenn der kasten wieder aus eigener Kraft ein Netzwerk hat.
Yast Online-Update: Keine Patches. Yast Upgrade hat einen Haufen Packages gemeldet, dann aber letztlich nichts heruntergeladen.
da fehlt mglw. noch was von dem yast kram in deiner installation su.
Auch ein Yast Install meldet keinen Handlungsbedarf bei der Paketüberprüfung.
OK. Also ein Rebootversuch ins System, um zu schauen, wie weit es geht. Ein normaler Reboot bleibt nach wie vor beim Start des cron hängen. Grmpft. Aber ein Boot in Runlevel 2 geht und ein init 3 geht dann auch. Naja - jede Menge Fehlermeldungen - besonders iptables wird angemeckert, ein Netzwerk ist auch nicht zu bekommen.
sieh erstmal zu das du ein NW bekommst ...
So langsam komme ich an den Punkt, wo eine Neuinstallation weniger Arbeit ist.
nicht unbedingt
Installiertes System booten geht bis zum default runlevel, den könntest du in der inittab schon beim nachinstallieren der Pakete entsprechend runtersetzen um einen evtl. notwendigen turnaround zu verkürzen.
Naja - das kann man ja auch im Grub-Bootmenue wählen ...
nur wenn du über grub bootest, afair nicht wenn du installiertes system starten von der CD machst (das wo man hin kommt wenn man die installation abbricht wo ein CD Kernel geladen wird zum start der Distri). Das ist auch das was ich meinte, ich fürchte du hast zu früh versucht direkt über Grub zu starten.
Und da das Netzwerk nur da ist, wenn ich im Rescue-System boote und nicht, wenn ich das System selber boote ...
Also - noch eine Idee?
Ok dann eben totaler Handbetrieb, rpm -V `rpm -qa` stellt dir die info zur Verfügung wo es Abweichungen gibt zwischen der Paket-DB und den files der Pakete, darüber lässt sich abschätzen wie faul die Kiste wirklich ist. etwas ausführlicher nachzulesen in http://www.linuxfibel.de/swinstall.htm und wenn du einen Überblick hast wo es klemmt kannst du mit der rpm option --replacepkgs die pakete in Ordnung bringen die faul sind. btw: hast du mal spaßeshalber geschaut was in /etc/SuSE-version und bei den yast quellen steht? Nicht das da auch noch was altes angezogen wird. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Don, 15 Mär 2007, Falk Sauer schrieb:
rpm -V `rpm -qa`
rpm -Va -dnh -- What is the difference between Scientology and Microsoft? One is an evil cult bent on world domination and the other was begun by L. Ron Hubbard. (anonym von slashdot.org) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Falk,
du hast aber schon vorher die Pakete von denen du weist das sie abweichen (die mit den kernelmodulen) von hand aktualisiert?!? Durchaus auch mit Gewalt --force
bisher nur mit den zur Verfügung stehenden Automatismen.
So langsam komme ich an den Punkt, wo eine Neuinstallation weniger Arbeit ist.
nicht unbedingt
Doch, das sehe ich inzwischen so. "Handbetrieb" ist mir durch aus ein Begriff (LPIC), aber ich mag es nicht besonders - die Notwendigkeit ist immer ein Zeichen dafür, daß irgendwo schwer der Wurm drin ist. Zudem - zwar wäre eine Heilung hier möglich (ist immer machbar), dauert aber schlicht zu lange - nicht "wirtschaftlich", wenn man so will. Mit Neuinstallation und Nachziehen der Pakete bin ich wohl schneller - zumal ich mir ja noch eine Paketliste generieren kann. Ein weiterer Punkt: Wenn ich jetzt repariere, habe ich wieder ein System, das /boot auf einer Partition und den Rest auf LVs hat. Beim nächsten Kernelupdate fliegt mir der Kram also wieder um die Ohren, ja? Nein - darf natürlich nicht passieren, aber das hätte es diesmal auch nicht tun dürfen. Der LVM ist weit entfernt von der Stabilität, die ich von AIX oder Veritas kenne - ich habe jetzt einmal zuviel Ärger damit gehabt.
rpm -V `rpm -qa`
Liefert mit alleine schon 117 "Fehler". Ich könnte jetzt natürlich in jedem Einzelfall abfragen, zu welchem rpm das File gehört und diese Pakete dann nachinstallieren. Dennoch benörgelt er da noch Pakete, die zum alten Kernel gehören.
etwas ausführlicher nachzulesen in http://www.linuxfibel.de/swinstall.htm
Guter Link.
btw: hast du mal spaßeshalber geschaut was in /etc/SuSE-version und bei den yast quellen steht? Nicht das da auch noch was altes angezogen wird.
In der /etc/SuSE-release steht 10.2. Also - ich rette jetzt meine Daten von den LVs partitioniere und installiere neu. Sehr ärgerlich, da LVs für root eine schöne Möglichkeit bieten, online-Backups mit Snapshots zu machen. Mal sehen - ich werde mir wohl doch mal andere Möglichkeiten ansehen müssen (RedHat, Debian, BSD ...). Gruß Richard
Hallo Richard, hallo Gemeinde ! Richard Kampmann wrote / schrieb:
ich habe hier ein ziemlich fatales Problem nach dem letzten Kernel-Update auf 2.6.18.2-34-default.
Hintergrund. Auf dem Rechner läuft (bzw. lief) openSUSE 10.2 mit aktuellen Patches. /boot liegt auf /dev/sda2 / liegt auf einem Logical Volume (also eine Konfiguration, die in diesem Sinne so ähnlich ist, wie auf http://de.opensuse.org/SW-RAID_und_LVM beschrieben).
/ auf einer logical volume ... Vielleicht bin ich etwas konservativ, aber das würde ich persönlich nicht unbedingt machen. [...]
Jedenfalls war auch zu sehen, daß die Datei /boot/grub/menu.lst komplett neu geschrieben war - alle (!) alten Einträge, auch die von mir hinzugefügten, waren damit weg.
Du hast sicher übersehen, dass es auch noch eine Datei namens "menu.lst.old" gibt bzw. gab. Dies ist die ursprüngliche Konfiguration mit einem zusätzlichen Eintrag für den neuen Kernel. Ein einfaches Anpassen dieser Datei hätte die helfen können.
Langer Rede, kurzer Sinn - ich habe also eine neue Installation gemacht, das Update fand im Rahmen der Installation statt. Diesesmal habe ich ein neues LV angelegt in der Annahme, daß ich dann mit einer neu installierten /boot und der alten Rootpartition wieder booten könnte (nach entsprechendem Eintrag in der menu.lst).
Hattest Du es auch 'mal mit dem Rettungssystem vom Installationsmedium versucht ? [...]
PS: Schon lange frage ich mich, warum es keine Konfig gibt, die einem das alte Partitionsschema erspart (d.h. PV ist /dev/sda und fertig). Grub müßte damit klarkommen und es müßte eine entsprechende initrd geben ...
Im Prinzip könntest Du Recht haben. Da es aber immer wieder Probleme bereitet alle möglichen Fallstricke zu berücksichtigen, könnte ich mir vorstellen, dass es möglicherweise doch nicht ganz so einfach ist ... Bei vom Standard abweichenden Konfigurationen lohnt sich immer vor einer Verzweiflungstat ala Neuinstallation die Anwendung des Rettungssystems vom Installationsmedium. -- Never give up ! Best regards / Gruß, Reinhard. "Software is like a parachute. It doesn't work if it is not open." -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Wednesday 14 March 2007 09:08:46 Reinhard Gimbel wrote:
/ auf einer logical volume ... Vielleicht bin ich etwas konservativ, aber das würde ich persönlich nicht unbedingt machen.
Das war lange auch meine Einstellung. Aber inzwischen kann man ohne Probleme selbst eine alte / nachtraeglich auf LVM umziehen und mit mkinitrd die noetigen Module dazubasteln. Bisher (ich glaube seit Beginn der 9.3) noch keine Probleme gehabt. Bin allerdings vorsichtig mit der VG in der ich das Rootvolume habe.
"Software is like a parachute. It doesn't work if it is not open."
Der ist gut. :) Roman -- Roman Fietze Telemotive AG Büro Mühlhausen
Hallo Roman, hallo Gemeinde ! Roman Fietze wrote / schrieb:
On Wednesday 14 March 2007 09:08:46 Reinhard Gimbel wrote:
/ auf einer logical volume ... Vielleicht bin ich etwas konservativ, aber das würde ich persönlich nicht unbedingt machen.
Das war lange auch meine Einstellung. Aber inzwischen kann man ohne Probleme selbst eine alte / nachtraeglich auf LVM umziehen und mit mkinitrd die noetigen Module dazubasteln. Bisher (ich glaube seit Beginn der 9.3) noch keine Probleme gehabt.
Bin allerdings vorsichtig mit der VG in der ich das Rootvolume habe.
Na, dann bin ich wenigstens nicht alleine ...
"Software is like a parachute. It doesn't work if it is not open."
Der ist gut. :)
Der ist von houghi@houghi.org. Ich fand den so gut, dass ich einfach nicht widerstehen konnte ... -- Never give up ! Best regards / Gruß, Reinhard. "Software is like a parachute. It doesn't work if it is not open." -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Moin,
Du hast sicher übersehen, dass es auch noch eine Datei namens "menu.lst.old" gibt bzw. gab. Dies ist die ursprüngliche Konfiguration mit einem zusätzlichen Eintrag für den neuen Kernel.
Ein einfaches Anpassen dieser Datei hätte die helfen können.
die war glaube ich auch nicht vollständig. Naja - /daran/ hängt's nun auch nicht, eine menu.lst bekomme ich zur Not auch noch per Hand zusammengeschrieben. Entscheidender ist das Problem mit den Modulen. Hier werde mal Falks Vorschlag verfolgen.
Hattest Du es auch 'mal mit dem Rettungssystem vom Installationsmedium versucht ?
Ich hatte die diversen Reparaturversuche von Yast versucht - aber da gab es Fehlermeldungen, daß die Grub-Konfig nicht neu geschrieben werden konnte ... Bevor ich echte Handarbeit anfange, wollte ich hier mal fragen. Und chroot ist ja auch ein guter Gedanke.
Im Prinzip könntest Du Recht haben. Da es aber immer wieder Probleme bereitet alle möglichen Fallstricke zu berücksichtigen, könnte ich mir vorstellen, dass es möglicherweise doch nicht ganz so einfach ist ...
Stand ist wohl einfach, daß GRUB keine LVs lesen kann ...
Verzweiflungstat
:-) Ich werde doch niemanden umbringen (das bringt mich ja nicht weiter, auch wenn ich solche Gedanken schon hatte). Ich frage mich nur, wie man sowas machen kann - einen Kernel updaten, ohne die entsprechenden Module ... Wenn das Netz dann weg ist, kann man auch nichts nachziehen. Gruß Richard
participants (5)
-
David Haller
-
Falk Sauer
-
Reinhard Gimbel
-
Richard Kampmann
-
Roman Fietze