# plötzlich macht gpm Probleme

## Christoph Schnauß

hallo,

ich habe mir auf einem Rechner, der relativ alt ist (Pentium II, 233 MHz, 256 MB RAM) Gentoo installiert und auf X-Server und grafische Oberfläche verzichtet - ich brauche ihn nur für Backups und teilweise als Server (Apache). Das geht ja auch ohne grafische Oberfläche. Um auf der Konsole mit der Maus gelegentlich was ausschneiden und woanders einfügen zu können, habe ich gpm benutzt - bisher.

Jetzt war es an der Zeit, auch auf diesem Rechner mal die "Welt" neu zu bauen, also habe ich ein "emerge -uD world" aufgerufen. Das läuft schön langsam (sind eben nur 233 MHz), und vor allem hält es bei gpm an. Natürlich gibt es Fehlermeldungen und ein log, das kriege ich im Moment aber nicht rüberkopiert auf einen Rechner, mit dem ich online gehen kann.

Weiß zufällig jemand, ob es für gpm irgendwelche beachtenswerten Neuerungen gibt? Ich habs erstmal unmerged, damit mir der Rest neu gebaut werden kann, was bei diesem Rechner zwei volle Tage dauern wird - schließlich sind da solche dicken Dinger wie ein neuer GCC dabei, und der alleine braucht auf diesem Rechner 16 Stunden ...

Aber ich hätte mein Mäuslein auf der Konsole halt gerne wieder.

Edit: es war nix mit "unmerge". Hab ich zwar laufenlassen, und mein Mäuslein ist von der Konsole verschwunden, aus den runlevels habe ich es mit "rc-update del ..." auch entfernt - aber wenn ich jetzt "emerge -uD system" aufrufe, fängt emerge trotzdem immer wieder mit gpm an und bricht nach zwei Minuten ab.

Es gibt irgendein log, oder einen Datenbankeintrag, in dem steht, daß "gpm" zwingend zu meinem "System" gehört. Das ist anscheinend durch mein unmerge (einschließlich  "eclean" und Rechnerneustart) aber nicht beeinflußt worden und verlangt weiterhin nach gpm. Wie korrigiere ich das?

Christoph S.Last edited by Christoph Schnauß on Sun Oct 28, 2007 11:47 pm; edited 1 time in total

----------

## s.hase

Da Du ja keine genaue Fehlermeldung geliefert hast kann man natürlich nur raten...

Eventuell der selbe Fehler wie bei mir letzte Woche:

https://bugs.gentoo.org/show_bug.cgi?id=195977

edit: Sonst halt mal in den anderen Bugs schauen.

----------

## Christoph Schnauß

hallo,

 *s.hase wrote:*   

> Da Du ja keine genaue Fehlermeldung geliefert hast kann man natürlich nur raten...

 Ich schrieb ja schon, daß ich das nicht kann, zumindest zur Zeit nicht. Der Rechner, auf dem mir das passiert ist, ist im Augenblick nicht in der Lage, online zu gehen bzw. übers lokale Netz Daten auszutauschen.

 *s.hase wrote:*   

> Eventuell der selbe Fehler wie bei mir letzte Woche:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=195977
> 
> edit: Sonst halt mal in den anderen Bugs schauen.

 

Hm. Ich kann die Bugtracker-Meldungen leider nicht verstehen und weiß nicht, wie ich da irgendwas für mich vielleicht Praktikables herauslesen könnte.

