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