Fehler bei apt-get upgrade durch Kernel

N

nighT

Hallo Leute,
nun habe ich seit langem mal wieder ein Problem, bei dem ich nicht weiß, wie ich mich verhalten soll.X(
Als ich gerade ein apt-get upgrade durchführen wollte ist mir aufgefallen, dass der Kernel einen Fehler meldet:
Code:
# apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? j
Richte linux-image-2.6.28.6-grsec-xxxx-std-ipv6-64 ein (etch.personal1) ...
Running depmod.
vmlinuz(/boot/vmlinuz-2.6.28.6-grsec-xxxx-std-ipv6-64
) points to /boot/vmlinuz-2.6.28.6-grsec-xxxx-std-ipv6-64
 (/boot/vmlinuz-2.6.28.6-grsec-xxxx-std-ipv6-64) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.28.6-grsec-xxxx-std-ipv6-64.postinst line 588.
Running postinst hook script update-grub.
User postinst hook script [update-grub] failed to execute: Datei oder Verzeichnis nicht gefunden
dpkg: Fehler beim Bearbeiten von linux-image-2.6.28.6-grsec-xxxx-std-ipv6-64 (--configure):
 Unterprozess post-installation script gab den Fehlerwert 255 zurück
Fehler traten auf beim Bearbeiten von:
 linux-image-2.6.28.6-grsec-xxxx-std-ipv6-64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Bei dem Kernel handelt es sich um den Standartkernel von OVH. Desweiteren wundert es mich, dass er versucht update-grub auszufüren, da ich lilo benutze.

Wie soll ich mich weiter verhalten? Ein apt-get -f install hat nicht geholfen.

mfg nighT
 
Standard bitte mit d am Ende. Was ist denn OVH?
 
Hi,

und wir duerfen jetzt die Distribution raten? Dann fang ich mal an: Squeeze? ;)

Bei dem Kernel handelt es sich um den Standartkernel von OVH.
Was immer OVH ist.

Desweiteren wundert es mich, dass er versucht update-grub auszufüren, da ich lilo benutze.
Da scheint ja auch das Problem zu sein. Fuer mich sieht das stark nach einem Bug in dem package aus, vermutlich wird einfach davon ausgegangen dass grub verwendet wird, statt nach Alternativen zu suchen. Du koenntest z.B. mal einen Blick in die postinst werfen, und gucken was da steht (/var/lib/dpkg/info/$pkg_name.postinst).

Wenn da Unsinn drin steht, koennte eventuell eine Korrektur in der Datei mit anschliessendem 'dpkg-reconfigure $pkg_name' helfen.

Edit:
Standard bitte mit d am Ende.
Stimmt, das wollte ich auch noch gesagt haben. Es geht schliesslich weder um Stand-Arten noch um eine Standarte. ;)
Bei Standart muss ich mir immer User vorstellen die stolz mit ihren Standarten auf und ab marschieren. ;)

mfg,
bytepool
 
Zuletzt bearbeitet:
Mal apt das Paket neu runterladen lassen? (Ich hatte so etwas in der Art mal bei einem Paket, dass beim runterladen kaputt gegangen ist und dann rumgezickt hat.)
 
Standard bitte mit d am Ende. Was ist denn OVH?
Tut mir leid. Natürlich mit d. Ich war an dem Zeitpunkt des Verfassens leicht übermüdet :brav:
OVH ist ein französischer Hoster (Server, etc)
bytepool schrieb:
und wir duerfen jetzt die Distribution raten? Dann fang ich mal an: Squeeze?
Natürlich auch mein Fehler. Wie geasgt..übermüdet..
Es handelt sich um Debian Lenny
bytepool schrieb:
Fuer mich sieht das stark nach einem Bug in dem package aus, vermutlich wird einfach davon ausgegangen dass grub verwendet wird, statt nach Alternativen zu suchen. Du koenntest z.B. mal einen Blick in die postinst werfen, und gucken was da steht (/var/lib/dpkg/info/$pkg_name.postinst).
Habe mir die Datei mal angeschaut. Es wird aber auf unterschiedliche Bootloader getestet. Unter anderem eben auch LILO.
sinn3r schrieb:
Mal apt das Paket neu runterladen lassen? (Ich hatte so etwas in der Art mal bei einem Paket, dass beim runterladen kaputt gegangen ist und dann rumgezickt hat.)
Diesen Gedanken hatte ich bereits. Aber ich traue mich nicht so recht. Was würde passieren, wenn ich das Paket deinstalliere und später nicht erneut installieren kann? Dann fehlt mir ein Kernel. Könnte sich leicht Negativ auf die Funktion des Servers ausüben :D
 
