Hallo, gerade habe ich gesehen, dass clodette:~ # rpm -qa | grep k_ k_deflt-2.4.21-0 k_deflt-2.4.21-0 k_deflt ist damit in der gleichen Version zweimal in der Datenbank eingetragen. Ich vermute, dass auch clodette:~ # rpm -e k_deflt Speicherzugriffsfehler damit zusammenhängt. Wie kann ich das beheben, damit ich wieder eine konsistente Datenbank habe und damit ich k_deflt entfernen kann und mit einem anderen kernel-default (2.6.1) überschreiben kann, dieser aber auch in der Datenbank eingetragen werden kann. Gruß Stefan
Stefan Schlörholz wrote:
gerade habe ich gesehen, dass
clodette:~ # rpm -qa | grep k_ k_deflt-2.4.21-0 k_deflt-2.4.21-0
k_deflt ist damit in der gleichen Version zweimal in der Datenbank eingetragen.
Eigentlich sollte das gar nicht moeglich sein...
Ich vermute, dass auch
clodette:~ # rpm -e k_deflt Speicherzugriffsfehler
damit zusammenhängt. Wie kann ich das beheben, damit ich wieder eine konsistente Datenbank habe und damit ich k_deflt entfernen kann und mit einem anderen kernel-default (2.6.1) überschreiben kann, dieser aber auch in der Datenbank eingetragen werden kann.
Was hast Du denn gemacht in letzter Zeit? Evtl. hilft es, die RPM Datenbank neu aufzubauen: rpm --rebuilddb. Allerdings solltest Du den Standard-Linux-Kernel der SuSE Distro NICHT mit dem neuen Kernel ersetzen, sondern parallel installieren. Mit "rpm -e k_deflt" bist Du da auf dem falschen Weg! Gruesse, Thomson
Thomas Hertweck schrieb am Donnerstag, 15. Januar 2004 19:18:
Stefan Schlörholz wrote:
Hallo Thomas,
gerade habe ich gesehen, dass
clodette:~ # rpm -qa | grep k_ k_deflt-2.4.21-0 k_deflt-2.4.21-0
k_deflt ist damit in der gleichen Version zweimal in der Datenbank eingetragen.
Eigentlich sollte das gar nicht moeglich sein...
Was hast Du denn gemacht in letzter Zeit? Evtl. hilft es, die RPM
Habe nichts gemacht, immer nur mit rpm -Fhv oder -Uhv installiert.
Datenbank neu aufzubauen: rpm --rebuilddb. Allerdings solltest Du
Werde ich mal probieren.
den Standard-Linux-Kernel der SuSE Distro NICHT mit dem neuen Kernel ersetzen, sondern parallel installieren. Mit "rpm -e k_deflt" bist Du da auf dem falschen Weg!
Bei rpm -Uvh kernel-default-26-2.6.1 gibt es ein Konfliktclodette:~ # rpm -Uvh kernel-default-26-2.6.1-0.i586.rpm Datei /boot/vmlinuz aus der Installation von kernel-default-26-2.6.1-0 steht im Konflikt mit Datei aus dem Paket k_deflt-2.4.21-0 Datei /boot/vmlinuz aus der Installation von kernel-default-26-2.6.1-0 steht im Konflikt mit Datei aus dem Paket k_deflt-2.4.21-0 Zur Installation des Pakets kernel-default-26-2.6.1-0 sind 2MByte auf dem Dateisystem /boot erforderlich Ich dache ich könnte das mit dem rpm -e mal ausprobieren zu lösen. Vielleicht solte ich doch aus den Quellen Quellen übersetzten und dann vmlinuz einen Suffix geben. Warum wird das in den Paketen nicht gleich gemacht. zumal es sich ja bei solchen Paketen immer um Updates oder Ergänzungen handelt. Diese System ist eh nur ein Spiel/Lernsyststem,wäre also nicht ganz so schlimm, wenn dabei etwasdrauf geht. Gruß Stefan
Stefan Schlörholz wrote:
[...] Bei rpm -Uvh kernel-default-26-2.6.1 gibt es ein Konfliktclodette:~ # rpm -Uvh kernel-default-26-2.6.1-0.i586.rpm Datei /boot/vmlinuz aus der Installation von kernel-default-26-2.6.1-0 steht im Konflikt mit Datei aus dem Paket k_deflt-2.4.21-0 Datei /boot/vmlinuz aus der Installation von kernel-default-26-2.6.1-0 steht im Konflikt mit Datei aus dem Paket k_deflt-2.4.21-0 Zur Installation des Pakets kernel-default-26-2.6.1-0 sind 2MByte auf dem Dateisystem /boot erforderlich
Das ist "normal" - RPM weigert sicht, zwei Kernel gleichzeitig zu installieren. Koennte es zudem sein, dass Deine Boot-Partition etwas volllaeuft?
Ich dache ich könnte das mit dem rpm -e mal ausprobieren zu lösen.
Siehe http://www.thomashertweck.de/kernel26.html zum parallelen Installieren mehrerer Kernel per RPM. "rpm -Uhv" darfst Du dabei eh nicht benutzen, das -U steht ja gerade fuer "Upgrade", also das ersetzen des alten Paketes durch das neue... Das solltest Du nicht tun, dann kannst Du, falls der neue Kernel nicht bootet, naemlich nicht mehr zurueck und musst den Umweg uebers Rettungssystem gehen.
Vielleicht solte ich doch aus den Quellen Quellen übersetzten und dann vmlinuz einen Suffix geben. Warum wird das in den Paketen nicht gleich gemacht. zumal es sich ja bei solchen Paketen immer um Updates oder Ergänzungen handelt.
Seit einiger Zeit sind die SuSE-Kernel so gebaut, dass System.map, initrd und auch das Kernel-Image selbst mit Versionsnummern versehen sind in /boot. Zusaetzlich gibt es aber glaube ich noch Links ohne Versionsnummer, die dann auf die jeweiligen Dateien mit Versionsnummer verweisen. Ich baue Kernel hier meistens aus den Quellen, da ich viele Dinge, die im SuSE-Kernel aktiviert sind, gar nicht brauche. Gerade beim Kernel oder den Kernel-Quellen ist es manchmal echt unhandlich, wenn sie im RPM Format kommen, da man dann eben ohne weiteres erst einmal nicht parallel installieren kann (ohne eine inkonsistente RPM-Datenbank in Kauf zu nehmen) - so nutze ich meist schlicht die Tar-Archive, die kann ich dann naemlich einfach hinpacken, wo ich moechte, und das ohne Probleme mit der RPM-Datenbank. In diesem Falle (und das ist IMHO einer von wenigen) macht das Installieren von Software, ohne dabei auf die RPM-Datenbank zu achten, ausnahmsweise mal Sinn...
Diese System ist eh nur ein Spiel/Lernsyststem,wäre also nicht ganz so schlimm, wenn dabei etwasdrauf geht.
Na dann, happy hacking! CU, Th.
Hallo, Am Thu, 15 Jan 2004, Thomas Hertweck schrieb:
ich meist schlicht die Tar-Archive, die kann ich dann naemlich einfach hinpacken, wo ich moechte, und das ohne Probleme mit der RPM-Datenbank. In diesem Falle (und das ist IMHO einer von wenigen) macht das Installieren von Software, ohne dabei auf die RPM-Datenbank zu achten, ausnahmsweise mal Sinn...
Full ACK! Theoretisch ist hier noch Kernel 2.2.10 installiert ;) Hm. Ich glaub, ich koennte das mal aus der RPM-DB entfernen... $ find /boot/ -name "bz*" -o -name "vml*" | wc -l 42 *lol* -dnh -- Braucht Ihr ab oder zunehmen ??? Ich benutze zur Zeit ein total tolles Zeug um abzunehmen. Es geht irre schnell und ist wunderbar. Es ist auch gebrauchlich zum zunehmen. Ihr koenntet auch business tun.....interestan nicht war ??? ['disa_linn@my-deja.com spammt mit viel Hirn in dag°]
Thomas Hertweck schrieb am Donnerstag, 15. Januar 2004 20:00:
Stefan Schlörholz wrote:
Hallo Thomas,
kernel-default-26-2.6.1-0 sind 2MByte auf dem Dateisystem /boot erforderlich
installieren. Koennte es zudem sein, dass Deine Boot-Partition etwas volllaeuft?
Habe ich gesehen. Kann ich in den Griff kriegen, es liegen da ziemlich viele Kernel rum, die weg können.
Ich dache ich könnte das mit dem rpm -e mal ausprobieren zu lösen.
Siehe http://www.thomashertweck.de/kernel26.html zum parallelen
Habe ich mir schon reingezogen, ist echt ne gute Anleitung, danke auch dafür.
Installieren mehrerer Kernel per RPM. "rpm -Uhv" darfst Du dabei eh nicht benutzen, das -U steht ja gerade fuer "Upgrade", also das
ist ja aber ein anderer Paketname k_deflt <-> kernel-default
Seit einiger Zeit sind die SuSE-Kernel so gebaut, dass System.map, initrd und auch das Kernel-Image selbst mit Versionsnummern versehen sind in /boot. Zusaetzlich gibt es aber glaube ich noch Links ohne Versionsnummer, die dann auf die jeweiligen Dateien mit Versionsnummer verweisen. Ich baue Kernel hier meistens aus den Quellen, da ich viele Dinge, die im SuSE-Kernel aktiviert sind, gar nicht brauche. Gerade beim Kernel oder den Kernel-Quellen ist es manchmal echt unhandlich, wenn sie im RPM Format kommen, da man dann eben ohne weiteres erst einmal nicht parallel installieren kann (ohne eine inkonsistente RPM-Datenbank in Kauf zu nehmen) - so nutze ich meist schlicht die Tar-Archive, die kann ich dann naemlich einfach hinpacken, wo ich moechte, und das ohne Probleme mit der RPM-Datenbank. In diesem Falle (und das ist IMHO einer von wenigen) macht das Installieren von Software, ohne dabei auf die RPM-Datenbank zu achten, ausnahmsweise mal Sinn...
Das hatte ich genau so auch schon im Sinn. Wenn mein anderer Kernel läuft, dann kann ich aber den alten noch nicht einmal entsorgen :-(
Na dann, happy hacking!
Ja ja, schlage mich auch noch mit nem Vanilla 2.4.24 auf nem Notebook rum, damit ich ndiswrapper installieren kann. Ich bin wohl der einzige, bei dem es nicht geht, obwohl ich mitlerweile eine .config von jemandem mit identischem Notebook habe. Jedenfalls bootet er schon mal weiter als ich es hinbekommen habe, obwohl ich die funktionierende .config meines 2.4.21 genommen hatte. ndiwrapper geht aber immer noch nicht. :-((((((( Gruß Stefan
Hallo, Am Fri, 16 Jan 2004, Stefan Schlörholz schrieb:
Thomas Hertweck schrieb am Donnerstag, 15. Januar 2004 20:00:
Stefan Schlörholz wrote: Siehe http://www.thomashertweck.de/kernel26.html zum parallelen
Habe ich mir schon reingezogen, ist echt ne gute Anleitung, danke auch dafür.
Du bist auch dem Link zum "Multikernel-Howto" gefolgt?
Installieren mehrerer Kernel per RPM. "rpm -Uhv" darfst Du dabei eh nicht benutzen, das -U steht ja gerade fuer "Upgrade", also das
ist ja aber ein anderer Paketname k_deflt <-> kernel-default
rpm -q --queryformat "%{provides} %{obsoletes}\n" Nicht alle Abhaengigkeiten sind allein auf dem Namen basiert. Mittels "obsoletes" lassen sich z.B. Pakete umbenennen: ==== Name: Xfree86 [..] %package devel Provides: xdevel Obsoletes: xdevel ==== Durch ein 'rpm -Uvh' wuerde so (wie bei SuSE der Fall) z.B. 'xdevel-3.3.x' als "Vorgaengerpaket" von 'XFree86-devel-4.x' erkannt und demzufolge ersetzt. Steht nun also z.B. im 'kernel-default' Paket ein Provides: k_deflt dann... s.o... -dnh -- "Given the choice of condoms, your gentialia turning green and dropping off, or celerycy^W clebrat^W not getting any, condoms are often a clear winner." -- Chris Hacking in the scary devil monastery
Am Do, 2004-01-15 um 19.18 schrieb Thomas Hertweck:
Stefan Schlörholz wrote:
gerade habe ich gesehen, dass
clodette:~ # rpm -qa | grep k_ k_deflt-2.4.21-0 k_deflt-2.4.21-0
k_deflt ist damit in der gleichen Version zweimal in der Datenbank eingetragen.
Eigentlich sollte das gar nicht moeglich sein...
Sollte. Ich hatte das Problem auch mal.
Ich vermute, dass auch
clodette:~ # rpm -e k_deflt Speicherzugriffsfehler
damit zusammenhängt. Wie kann ich das beheben, damit ich wieder eine konsistente Datenbank habe und damit ich k_deflt entfernen kann und mit einem anderen kernel-default (2.6.1) überschreiben kann, dieser aber auch in der Datenbank eingetragen werden kann.
[...] Damals hatte ich das Problem mit rpm -e --allmatches --nodeps <Paket-Name> # War hier cyrus-sasl rpm --rebuilddb rpm -i <RPM> Allerdings bin ich mir ziemlich unsicher, ob das bei einem Kernel-RPM so gut wäre. Aber vielleicht bringt es dich auf den richtigen Weg. Gruß Marcus
Am Do, 2004-01-15 um 20.17 schrieb Marcus Habermehl:
Am Do, 2004-01-15 um 19.18 schrieb Thomas Hertweck:
Stefan Schlörholz wrote:
gerade habe ich gesehen, dass
clodette:~ # rpm -qa | grep k_ k_deflt-2.4.21-0 k_deflt-2.4.21-0
k_deflt ist damit in der gleichen Version zweimal in der Datenbank eingetragen.
Eigentlich sollte das gar nicht moeglich sein...
Sollte. Ich hatte das Problem auch mal.
Ich vermute, dass auch
clodette:~ # rpm -e k_deflt Speicherzugriffsfehler
damit zusammenhängt. Wie kann ich das beheben, damit ich wieder eine konsistente Datenbank habe und damit ich k_deflt entfernen kann und mit einem anderen kernel-default (2.6.1) überschreiben kann, dieser aber auch in der Datenbank eingetragen werden kann.
[...]
Damals hatte ich das Problem mit
rpm -e --allmatches --nodeps <Paket-Name> # War hier cyrus-sasl rpm --rebuilddb rpm -i <RPM>
gelöst.
Allerdings bin ich mir ziemlich unsicher, ob das bei einem Kernel-RPM so gut wäre. Aber vielleicht bringt es dich auf den richtigen Weg.
Gruß
Marcus
Hallo, Am Thu, 15 Jan 2004, Marcus Habermehl schrieb:
Damals hatte ich das Problem mit
rpm -e --allmatches --nodeps <Paket-Name> # War hier cyrus-sasl rpm --rebuilddb rpm -i <RPM>
Allerdings bin ich mir ziemlich unsicher, ob das bei einem Kernel-RPM so gut wäre. Aber vielleicht bringt es dich auf den richtigen Weg.
Besser: rpm --rebuilddb Falls immer noch nicht korrigiert: rpm --justdb -e <Paketname> Und falls immer noch nicht: rpm --justdb -e <Paketname> rpm --rebuilddb rpm --justdb -i <Paketname> Das zumindest, wenn man das Paket nur einmal auf der Platte hat. -dnh -- Perl is a mess. But that's okay, because the problem space is also a mess. -- Larry Wall
Stefan Schlörholz schrieb am Donnerstag, 15. Januar 2004 18:08:
Hallo,
gerade habe ich gesehen, dass
clodette:~ # rpm -qa | grep k_ k_deflt-2.4.21-0 k_deflt-2.4.21-0
k_deflt ist damit in der gleichen Version zweimal in der Datenbank eingetragen. Ich vermute, dass auch
Die Lösung war tatsächlich rpm --rebuilddb Danke an alle für die konstruktiven Antworten. Eine Hürde weniger auf meinem vermutlich noch langen Weg. Gruß Stefen
participants (4)
-
David Haller
-
Marcus Habermehl
-
Stefan Schlörholz
-
Thomas Hertweck