HP-Drucker (6500A) auf openSuse installiert


sudo zypper install hplip

Problem
Die automatische Drucker-Suche von hp-setup liefert keine Ergebnisse.

Selbst den entsprechenden Firewall-Port zu öffnen brachte keine Verbesserungen http://hplipopensource.com/node/375
sed -i -r 's/^(FW_SERVICES_ACCEPT_EXT)="(.)"$/\1="\2 0\/0,udp,427"/' /etc/sysconfig/SuSEfirewall2 # 427 -> SLP
sed -i -r 's/^(FW_SERVICES_ACCEPT_EXT)="(.
)"$/\1="\2 0\/0,udp,5353"/' /etc/sysconfig/SuSEfirewall2 # 5353 -> mDns, Bonjour
sudo SuSEfirewall2

Lösung1

Firewall ausschalten.
(D.h. die definierten Firewall-Regeln haben noch nicht ausgereicht.)

Lösung2

„Manual Discovery“
Bei „IP address or network name:“ HPE99A86 eingegeben.

Dann:
Via Yast die Papiergröße auf A4 gestellt und den Drucker yum Standard gemacht.

Zu viele Prozesse (bash: fork: retry: Keine Kind-Prozesse)

Problem
Bei OpenSuse 42.2 sagt die Shell plötzlich immer wieder:
bash: fork: retry: Keine Kind-Prozesse
Und ab und zu auch mal:
bash: fork: Die Ressource ist zur Zeit nicht verfügbar

Lösung
Im System sind Grenzen für z.B. die Anzahl der pro Benutzer laufenden Prozesse festgelegt, um „Fork-Bombs“ zu verhindern.

https://ask.fedoraproject.org/en/question/58717/what-is-resource-temporarily-unavailable-mean-in-the-bash-shell/
http://serverfault.com/questions/449363/understanding-ulimit-u

Was bei mir schon geholfen hat: Einige nicht unbedingt benötige Prozesse zu schließen.
Ansonsten kann man ja auch zu einem anderen User wechseln, der darf dann ja noch Prozesse starten.
su

Höhere Limits für später:
Habe gesehen, dass der Wert für ulimit -u
in
/etc/security/limits.conf
definiert wird.

Mysql-Datenbank von Akonadi repariert

Problem
Nach Umzug von openSuse 13.2 auf Mint 17.3 (KDE 4.14.2) funktionierte KMail (4.14.2) nicht mehr.
Akonadi startete zwar, aber kmail meldete gleich beim Starten einen Fehler („Fehler beim .. der Ressourcen-Collection“ oder so).
Über die Akonadiserver-Konfiguratioon in der akonadiconsole (Button „Test“) die Fehlermeldungen angeschaut, in einer der Dateien stand:
„MySQL server has gone away“
Denn der Mysql-Server stoppte gleich nach dem Start, mit folgendem mysql.err:


160109 15:14:30 [Note] Plugin 'FEDERATED' is disabled.
160109 15:14:30 InnoDB: The InnoDB memory heap is disabled
160109 15:14:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160109 15:14:30 InnoDB: Compressed tables use zlib 1.2.8
160109 15:14:30 InnoDB: Using Linux native AIO
160109 15:14:30 InnoDB: Initializing buffer pool, size = 80.0M
160109 15:14:30 InnoDB: Completed initialization of buffer pool
160109 15:14:30 InnoDB: highest supported file format is Barracuda.
160109 15:14:30 InnoDB: Waiting for the background threads to start
160109 15:14:31 InnoDB: 5.5.46 started; log sequence number 8324119707
160109 15:14:31 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.46-0ubuntu0.14.04.2' socket: '/tmp/akonadi-sunito.VZqpdc/mysql.socket' port: 0 (Ubuntu)
160109 15:14:32 InnoDB: Warning: table 'akonadi/collectiontable'
InnoDB: in InnoDB data dictionary has unknown flags 50.
160109 15:14:32 InnoDB: Warning: table 'akonadi/tagtable'
InnoDB: in InnoDB data dictionary has unknown flags 50.
160109 15:14:32 InnoDB: Warning: table 'akonadi/tagtypetable'
InnoDB: in InnoDB data dictionary has unknown flags 50.
160109 15:14:42 InnoDB: error clustered record for sec rec not found
InnoDB: index `PimItemTable_collectionIndex` of table `akonadi`.`pimitemtable`
InnoDB: sec index record PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000d81f55cad87d; asc U };;
1: len 8; hex d5cad81f55caae11; asc U ;;

InnoDB: clust index record PHYSICAL RECORD: n_fields 13; compact format; info bits 0
0: len 8; hex 800000000004cd69; asc i;;
1: len 6; hex 00000803712e; asc q.;;
2: len 7; hex 1800000c8c35cc; asc 5 ;;
3: len 4; hex 80000003; asc ;;
4: len 26; hex 313435313932313936302e52362e7a7573653133322e73697465; asc 1451921960.R6.zuse132.site;;
5: SQL NULL;
6: len 30; hex 3c73656e7368752f536f7a692f6973737565732f31352f31363836393736; asc <senshu/Sozi/issues/15/1686976; (total 44 bytes);
7: len 8; hex 8000000000000031; asc 1;;
8: len 8; hex 8000000000000008; asc ;;
9: len 4; hex 568a87ea; asc V ;;
10: len 4; hex 568a95fd; asc V ;;
11: len 1; hex 80; asc ;;
12: len 8; hex 8000000000001e08; asc ;;