Hmm, Kernel-Updates auf root-Servern sind immer so eine Sache. Wenns beruflich genutzt wird, würde ich KVM-over-IP verwenden, um kurze Downtimes sicherzustellen. Sonst bleibt einem nach dem Neustart ja nur zu beten und sich zu wundern, warum es nicht geht. Das einfachste wäre wahrscheinlich, ein sauberes Originalkernelpaket zu benutzen, spricht da was gegen? Ansonsten wäre es auch eine Idee, dich mit dem Ersteller des Pakets auseinanderzusetzen.

Ansonsten: Kannst du das postinst-Skript bitte einmal posten?
 
Hm, warum steht dann aber oben in der Ausgabe was von etch?
 
man kernel-img.conf

Welche sich uebrigens im package kernel-package befindet.

Aber weil es so schoen passt, hier mal kurz was mir eben selber passiert ist:

nfs-common wollte sich auf einer meiner Lenny Maschinen nicht installieren lassen, das postinst Skript brach mit Fehlerwert 20 ab.
Das Skript startete wie so oft mit '#!/bin/sh -e', also dachte ich mir, clever wie ich bin, machen wir doch aus dem e ein x, ohne genau zu wissen was das e eigentlich macht (denn -e -x wollte er nicht). ;)

Das gab mir zwar den gewuenschten Debug output, sorgte aber auch dafuer dass das Skript ploetzlich durchlief, und nfs-common "sauber" installiert wurde. ;)

Eine kurze Recherche ergab folgenden Link: http://blog.andrew.net.au/2009/11/20
Recht hat er, denn so aehnlich ist es mir passiert, was aber in diesem Fall wohl eher eine glueckliche Dummheit war. Ich weiss zwar dadurch nicht was eigentlich genau falsch lief, aber da das Skript extrem simpel ist, ist es auch voellig egal, ich nehme an das einfach nur ein update-rc.d oder so nicht sauber ausgefuehrt werden konnte.

Fuer die Leute die wie ich nicht wissen wofuer die Option -e steht, dadurch wird das Skript abgebrochen sobald eine Funktion, die nicht in einer Bedingung steht, nicht Null zurueck gibt (retVal != 0).

Also um nochmal konkret zum urspruenglichen Thema dieses Threads zurueck zu kommen, du koenntest auch einfach am Anfang des postinst Skripts set -x setzen, um zu gucken wo er sich genau aufhaengt.

Spaetes Edit:
Sollte hier mal jemand drueber stolpern, der auch Probleme mit dem postinst Skript von einigen Paketen hat: In meinem Fall lag es daran dass Verbose=1 in /etc/ucf.conf gesetzt war. Ein Bug in ucf sorgt dafuer, dass Verbose=1 ucf zu fehlerhaftem Verhalten animiert, weil es dann debconf durcheinander bringt. Das liegt aber auch an dem komischen Design von debconf, es benutzt stdin um Befehle entgegen zu nehmen... Jedenfalls fehlt in ucf bei einigen echo's die Umleitung zu stderr (>&2).
Werde einen Bug report schreiben. Bug filed: #577127

mfg,
bytepool
 
Zuletzt bearbeitet:
Welche sich uebrigens im package kernel-package befindet.
Tut es nicht ... was Du meinst ist /etc/kernel-pkg.conf welches Konfigurationen für selbst gebaute Kernel-Images enthält (daher macht es auch Sinn, dass ins Paket kernel-package zu packen)

/etc/kernel-img.conf enthält stattdessen Konfigurationen für die Installation von Kernel-Image-Paketen ... u.a. auch Hooks für den Bootloader.
 
Tut es nicht ... was Du meinst ist /etc/kernel-pkg.conf welches Konfigurationen für selbst gebaute Kernel-Images enthält
Noe.
Code:
$ apt-file list kernel-package | grep kernel-img.conf
kernel-package: /usr/share/doc/kernel-package/examples/sample.kernel-img.conf
kernel-package: /usr/share/man/man5/kernel-img.conf.5.gz
Dann musst du ein anderes Lenny haben als ich. ;)
Ich meinte die manpage, nicht die Datei selbst, falls du mich da falsch verstanden haben solltest.

mfg,
bytepool
 

Ähnliche Themen

Keine grafische Oberfläche (Debian Installation)

grub-pc Probleme bei upgrade

Problem bei apt-get upgrade (Kali 2.0)

wie Alte Kernelversionen unter Debian entfernen

Kernel Panic GRUB 2

Zurück
Oben