Am 25.11.2011 19:57, schrieb Dirk Vornheder:

...

Nach dem Wechsel von openSUSE 11.3 auf openSUSE 12.1 per Neuinstallation

der openSUSE-Version funktioniert der unter openSUSE 11.3 problemlos

laufende Kartenleser

SCM Microsystems, Inc. SCR3340 - ExpressCard54 Smart Card Reader

mit Moneylex 11.0 Standard Build 19905 nicht mehr, d.h. der Zugriff

klappt nicht mehr.

U.a. sind folgende RPMs installiert:

pcsc-ccid-1.4.5-26.1.i586 pcsc-ctapi-wrapper-0.3-2.1.i586 pcsc-lite-1.8.0-65.1.i586 pcsc-lite-devel-1.8.0-65.1.i586 perl-pcsc-1.4.10-11.1.i586 libpcsclite1-1.8.0-65.1.i586 pcsc-openct-0.6.20-29.1.i586 pcsc-tools-1.4.17-1.1.i586 libpcscspy0-1.8.0-65.1.i586

Bitte geh mal zurück auf die 12.1 Version von pcsc-lite (1.7.4). Ich hab den Verdacht, dass es an der neuen Version 1.8.x liegt. Und gib bitte Bescheid, ob es dann wieder läuft. Müssen wir dann mal genau checken, woran der Fehler liegt, wenn wir das verifiziert haben.

Nach dem Löschen der ganzen Pakete habe ich die alte Version 1.7.4 installiert, aber pcscd läßt sich nicht mehr starten: /etc/init.d/pcscd restart redirecting to systemctl Failed to issue method call: Unit pcscd.service failed to load: No such file or directory. See system logs and 'systemctl status pcscd.service' for details. systemctl status pcscd.service pcscd.service Loaded: error (Reason: No such file or directory) Active: failed since Sat, 26 Nov 2011 12:00:38 +0100; 25min ago Main PID: 8805 (code=exited, status=1/FAILURE) Deswegen habe ich die neue Version 1.8.1 installiert, aber auch die läßt sich nicht starten: pcsc-lite-devel-1.8.1-64.1.i586 pcsc-towitoko-2.0.7-379.1.i586 pcsc-ccid-1.4.5-26.1.i586 pcsc-ctapi-wrapper-0.3-2.1.i586 libpcscspy0-1.8.1-64.1.i586 perl-pcsc-1.4.10-11.1.i586 pcsc-openct-0.6.20-29.1.i586 pcsc-lite-1.8.1-64.1.i586 pcsc-towitoko-devel-2.0.7-379.1.i586 pcsc-cyberjack-3.99.5final.SP02-57.1.i586 libpcsclite1-1.8.1-64.1.i586 pcsc-tools-1.4.17-1.2.i586 Nov 26 11:48:52 lappc pcscd[4545]: Unknown option: Nov 26 11:48:52 lappc pcscd[4545]: Usage: /usr/sbin/pcscd options Nov 26 11:48:52 lappc pcscd[4545]: Options: Nov 26 11:48:52 lappc pcscd[4545]: -a, --apdu#011#011log APDU commands and results Nov 26 11:48:52 lappc pcscd[4545]: -c, --config#011#011path to reader.conf Nov 26 11:48:52 lappc pcscd[4545]: -f, --foreground#011run in foreground (no daemon), Nov 26 11:48:52 lappc pcscd[4545]: send logs to stdout instead of syslog Nov 26 11:48:52 lappc pcscd[4545]: -T, --color#011#011force use of colored logs Nov 26 11:48:52 lappc pcscd[4545]: -h, --help#011#011display usage information Nov 26 11:48:52 lappc pcscd[4545]: -H, --hotplug#011#011ask the daemon to rescan the available readers Nov 26 11:48:52 lappc pcscd[4545]: -v, --version#011#011display the program version number Nov 26 11:48:52 lappc systemd[1]: pcscd.service: main process exited, code=exited, status=1 Nov 26 11:48:52 lappc pcscd[4545]: -d, --debug#011#011display lower level debug messages Nov 26 11:48:52 lappc pcscd[4545]: --info#011#011display info level debug messages Nov 26 11:48:52 lappc pcscd[4545]: -e --error#011#011display error level debug messages (default level) Nov 26 11:48:52 lappc pcscd[4545]: -C --critical#011display critical only level debug messages Nov 26 11:48:52 lappc pcscd[4545]: --force-reader-polling ignore the IFD_GENERATE_HOTPLUG reader capability Nov 26 11:48:52 lappc pcscd[4545]: -t, --max-thread#011maximum number of threads (default 200) Nov 26 11:48:52 lappc pcscd[4545]: -s, --max-card-handle-per-thread#011maximum number of card handle per thread (default: 200) Nov 26 11:48:52 lappc pcscd[4545]: -r, --max-card-handle-per-reader#011maximum number of card handle per reader (default: 200) Nov 26 11:48:52 lappc pcscd[4545]: -x, --auto-exit#011pcscd will quit after 60 seconds of inactivity Nov 26 11:48:52 lappc systemd[1]: Unit pcscd.service entered failed state. Grüße, Dirk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