NB: ich mag _diesen_ Bugtracker einfach nicht. Das Ding bringt mich auch in anderen Umgebungen regelmäßig zur Verzweiflung :-(

----------

## Christoph Schnauß

hallo,

 *s.hase wrote:*   

> Da Du ja keine genaue Fehlermeldung geliefert hast kann man natürlich nur raten...

 

So, ich habe das log mal mit etwas Mühe herüberkopiert. Es gibt erstmal eine Menge solcher Meldungen:

```
mice.c:185: warning: pointer targets in initialization differ in signedness

mice.c:186: warning: pointer targets in initialization differ in signedness

mice.c:187: warning: pointer targets in initialization differ in signedness

```

Die sind offenbar unkritisch, das heißt, der Kompilierlauf geht erstmal weiter. Zum Abbruch kommt es dann mit diesen Einträgen:

```
special.c:158: error: 'OPEN_MAX' undeclared (first use in this function)

special.c:158: error: (Each undeclared identifier is reported only once

special.c:158: error: for each function it appears in.)

make[1]: *** [special.o] Error 1

make[1]: Leaving directory `/var/tmp/portage/sys-libs/gpm-1.20.1-r6/work/gpm-1.20.1/src'

make: *** [do-all] Error 1

 [31;01m*[0m 

 [31;01m*[0m ERROR: sys-libs/gpm-1.20.1-r6 failed.

 [31;01m*[0m Call stack:

 [31;01m*[0m              ebuild.sh, line 1695:  Called dyn_compile

 [31;01m*[0m              ebuild.sh, line 1033:  Called qa_call 'src_compile'

 [31;01m*[0m              ebuild.sh, line   44:  Called src_compile

 [31;01m*[0m   gpm-1.20.1-r6.ebuild, line   44:  Called die

 [31;01m*[0m The specific snippet of code:

 [31;01m*[0m      emake \

 [31;01m*[0m         CC=$(tc-getCC) \

 [31;01m*[0m         AR=$(tc-getAR) \

 [31;01m*[0m         RANLIB=$(tc-getRANLIB) \

 [31;01m*[0m         EMACS=: \

 [31;01m*[0m         || die "emake failed"

 [31;01m*[0m  The die message:

 [31;01m*[0m   emake failed
```

Ich habe keine Vorstellung, was ich dagegen tun sollte.

----------

## AmonAmarth

 *Christoph Schnauß wrote:*   

> 
> 
>  [31;01m*[0m ERROR: sys-libs/gpm-1.20.1-r6 failed.
> 
> 

 

also erstmal warum verwendest du die ~x86 version und nicht x86 ?

```
[I] sys-libs/gpm

     Available versions:  1.20.1-r4 1.20.1-r5 ~1.20.1-r6 {emacs selinux}

```

wegen einem neuen feature oder weil du accept_keywords ~x86 gesetzt hast?

wenn du kein neues feature davon brauchst würd ich dir mal empfehlen die x86 version zu nehmen indem du die ~x86 version in die package.mask einträgst, vielleicht funktioniert die ja gescheit.

ansonsten wenn du unbedingt die neue version benutzen willst solltest du noch weitere 10 zeilen mehr von der fehlermeldung posten. interssant ist meistens der erste eintrag einer fehlermeldung von der compiler ausgabe

mfg

----------

## zworK

 *Christoph Schnauß wrote:*   

> Edit: es war nix mit "unmerge". Hab ich zwar laufenlassen, und mein Mäuslein ist von der Konsole verschwunden, aus den runlevels habe ich es mit "rc-update del ..." auch entfernt - aber wenn ich jetzt "emerge -uD system" aufrufe, fängt emerge trotzdem immer wieder mit gpm an und bricht nach zwei Minuten ab.
> 
> Es gibt irgendein log, oder einen Datenbankeintrag, in dem steht, daß "gpm" zwingend zu meinem "System" gehört. Das ist anscheinend durch mein unmerge (einschließlich  "eclean" und Rechnerneustart) aber nicht beeinflußt worden und verlangt weiterhin nach gpm. Wie korrigiere ich das?
> 
> 

 

Möglich das es als Abhängigkeit durch das gpm USE-Flag wieder mit in die Liste rutscht. Falls ja, kannst du es ja temporär für das Update rausnehmen.

----------

## Christoph Schnauß

hallo,

 *AmonAmarth wrote:*   

> also erstmal warum verwendest du die ~x86 version und nicht x86 ?

 

Das ist mir als Update so angeboten worden.

 *AmonAmarth wrote:*   

> wegen einem neuen feature oder weil du accept_keywords ~x86 gesetzt hast?

 

Irgendwelche neuen Features sind mir gar nicht bekannt. ACCEPT_KEYWORDS="~x86" habe ich allerdings irgendwann mal gesetzt, weiß aber nicht mehr genau, warum. "emerge --info" sagt im Moment folgendes:

```
Portage 2.1.3.16 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.5-r3, 2.6.20.3 i686)

=================================================================

System uname: 2.6.20.3 i686 Pentium II (Klamath)

Timestamp of tree: Mon, 29 Oct 2007 11:50:01 +0000

ccache version 2.4 [disabled]

app-shells/bash:     3.2_p17-r1

dev-lang/python:     2.4.4-r4

dev-python/pycrypto: 2.0.1-r6

dev-util/ccache:     2.4-r7

sys-apps/baselayout: 1.12.10-r5

sys-apps/sandbox:    1.2.18.1-r2

sys-devel/autoconf:  2.13, 2.61-r1

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.18-r1

sys-devel/gcc-config: 1.4.0-r4

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.23

ACCEPT_KEYWORDS="x86 ~x86"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=i686 -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"

CXXFLAGS="-O2 -march=i686 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="CCACHE distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ http://gentoo.intergenia.de "

LINGUAS="de"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="berkdb bitmap-fonts cli cracklib crypt dri fortran gdbm gpm iconv midi mudflap ncurses nls nptl nptlonly openmp pam pcre perl ppds python readline reflection session spl ssl tcpd unicode x86 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
```

 *AmonAmarth wrote:*   

> wenn du kein neues feature davon brauchst würd ich dir mal empfehlen die x86 version zu nehmen indem du die ~x86 version in die package.mask einträgst, vielleicht funktioniert die ja gescheit.

 

Nein, das tut es auch nicht, obwohl dann gpm-1.20.1-r5 genommen wird.

 *AmonAmarth wrote:*   

> ansonsten [...] solltest du noch weitere 10 zeilen mehr von der fehlermeldung posten. interssant ist meistens der erste eintrag einer fehlermeldung von der compiler ausgabe

 

Bittesehr:

```
>>> Unpacking source...

>>> Unpacking gpm-1.20.1.tar.bz2 to /var/tmp/portage/sys-libs/gpm-1.20.1-r5/work

>>> Unpacking gpm-1.20.1-patches-1.4.tar.bz2 to /var/tmp/portage/sys-libs/gpm-1.20.1-r5/work

 [32;01m*[0m Applying various patches (bugfixes/updates) ...

 [32;01m*[0m   01_all_info.patch ...

[...]

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/sys-libs/gpm-1.20.1-r5/work/gpm-1.20.1 ...

./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/lib --sysconfdir=/etc/gpm --build=i686-pc-linux-gnu

creating cache ./config.cache

checking for gcc... gcc

[...]

updating cache ./config.cache

creating ./config.status

creating Makefile.include

creating Makefile

[...]

touch src/.depend # to prevent unecessary warnings

make -C src dep

make[1]: Entering directory `/var/tmp/portage/sys-libs/gpm-1.20.1-r5/work/gpm-1.20.1/src'

[...]

gpm.c: In function 'getMouseData':

gpm.c:380: warning: pointer targets in initialization differ in signedness

gpm.c:399: warning: pointer targets in return differ in signedness

gpm.c:430: warning: pointer targets in return differ in signedness

gpm.c: In function 'processMouse':

gpm.c:482: warning: pointer targets in passing argument 2 of 'which_mouse->m_type->fun' differ in signedness

gpm.c: In function 'old_main':

gpm.c:1123: warning: value computed is not used

gpm.c: In function 'open_console':

gpm.c:172: warning: control reaches end of non-void function

gpm.c:165: warning: 'si.line' is used uninitialized in this function

gpm.c: In function 'get_console_size':

gpm.c:165: warning: 'si.line' is used uninitialized in this function

gpm.c: In function 'processMouse':

gpm.c:165: warning: 'si.line' is used uninitialized in this function

gpm.c: In function 'old_main':

gpm.c:165: warning: 'si.line' is used uninitialized in this function

gpm.c:165: warning: 'si.line' is used uninitialized in this function

i686-pc-linux-gnu-gcc -I/var/tmp/portage/sys-libs/gpm-1.20.1-r5/work/gpm-1.20.1/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR="\"/etc/gpm\"" -DSBINDIR="\"/usr/sbin\""  -O2 -march=i686 -pipe -O2 -march=i686 -pipe -c -o gpn.o gpn.c

gpn.c: In function 'loadlut':

gpn.c:108: warning: pointer targets in passing argument 1 of 'getsym' differ in signedness

gpn.c:110: warning: pointer targets in passing argument 1 of 'getsym' differ in signedness

i686-pc-linux-gnu-gcc -I/var/tmp/portage/sys-libs/gpm-1.20.1-r5/work/gpm-1.20.1/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR="\"/etc/gpm\"" -DSBINDIR="\"/usr/sbin\""  -O2 -march=i686 -pipe -O2 -march=i686 -pipe -c -o mice.o mice.c

mice.c:170: warning: type qualifiers ignored on function return type

mice.c: In function 'option_modem_lines':

mice.c:185: warning: pointer targets in initialization differ in signedness

mice.c:186: warning: pointer targets in initialization differ in signedness

mice.c:187: warning: pointer targets in initialization differ in signedness

mice.c: In function 'M_gunze':

mice.c:1323: warning: pointer targets in passing argument 1 of 'sscanf' differ in signedness

i686-pc-linux-gnu-gcc -I/var/tmp/portage/sys-libs/gpm-1.20.1-r5/work/gpm-1.20.1/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR="\"/etc/gpm\"" -DSBINDIR="\"/usr/sbin\""  -O2 -march=i686 -pipe -O2 -march=i686 -pipe -c -o special.o special.c

special.c: In function 'processSpecial':

special.c:158: error: 'OPEN_MAX' undeclared (first use in this function)

special.c:158: error: (Each undeclared identifier is reported only once

special.c:158: error: for each function it appears in.)

make[1]: *** [special.o] Error 1

make[1]: Leaving directory `/var/tmp/portage/sys-libs/gpm-1.20.1-r5/work/gpm-1.20.1/src'

make: *** [do-all] Error 1

 [31;01m*[0m 

 [31;01m*[0m ERROR: sys-libs/gpm-1.20.1-r5 failed.

 [31;01m*[0m Call stack:

 [31;01m*[0m              ebuild.sh, line 1695:  Called dyn_compile

 [31;01m*[0m              ebuild.sh, line 1033:  Called qa_call 'src_compile'

 [31;01m*[0m              ebuild.sh, line   44:  Called src_compile

 [31;01m*[0m   gpm-1.20.1-r5.ebuild, line   43:  Called die

 [31;01m*[0m The specific snippet of code:

 [31;01m*[0m      emake \

 [31;01m*[0m         CC=$(tc-getCC) \

 [31;01m*[0m         AR=$(tc-getAR) \

 [31;01m*[0m         RANLIB=$(tc-getRANLIB) \

 [31;01m*[0m         EMACS=: \

 [31;01m*[0m         || die "emake failed"

 [31;01m*[0m  The die message:

 [31;01m*[0m   emake failed
```

Ich habe jetzt nur das rausgeschnitten, was wirklich nix Wichtiges darstellt.

----------

## Christoph Schnauß

 *zworK wrote:*   

> Möglich das es als Abhängigkeit durch das gpm USE-Flag wieder mit in die Liste rutscht. Falls ja, kannst du es ja temporär für das Update rausnehmen.

 

Irgendwo muß da wohl so ein USE drinstehen, ja. Hm. Ok, ich probiers mal mit einem -gpm bei den USE-flags in der make.conf, mal schauen.

----------

## Christoph Schnauß

so, jetzt ist der absolute Crash passiert:

Ich habe mir die einzelnen Pakete, die ich mit "emerge -puD" angezeigt bekam, dann eben einzeln gebaut. Und weil es mit "emerge -uD [Paketname" immer an gpm hängenblieb, habe ich eben auf das Update verzichtet, also beispielsweise "emerge gcc" angegeben.

GCC und die glibc liefen jeweisl auf eienr Konsole, und das ging ein paar Stunden ganz gut. Ich habe ungefähr jede Stunde mal nachgeschaut - aber ich wußte ja von früher, daß die beiden jeweils etwa 12 Stunden brauchen.

Aber jetzt ist etwas passiert, was ich überhaupt nicht einordnen kann: mein Monitor zeigt plötzlich gar nichts mehr. Es bleibt schwarz. Es blieb mir also schweren Herzens gar nichts anderes übrig, als den Rechner ganz auszuschalten.

Das Ding ist ein acht Jahre alter Pentium II mit 233 MHZ und 256 MB RAM. Daß der "langsam" ist, wußte ich vorher.  Glücklicherweise habe ich auf einer anderen Platte noch ein Windows (Win98) und habe das jetzt mal hochgefahren - funktioniert.

Bootmanager ist LILO. Ich hätte zwar lieber GRUB genommen, aber der kriegt mein altes BIOS nicht auf die Reihe. Es geht nur mit LILO.

So, und nun ist mein Gentoo komplett nicht mehr erreichbar. Es scheint noch zu starten, ich kriege aber auf dem Monitor nicht einmal mehr die üblichen Startmeldugen zu sehen. 

Gibt es irgendeine andere Rettung, als jetzt von der CD zzu booten und mein Gentoo komplett neu einzuspielen?

----------

## ComicBookGuy

Ich hab nicht wirklich eine Lösung für Dich, aber ich hätte ein paar Gedanken   :Smile:  .

Du könntest ja versuchen, das System über eine Live-Cd zu retten.

Das hat man mir damals geraten 

 *Quote:*   

>  This is what I would do:
> 
> reboot into a LiveCD (I'd suggest Knoppix so you have a working system while doing this)
> 
> chroot into your Gentoo install
> ...

 

Du kannst ja dein Problem im englischsprachigen Forum stellen, falls Du das nicht schon getan hast.

Was jetzt nicht mit deinem Problem zu tun hat: vielleicht könntest Du mit verteiltem Kompilieren (distcc oder so) Zeit beim Kompilieren sparen.

Meine 2 Pfennige

----------

## Christoph Schnauß

 *Zuriya wrote:*   

> Ich hab nicht wirklich eine Lösung für Dich, aber [...] Du könntest ja versuchen, das System über eine Live-Cd zu retten.

 

Hrm. Ja, könnte ich. Das dauert auf diesem Rechner bloß wieder volle drei Tage, wäre keine "Rettung", sondern eine komplette Neuinstallation einschließlich Formatierung, und das wollte ich eigentlich gerne vermeiden. Alles, was ich an "Daten" habe, liegt glücklicherweise auf einer anderen Platte und wird von irgendwelchen Hampeleien am Betriebssystem überhaupt nicht berührt.

 *Zuriya wrote:*   

> Meine 2 Pfennige

 

Ups? In welcher Währung soll ich die dir jetzt überweisen? Ich habe aus reiner Melancholie noch etliche "Pfennige" in DDR-Währung hier herumliegen. Aber ein DDR-Pfennig hätte heute vermutlich nur noch ungefähr 0,002 Eurocent Kaufkraft - es sei denn, du bist ein Sammler, der für ein so seltenes Tück mal generös einen 50er-Schein rüberwachsen läßt ...

----------

