MaxPayne schrieb
Kann man daraus was machen?
Soweit ich es mir angeschaut habe eher nicht. Der letzte Patch ist von 05/2010...
Ich sehe - mit meinen Kenntnissen - auch eher die Ursache bei der Kernelbezeichnung vom Achlinux linuxPaket.
Üblich ist eigentlich Major.Minor.Patchlevel, also 3.0.2-ARCH statt (uname -r) 3.0-ARCH.
Wo der Sourcecode auf die Schnauze fällt ist wohl in sutil/ncpm_common.c
static int getmountver(void) {
struct utsname name;
int maj, mid, rev;
int ver;
if (uname(&name)) {
errexit(1, _("Cannot get kernel release\n"));
}
if (sscanf(name.release, "%d.%d.%d", &maj, &mid, &rev) != 3) {
errexit(2, _("Cannot convert kernel release \"%s\" to number\n"), name.release);
}
ver = maj*0x10000 + mid*0x100 + rev;
if (ver < 0x20100)
return 2;
if (ver < 0x20328)
return 3;
if (ver < 0x2051F)
return 4;
return 5;
}
Die variable ver würde hier aus 3*0x10000 plus 0*0x100 + "ARCH" gebildet, was mit Sicherheit keine korrekte Integer-Zahl ergibt.
//Edit: Bzw. er steigt hier: "if (sscanf(name.release, "%d.%d.%d", &maj, &mid, &rev) != 3)" mit errexit aus (Die meldung ist ja die englische für deinen Fehler.)
Da diese Funktion uname->name.release ja sicher nicht nur von diesem Programm so geprüft wird, könnte das Problem auch noch mit anderen Sourcen auftreten. &rev wird ja eindeutig von der Funktion als Dezimal erwartet, bekommt aber einen String (ARCH) serviert - peng....
Mal sehen ob ich einen Bugreport o.ä. zu unserem Linux-Paket finde...
Ein übler Hack wäre evtl. nur auf 2 Varaiblen in name.release zu prüfen (um den errexit zu umgehen) und die VARs maj, mid und rev fix zu setzen auf 3, 0 und 2....
//Edit 2: Ich habe mal einen Bugreport geschrieben zu der uname Geschichte:
https://bugs.archlinux.org/task/25727