On Sun, Nov 27, 2011 at 01:32:06PM +0100, Wolfgang Rosenauer wrote:

Am 27.11.2011 12:02, schrieb Dirk Vornheder:

...

...

Bitte geh mal zurück auf die 12.1 Version von pcsc-lite (1.7.4). Ich hab den Verdacht, dass es an der neuen Version 1.8.x liegt. Und gib bitte Bescheid, ob es dann wieder läuft. Müssen wir dann mal genau checken, woran der Fehler liegt, wenn wir das verifiziert haben.

Nach dem Löschen der ganzen Pakete habe ich die alte Version 1.7.4

installiert, aber pcscd läßt sich nicht mehr starten:

/etc/init.d/pcscd restart

redirecting to systemctl

Failed to issue method call: Unit pcscd.service failed to load: No such file or directory. See system logs and 'systemctl status pcscd.service' for details.

systemctl status pcscd.service pcscd.service Loaded: error (Reason: No such file or directory) Active: failed since Sat, 26 Nov 2011 12:00:38 +0100; 25min ago Main PID: 8805 (code=exited, status=1/FAILURE)

Argl, da muss jemand mit systemd Wissen ran. Hintergrund ist, dass pcsc-lite 1.8.x von sysvinit auf systemd umgestiegen ist. Dabei passiert irgendwas magisches. Offensichtlich ist der Rückweg nicht so ohne weiteres möglich :-(

Hm, warum sind da nicht beide Varianten dabei? Wenn es einen systemd Service gibt, dann wird das gleichzeitig vorliegende sysvinit-Skript einfach ignoriert. So zumindestends die Theorie. Und weshalb nicht vorerst weiterhin sysvinit benutzen? systemd ist so frisch und appetitlich wie ein dampfender Kuhfladen. ;) Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Sun, Nov 27, 2011 at 02:42:04PM +0100, Wolfgang Rosenauer wrote:

Am 27.11.2011 14:24, schrieb Lars Müller: [ 8< ]

...

Hm, warum sind da nicht beide Varianten dabei? Wenn es einen systemd Service gibt, dann wird das gleichzeitig vorliegende sysvinit-Skript einfach ignoriert. So zumindestends die Theorie.

Es sind beide Varianten dabei. Aber offensichtlich hat sich systemd gemerkt, dass zu dem sysvinit File ein systemd service gehört und will weiterhin diesen verwenden.

Aber das ist doch vom Design her auch richtig. Oder? Wenn ein systemd-Service existiert, dann muss ein ebenso vorliegendes sysvinit-Skript ignoriert werden. Ansonsten haben wir am Ende den zur Frage stehenden Dienst zwei Mal gestartet. Oder zwei Prozesse treten oder stehen sich gegenseitig auf den Füßen.

Vielleicht reicht da ja irgendein "reload" im postun oder wie auch immer. Das neue Paket hält sich aber an die verfügbare Dokumentation. Die scheint nur nicht komplett zu sein.

Ein Geschmarrn ist sie! Aber das gehört so, wie ein Freund gerade am Telefon meinte. Überhaupt sind 76,275% des systemd-Zeugs sehr mit der heißen Nadel gestrickt ist. Teeren und federn und aus der Stadt jagen die dafür Verantwortlichen! Permanente wiederkehrende Geschlechts- krankheiten für die nächsten zehn Jahre! Mit mir eine Woche jeden Tag acht Stunden einen Raum teilen! Fallen wem noch härtere Strafen ein? ;)