TRANSACTION 8043EEB, ACTIVE 0 sec fetching rows
mysql tables in use 2, locked 0
MySQL thread id 20, OS thread handle 0x7f102b514700, query id 59908 localhost sunito Sending data
SELECT PimItemTable.id, MimeTypeTable.name, PimItemTable.rev, PimItemTable.size, PimItemTable.datetime, PimItemTable.collectionId FROM PimItemTable INNER JOIN MimeTypeTable ON ( PimItemTable.mimeTypeId = MimeTypeTable.id ) WHERE ( collectionId = ? AND PimItemTable.datetime >= ? ) ORDER BY PimItemTable.id DESC

InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: Dump of the child page:
160109 15:19:50 InnoDB: Page dump in ascii and hex (16384 bytes):

[...]

160109 15:19:50 InnoDB: Page checksum 1915289840, prior-to-4.0.14-form checksum 3717995491
InnoDB: stored checksum 3711358679, prior-to-4.0.14-form stored checksum 3717995491
InnoDB: Page lsn 1 4285448650, low 4 bytes of lsn at page end 4285448650
InnoDB: Page number (if stored to page already) 6,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 5
InnoDB: Page may be an index page where index id is 50
InnoDB: (index "PimItemTable_collectionIndex" of table "akonadi"."pimitemtable")
InnoDB: Corruption of an index tree: table "akonadi"."pimitemtable", index "PimItemTable_collectionIndex",
InnoDB: father ptr page no 4489, child page no 553
PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000d81f55cad87d; asc U };;
1: len 8; hex d5cad81f55caae11; asc U ;;
n_owned: 0; heap_no: 421; next rec: 9366
PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 8; hex 8000000000000241; asc A;;
1: len 8; hex 800000000001992c; asc ,;;
2: len 4; hex 00001189; asc ;;
n_owned: 4; heap_no: 395; next rec: 112
InnoDB: You should dump + drop + reimport the table to fix the
InnoDB: corruption. If the crash happens at the database startup, see
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html about
InnoDB: forcing recovery. Then dump + drop + reimport.
160109 15:19:50 InnoDB: Assertion failure in thread 139707457586944 in file btr0btr.c line 1304
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:19:50 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=16384
read_buffer_size=131072
max_used_connections=48
max_threads=256
thread_count=48
connection_count=48
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 560024 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x7f103e0e8ec0]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x7f103dfd3025]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f103cd62340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f103c3b9cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f103c3bd0d8]
/usr/sbin/mysqld(+0x561e73)[0x7f103e158e73]
/usr/sbin/mysqld(+0x56a887)[0x7f103e161887]
/usr/sbin/mysqld(+0x571c0d)[0x7f103e168c0d]
/usr/sbin/mysqld(+0x57573f)[0x7f103e16c73f]
/usr/sbin/mysqld(+0x60adbc)[0x7f103e201dbc]
/usr/sbin/mysqld(+0x60b8d8)[0x7f103e2028d8]
/usr/sbin/mysqld(+0x601bc4)[0x7f103e1f8bc4]
/usr/sbin/mysqld(+0x54b973)[0x7f103e142973]
/usr/sbin/mysqld(+0x53d5dc)[0x7f103e1345dc]
/usr/sbin/mysqld(+0x541452)[0x7f103e138452]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f103cd5a182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f103c47d47d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Lösung

# Wiederherstellen der Original-Datenbank
mv .local/share/akonadi/ .local/share/akonadi_160109c_kop2
cp -a ../sunito_zuse132/.local/share/akonadi/ .local/share/akonadi/

# in der mysql.conf den Eintrag innodb_force_recovery auf 2 gesetzt (1 funktionierte nicht)
kwriteconfig --file /home/sunito/.local/share/akonadi/mysql.conf --group mysqld --key innodb_force_recovery 2

# Mysql alleine (ohne Akonadi) gestartet:
akonadictl stop
killall /usr/sbin/mysqld
mkdir /tmp/akonadi-sunito.vZoEHB/
/usr/sbin/mysqld --defaults-file=/home/sunito/.local/share/akonadi/mysql.conf --datadir=/home/sunito/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-sunito.vZoEHB/mysql.socket

# Den Server in seinem Konsolefenster laufen lassen, in neuem Fenster die ganze Datenbank gedumpt:
mkdir /opt/ms/dump1/
mysqldump -S /tmp/akonadi-sunito.vZoEHB/mysql.socket -A >/opt/ms/dump1/a2all.sql # 2016-01-09 17:23:24
# Danach den Mysql-Server weieder beendet:
killall /usr/sbin/mysqld

# Dann die Datenbank-Daten weggemovet:
mv .local/share/akonadi/db_data/ .local/share/akonadi/db_data_zuse-kaputt
mv .local/share/akonadi/file_db_data/ .local/share/akonadi/file_db_data_zuse-kaputt
# und den DB-Ordner wieder erstellt:
mkdir .local/share/akonadi/db_data
# in der mysql.conf den Eintrag innodb_force_recovery wieder entfernt
kwriteconfig --file /home/sunito/.local/share/akonadi/mysql.conf --group mysqld --key innodb_force_recovery 0

# Nun in dem vorigen Fenster wieder Mysql gestartet:
/usr/sbin/mysqld --defaults-file=/home/sunito/.local/share/akonadi/mysql.conf --datadir=/home/sunito/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-sunito.vZoEHB/mysql.socket
# Dann die DB aus dem Dump wiederhergestellt:
mysql -S /tmp/akonadi-sunito.vZoEHB/mysql.socket # Und Mysql-Server weieder beendet:
killall /usr/sbin/mysqld

# Nun Akonadi gestartet
akonadictl start

–> Läuft!!!

 


 

Dann festgestellt, dass einige Konfigurationsdateien nicht im neuen Userverzeichnis angekommen waren:

cp -a ../sunito_zuse132/.kde4/share/config/akonadi_pop3_resource_[1-9]*rc ~/.kde/share/config

Allerdings stimmen dan die in diesen Dateien eingetragenen Zielordner-IDs (targetCollection) nicht mehr. Mühsam manuell per GUI geändert (ohne Internetverbindung, damit keine Mails in die falschen Odner gelangen).

Verknüpfung mit Dateityp .pdf in Wine/PlayOnLinux

cat <<eot >/dat/systemwartung/wine-zeug/regedit-pdf.reg

[HKEY_CLASSES_ROOT\.pdf]
@=“PDFfile“
„Content Type“=“application/pdf“
[HKEY_CLASSES_ROOT\PDFfile\Shell\Open\command]
@=“winebrowser \“%1\““

eot

WINEPREFIX=~/.PlayOnLinux/wineprefix/Office2010 wine/linux-x86/1.7.22/bin/regedit /dat/systemwartung/wine-zeug/regedit-pdf.reg

Normalen Update-Prozess unter wine für wiso 2013 ermöglicht

Problem

Wenn man den auf „Nach Updates suchen“ klickt, kommen einige kleine Fenster
etwa „verbinde mit Buhl-Server“, aber dann bricht der Prozess mit diesem wine-Fehler ab:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NotImplementedException: The method or operation is not implemented.
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at Buhl.Bdmsc.FormBdmsc.WaitAndExecute_OnWaitWorkerEvent(Object sender, WaitEventParams e)
at Buhl.Bdmsc.Classes.AsyncWaitAndExecute.DoEvent(Object sender, WaitEventType eventType)
at Buhl.Bdmsc.Classes.AsyncWaitAndExecute.bw_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e)
at System.ComponentModel.BackgroundWorker.OnRunWorkerCompleted(RunWorkerCompletedEventArgs e)
at System.ComponentModel.BackgroundWorker.AsyncOperationCompleted(Object arg)

************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
[...]

Lösung
Inspiriert von
http://forum.linux-club.de/viewtopic.php?f=90&t=111203 und
http://www.winehq.org/pipermail/wine-bugs/2013-April/351258.html:
Adobe Reader 9.5 und Internet Explorer 8 installiert, ich weiß nicht,
was von beiden es gebrtacht hat.

wine AdbeRdr950_de_DE.exe
winetricks -q ie8

Helligkeit beim Acer Travelmate einstellbar gemacht

Problem

Die Helligkeit konnte überhaupt nicht eingestellt werden,
weder par Tasten, noch per Oberfläche

Lösung

Entsprechend http://askubuntu.com/questions/180819/how-to-control-brightness-on-acer-laptop

# in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

# ersetzt durch:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux acpi_backlight=vendor"

# dann:
sudo update-grub

Grundlegende Konsole-Einrichtung

1. umask für Gruppe erweitern!
Wollte Umask wie https://syve.wordpress.com/2011/08/18/die-start-umask-per-ssh-setzen/ setzen. Leider gibt es dieses Verzeichnis nicht unter Kubuntu, stattdessen habe ich etwas im Login gefunden.

# Damit hat es funktioniert
sudo sed -i „s/UMASK …/UMASK 002/“ /etc/login.defs

2. bashrc schön machen:


cat <<EOT >>~/.bashrc

# siehe https://syve.wordpress.com/2011/11/25/grundlegende-konsole-einrichtung/
# Zeit vor dem Prompt ausgeben
PS1="\t "\$PS1

# History verbessern:
shopt -s histappend
export PROMPT_COMMAND='history -a'
export HISTSIZE=9999
EOT

Iso Images mounten

Falls man Iso Images nicht extra entpacken möchte, da größere Dateien etwas mehr Zeit & Ressourcen bentöigen, mounten wir die Iso Image einfach …

sudo mount /pfad/zum/image.iso /mnt

… dadurch wird die Iso Image zugänglich gemacht (wie „entpackt“)., kann also völlig normal benutzt werden.