...

Und weshalb nicht vorerst weiterhin sysvinit benutzen? systemd ist so frisch und appetitlich wie ein dampfender Kuhfladen. ;)

Offensichtlich. Aber wir werden ja doch nicht drum herum kommen. Also muss man irgendwann umstellen und wohl leider auch Schmerzen in Kauf nehmen.

Oh, wenn der Schmerz zu gross ist, dann hilft nur eine Resektion. Momentan ist mir der Schmerz eindeutig noch viel, viel zu gross. Jeder der ein Linux schon ein wenig länger und für mehr als einen 0815-Desktop einsetzt sollte das mitbekommen haben. Je mehr Nutzer zeigen, dass es so einfach wie gedacht doch nicht geht, desto klarer wird, dass sysvinit auch in der nächsten Version noch benötigt wird. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Am Sonntag, den 27.11.2011, 15:53 +0100 schrieb Wolfgang Rosenauer:

Am 27.11.2011 15:41, schrieb Lars Müller:

...

On Sun, Nov 27, 2011 at 02:42:04PM +0100, Wolfgang Rosenauer wrote:

...

Am 27.11.2011 14:24, schrieb Lars Müller: [ 8< ]

...

Hm, warum sind da nicht beide Varianten dabei? Wenn es einen systemd Service gibt, dann wird das gleichzeitig vorliegende sysvinit-Skript einfach ignoriert. So zumindestends die Theorie.

Es sind beide Varianten dabei. Aber offensichtlich hat sich systemd gemerkt, dass zu dem sysvinit File ein systemd service gehört und will weiterhin diesen verwenden.

Aber das ist doch vom Design her auch richtig. Oder?

Wenn ein systemd-Service existiert, dann muss ein ebenso vorliegendes sysvinit-Skript ignoriert werden. Ansonsten haben wir am Ende den zur Frage stehenden Dienst zwei Mal gestartet. Oder zwei Prozesse treten oder stehen sich gegenseitig auf den Füßen.

Entscheidend ist, dass der Downgrade von 1.8.x auf 1.7.4 auch den systemd Service entfernt aber das init script trotzdem nicht wieder funktioniert.

Wolfgang

Hallo Leute, ich habe gerade auf die 12.1 umgestellt. (Neuinstallation) Wenn ich versuche Moneyplex zu starten bekomme ich folgende Meldung: /home/......./moneyplex/start Runtime error 230 at 0805C77D /home/......./moneyplex/start: Zeile 30: 6891 Speicherzugriffsfehler "$APPPATH/$APPNAME" Hilft das jemandem? ..... mir nicht!? Bin fürjeden Rat dankbar. Gruß Mario -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

On Sun, Nov 27, 2011 at 04:41:16PM +0100, Torsten Förtsch wrote:

On Sunday, 27 November 2011 15:41:30 Lars Müller wrote:

...

Je mehr Nutzer zeigen, dass es so einfach wie gedacht doch nicht geht, desto klarer wird, dass sysvinit auch in der nächsten Version noch benötigt wird.

Gibt es irgendwo eine Protestliste, in die man sich eintragen kann?

Mir fällt nur openFATE ein. Dort einen der folgenden Feature-Request alternativ anlegen: a) drop non working systemd (viel, viel zu negativ!) b) make systemd work (immer noch negativ) c) make sysvinit default again till systemd is ready c) halte ich nicht nur für die höflichste und konflikt-minimal-invasive Variante. Sie gäbe systemd auch eine zweite Chance. Aber das alles hat Voraussetzungen. Siehe am Ende. Die ID bitte hier zitieren und dann alle ordentlich votieren. Wir knüppeln den systemd schon zurecht. Das kann nicht nur die Polizei in Niedersachsen. :/ "Aber, aber, aber: systemd ist doch so modern und sysvinit ist nur was für alte Säcke." kommt jetzt sicherlich dem einen oder anderen hoch. Ja, modern kaputt. ;)

Mich stört ein um 10 Sekunden längerer Boot-Prozess eigentlich nicht. Die großen Server brauchen eh zum Initialisieren der Hardware viele Minuten und werden außerdem so gut wie nie gebootet.

Ja.

Bei meinem Notebook ist es mir auch egal. Hier ist wichtig, dass Suspend-To- RAM zuverlässig funktioniert. 11.3 war die letzte Version mit dieser Eigenschaft.

Jain. Gemischt. Mit 11.4 ging bei einem meiner Laptops s2disk nicht mehr, dafür funktionierte aber s2ram tadellos. Meine Workstation kann beides tadlelos. Es hängt wohl von der Hardware ab. Ist leider wie so oft so.

Wichtig an einem Init-System ist, dass es Dateisysteme zuverlässig aushängt beim Shutdown, auch wenn man mit mount --bind oder ähnlichen Tricks Zeug unabhängig von der fstab kreuz und quer durcheinander gemountet hat.

Hm, das wäre ein neues Feature. Und ich sehe das nicht als angebracht an. Wer im laufenden System händisch bind mounts an der fstab vorbei erzeugt, der möge sie auch aufräumen. Jede Energie, die an dieser Stelle in die Entwicklung einer "mach das System 'halt'-bar-Mmgie gesteckt wird, halte ich in Anbetracht der wirklichen anstehenden Probleme, für Vergeudung.

Das klappt seit vielen Opensuse-Versionen schon nicht mehr auf anhieb. Bis 11.4 sah man dann, kurz bevor der Strom ausgeschaltet wurde, in grüner Schrift, was schief ging. Mit ein paar Änderungen in den Init-Scripten konnte man das sogar debuggen.

Ok, wenn Du das bereits erforscht hast, dann würde ich die Ergebnisse per bugzilla oder openFATE kommunizieren.

Bei 12.1 hängt beim Ausschalten meist einfach. Gut, wenn ich ihn mit splash=silent starte, ist mir das sowieso egal. Das ist jedoch was, was ich bei allen Maschinen schon bei der Installation abstelle. Hier würde ich mich auch in eine Protestliste eintragen (für splash=verbose oder splash=off).

Nein, nein, nein. In 98,7395% der Fälle interessieren die Meldungen den Nutzer nicht. Sie verwirren ihn sogar eher. Dem Grundsatz des Keep It Simple Stupid (KISS) folgend ist hier weniger mehr. Während der Installation sollte das Abschalten der spash-Magie über einen nachrangige Option - also nur sichtbar, wenn man im Experten/ Details-Moduls ist - möglich sein. Und ich bin mir sicher, dass das bereits geht nur ich es nicht kenne.

Die einzige gleile Idee in systemd ist, jeden Service in eine eigene Control- Group zu legen. So weiß man genau, welche Prozesse dazugehören, auch wenn sie nicht über Vater-Sohn Beziehungen verwandt sind. Das könnte man aber sicher auch im SysV-Init bewerkstelligen, oder?

Ja, das schlug auch wer auf opensuse-factory die Tage vor. Aber bevor ich da irgendwelche Energie reinstecken würde, ginge meine Frage an Werner, ob er an einer Weiterpfelge von sysvinit überhaupt Interesse hätte. Seitens Frederic bin ich mir sicher, dass er systemd weiter verbessern will. Hie kommt es auf unsere konstruktive Mithilfe an. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Unnötige Vollzitate sind auch 2011 unnötig. On Sun, Nov 27, 2011 at 06:55:37PM -0000, hamann.w@t-online.de wrote: [ 8< ]

Anruf von verzweifeltem Benutzer: mein Rechner mag nicht. Da ist nur so ein komisches Tier auf dem Bildschirm: Bis einschl. 11.4: wenn du die Taste ganz links oben drückt, siehst du Text. Was steht da?

Entweder: a) das Paket sysvinit-init installieren und systemd-sysvinit ist Geschichte. b) oder systemd so konfigurieren, dass er nicht den Schirm löscht. Aber auch das bringt nicht wirklich was, weil die Meldungen je nach Dienstumfang sehr unübersichtlich werden können. /var/log/boot.msg gibt es nicht mehr, wenn man systemd verwendet. Und dazu existiert bereits ein Report. Siehe http://lists.opensuse.org/opensuse/2011-11/msg01570.html mit einem Verweis am Ende auf bnc#732934 Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Sun, Nov 27, 2011 at 08:48:51PM +0100, Torsten Förtsch wrote:

On Sunday, 27 November 2011 18:55:26 Lars Müller wrote:

...

Nein, nein, nein. In 98,7395% der Fälle interessieren die Meldungen den Nutzer nicht. Sie verwirren ihn sogar eher. Dem Grundsatz des Keep It Simple Stupid (KISS) folgend ist hier weniger mehr.

Also das behauptet zwar die Lobby des Splash-Screens immer wieder, ich habe aber noch nie gesehen, dass sich davon jemand verwirren lies. Meine Tochter hat eine 11" Kiste mit 11.4, die sie auch manchmal mit in die Schule (11. Klasse) nimmt. Ein Mitschüler fragte: "Ist das normal? Oder geht Dein Rechner gerade kaputt?" Dem Rest war es egal. Nachdem meine Tochter bestätigte, dass es normal sei, war es auch für den einen gut. Weitere Nachfragen kamen nicht.

Mein Vater (>70 Jahre) lebt seit >10 Jahren mit den Meldungen. Auch er hat kein Problem damit. Einmal konnte ich ihn am Telefon durch ein reiserfsck leiten (damals, als reiserfs noch "gut" war).

Weil Du sie so sozialisiert hast. ;)

Wenn die Leute daran gewöhnt sind, dass ihr Computer beim Start irgendwas erzählt, kriegt man von ihnen viel besser die nötigen Informationen, wenn mal was nicht klappt. Wenn Sie in diesem Moment das erste Mal die Konsole sehen, dann sind sie überfordert (auch weil das Stresslevel eh schon erhöht ist).

Naja, aber bei den wenigen Rechnern, die ich zu installieren habe, werde ich keinen großen Aufstand gegen Splash anzetteln, solange man ihn noch ausschalten kann.

So war es immer und es wird auch abschaltbar bleiben.

Allerdings las ich neulich im Linux Magazin Linux auf dem Desktop sei tot. Der Autor dieser Aussage wedelte dabei mit einem ipad.

Ja, wenn die BSD-Pest einem das restliche Hirn bereits verdorben hat, dann kommen solche Aussagen dabei raus. ;)

Folgt man diesem Gedanken, dann ist das Hauptfeld für Linux-Einsatz der Server. Hier würde ich behaupten, dass die Mehrzahl der Administratoren sich von den Meldungen beim Start nicht überfordert fühlen, sie im Gegenteil wahrscheinlich eher begrüßen würden.

Ja, und solch ein fortgeschrittener Admin hat das auch im Griff. Es ist doch so: Abschalten geht wesentlich leichter, als es wieder einzuschalten. Ich halte deshalb den momentanen Ansatz für vernünfig. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Sun, Nov 27, 2011 at 09:16:14PM +0100, Christian wrote: [ 8< ]

...

...

Wichtig an einem Init-System ist, dass es Dateisysteme zuverlässig aushängt beim Shutdown, auch wenn man mit mount --bind oder ähnlichen Tricks Zeug unabhängig von der fstab kreuz und quer durcheinander gemountet hat. Hm, das wäre ein neues Feature. Und ich sehe das nicht als angebracht an. Wer im laufenden System händisch bind mounts an der fstab vorbei erzeugt, der möge sie auch aufräumen. hmm, der chrooted postfix tut sowas z.B.

Er nimmt aber nur das zurück, was er zuvor auch angelegt hat? Oder implementiert er eine Algorithmus, der das selbst herausfindet? Also im Init-Skript der 12.1 sehe ich da nichts. Es gobt allein ein /etc/sysconfig/postfix:POSTFIX_UPDATE_CHROOT_JAIL und selbst das ist voreingestellt auf no. Aber das ist auch ein ganz anderes Problem, als das was wir hier diskutieren.

...

...

Bei 12.1 hängt beim Ausschalten meist einfach. Gut, wenn ich ihn mit splash=silent starte, ist mir das sowieso egal. Das ist jedoch was, was ich bei allen Maschinen schon bei der Installation abstelle. Hier würde ich mich auch in eine Protestliste eintragen (für splash=verbose oder splash=off). Nein, nein, nein. In 98,7395% der Fälle interessieren die Meldungen den Nutzer nicht. Sie verwirren ihn sogar eher. Dem Grundsatz des Keep It Simple Stupid (KISS) folgend ist hier weniger mehr.

Während der Installation sollte das Abschalten der spash-Magie über einen nachrangige Option - also nur sichtbar, wenn man im Experten/ Details-Moduls ist - möglich sein. Und ich bin mir sicher, dass das bereits geht nur ich es nicht kenne. ACK, aber wenn der Benutzer sich für "splash=verbose" entscheidet, dann sollte das nicht wieder automagisch zu "splash=silent" zurückgesetzt werden.

Es wird auf jeden Fall schon bisher nichts im Nachhinein einfach so verändert. Ob man es bereits heute "leicht" über eine GUI setzen kann, kann ich nicht sagen. Wer das haben möchte, der möge openFATE bemühen. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Arndt [29.11.2011 09:56]:

Am Montag, 28. November 2011, 18:21:51 schrieb Lars Müller:

...

On Sun, Nov 27, 2011 at 09:16:14PM +0100, Christian wrote:

...

...

ACK, aber wenn der Benutzer sich für "splash=verbose" entscheidet, dann sollte das nicht wieder automagisch zu "splash=silent" zurückgesetzt werden.

Es wird auf jeden Fall schon bisher nichts im Nachhinein einfach so verändert.

Hallo Lars,

möglicherweise verstehe ich Dich falsch. Falls Du aber damit meinst, dass eine manuell gesetzte Option "splash=verbose" nach einem Distributionsupgrade nicht auf "silent" zurückgesetzt wird, muss ich Dir hier widersprechen.

Ich beobachte bereits seit längerem, dass nach einem Upgrade weitere Optionen an die jeweiligen Zeilen in menu.lst angefügt werden, während einige manuell gesetzte Optionen erhalten bleiben. Das führt dann zu so lustigen Zeilen wie:

module /vmlinuz-3.1.0-1.2-desktop root=xxx resume=yyy \ splash=verbose quiet splash=silent showopts vga=0x346

Beim Booten gewinnt dann die letzte "splash" Option. Meine eigenen Anpassungen nehme ich i.A. manuell ohne Yast vor.

Ich kann es jetzt nicht beschwören, aber ich bin mir ziemlich sicher, dass die oben beschriebene Änderung auch bei jedem Kernel Update vorgenommen wird. Kernel Updates mache ich immer aus dem offiziellen OSS bzw. Update Repo mit "zypper patch".

Grüße Ralf

Hallo Ralf, Änderungen, die ich in /etc/sysconfig/bootloader in den Zeilen DEFAULT_APPEND und DEFAULT_VGA gemacht habe, blieben beim Update von 11.4 auf 12.1 erhalten. Die Zeilen werden beim Installieren des Kernels ausgewertet und angewandt. Manuelle Änderungen in der /boot/grub/menu.lst werden nach Gutdünken der aktuellen Routinen ;-) behandelt. Wenn in /etc/sysconfig/bootloader in der Zeile DEFAULT_APPEND ein "splash=silent" steht, kannst Du auch mehrmals "splash=verbose" in die jeweiligen Zeilen der /boot/grub/menu.lst eintragen - die Zeile aus /etc/sysconfig ist stärker! HTH Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7UoQUACgkQk33Krq8b42P8MgCcCAipflzNCu3K8LjnA9iLntaj mwYAnAqbz0MQFmaRbxhFVsY4o264S2Sy =uNeD -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

...

systemctl status pcscd.service pcscd.service Loaded: error (Reason: No such file or directory) Active: failed since Sat, 26 Nov 2011 12:00:38 +0100; 25min ago Main PID: 8805 (code=exited, status=1/FAILURE)

Argl, da muss jemand mit systemd Wissen ran. Hintergrund ist, dass pcsc-lite 1.8.x von sysvinit auf systemd umgestiegen ist. Dabei passiert irgendwas magisches. Offensichtlich ist der Rückweg nicht so ohne weiteres möglich :-(

...

Deswegen habe ich die neue Version 1.8.1 installiert, aber auch die Nov 26 11:48:52 lappc pcscd[4545]: Unknown option:

Da kann ich vielleicht was dagegen machen. Aber auch mit 1.8.1 wird moneyplex nicht richtig funktionieren. Die Lösung wäre immer noch ein Downgrade auf 1.7.4, wobei man irgendwelche systemd Interna manuell "zurückfixen" muss :-(

Ich habe nochmal auf die aktuelle pcsc-Version 1.8.1 upgedated, was aber auch nicht hilft: perl-pcsc-1.4.10-11.1.i586 pcsc-ctapi-wrapper-0.3-2.1.i586 pcsc-towitoko-2.0.7-379.1.i586 pcsc-lite-1.7.4-4.1.3.i586 pcsc-cyberjack-3.99.5final.SP02-57.1.i586 pcsc-openct-0.6.20-29.1.i586 pcsc-lite-devel-1.7.4-4.1.3.i586 libpcsclite1-1.7.4-4.1.3.i586 pcsc-acsccid-1.0.2-12.1.i586 pcsc-towitoko-devel-2.0.7-379.1.i586 pcsc-tools-1.4.17-1.2.i586 libpcscspy0-1.8.1-65.1.i586 pcsc-ccid-1.4.5-26.1.i586 # pcsc_scan PC/SC device scanner V 1.4.17 (c) 2001-2009, Ludovic Rousseau Compiled with PC/SC lite version: 1.8.1 Scanning present readers... 0: Expresscard SmartCard Reader [CCID Interface] (713700003.) 00 00 Mon Nov 28 21:15:07 2011 Reader 0: Expresscard SmartCard Reader [CCID Interface] (713700003.) 00 00 Card state: Card inserted, ATR: 3B FF 18 00 FF 81 31 FE 45 65 63 11 06 40 02 50 00 10 40 40 04 03 05 00 02 Moneyplex scheint zwar den Kartenleser zu finden, kann aber laut Fehlermeldung nicht auf die eingelegte Karte zugreifen. Im Betriebssystem-Log kommen folgende Meldungen: Nov 28 21:17:22 lappc pcscd: eventhandler.c:403:EHStatusHandlerThread() Error powering up card. Nov 28 21:17:23 lappc pcscd: eventhandler.c:403:EHStatusHandlerThread() Error powering up card. Nov 28 21:17:23 lappc pcscd: winscard.c:316:SCardConnect() Error powering up card: -2146434967 0x80100069 Nov 28 21:17:23 lappc pcscd: winscard.c:321:SCardConnect() Card Not Powered Nov 28 21:17:26 lappc pcscd: winscard.c:316:SCardConnect() Error powering up card: -2146435050 0x80100016 Nov 28 21:17:26 lappc pcscd: winscard.c:321:SCardConnect() Card Not Powered Nov 28 21:17:29 lappc pcscd: winscard.c:316:SCardConnect() Error powering up card: -2146435050 0x80100016 Nov 28 21:17:29 lappc pcscd: winscard.c:321:SCardConnect() Card Not Powered Grüße, Dirk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hi, Am 29.11.2011 15:50, schrieb Peter Matthies:

...

...

Da kann ich vielleicht was dagegen machen. Aber auch mit 1.8.1 wird moneyplex nicht richtig funktionieren. Die Lösung wäre immer noch ein Downgrade auf 1.7.4, wobei man irgendwelche systemd Interna manuell "zurückfixen" muss :-(

ohne selbst eine 12.1 zu benutzen, hatte ich letztens nach einem Update bei einer 11.4 auch das Problem Moneyplex nicht mehr benutzen zu können. Es half bei mir die Version von libpcsclite1 von 1.8.1-64.1 auf 1.7.2-5.5.1 zurückzusetzen. Ich weiß nicht, ob es Dir hilfreich ist, aber einen Versuch ist es ja wert.

Ich hab ja schon geschrieben, dass ein Downgrade auf 1.7.x auf jeden Fall hilft. Auf der 12.1 brauchts evtl. noch ein "systemctl daemon-reload", damit wieder alles wie vorher funktioniert. Wolfgang -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org