2017-01-12
Init
I activated some time ago face recognition for Photo Station on our Synology DS212+ because I thought it would be a good idea but it wasn’t. It is super slow (at least on the DS212+), unprecise, and caused over days (weeks) high CPU load so I decided to deactivated it. After deactivating the CPU load was still high and I also saw the face recognition process in the process list. After searching around I found some hints in the direction of these file(s) synophoto_face.queue, synophoto_face.queue.tmp.
Solution
The face recognition process created queue files (synophoto_face.queue and synophoto_face.queue.tmp) which caused the processing of those photo files even if face recognition is disabled. The easiest solution to stop the face recognition process is to delete those queue files. Unfortunately I didn’t found a way to do that via Web UI so you have to do that via shell and ssh.
Make sure SSH access is active (Control Panel → Terminal & SNMP). Per default only the admin user is able to login via SSH.
ssh admin@my_nas
admin@my_nas: sudo -i
root@my_nas: rm -v -- /var/services/photo/\@eaDir/synophoto_face.*
After file removing I restarted the nas, just to be sure.
2016-12-01
Init
After upgrading my HTC m7 to Cyanogenmod 13 I discovered that NFC was not working. The NFC icon was touchable but nothing happened! I started to debug a little bit around. Here are my findings.
NFC initiation under Cyanogenmod 12.1
Under Cyanogenmod 12.1 NFC initiation looks like this. The NFC process is searching for some firmware but can’t find them and continues with old NFC firmware.
tuxinaut@sm191:~$ adb logcat | grep -Ei "NFCJNI|firmware"
D/NFCJNI ( 2647): Start Initialization
E/NFC-HCI ( 2647): Could not open /vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFC ( 2647): Firmware image not available: this device might be running old NFC firmware!
D/NFCJNI ( 2647): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 11, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
...
...
I/NFCJNI ( 2647): NFC Initialized
NFC initiation under Cyanogenmod 13
Under Cyanogenmod 13 NFC initiation looks like this. No missing firmware but some errors which cause NFC to not working.
tuxinaut@sm191:~$ adb logcat | grep -Ei "NFCJNI|firmware"
01-01 12:36:55.497 2721 2721 I NFCJNI : NFC Service: loading nxp JNI
01-01 12:36:55.911 2721 2945 D NfcService: checking on firmware download
01-01 12:36:55.938 2721 2945 D NFCJNI : Start Initialization
01-01 12:36:56.194 2721 2945 D NFCJNI : NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 11, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 249
01-01 12:36:56.392 2721 2945 D NFCJNI : Download new Firmware
01-01 12:36:57.441 2721 2945 W NFCJNI : Firmware update FAILED
01-01 12:36:57.631 2721 2945 D NFCJNI : Download new Firmware
01-01 12:36:58.681 2721 2945 W NFCJNI : Firmware update FAILED
01-01 12:36:58.871 2721 2945 D NFCJNI : Download new Firmware
01-01 12:36:59.921 2721 2945 W NFCJNI : Firmware update FAILED
01-01 12:36:59.921 2721 2945 E NFCJNI : Unable to update firmware, giving up
01-01 12:36:59.971 2721 2945 D NFCJNI : Terminating client thread...
Solution
After comparing the logcat outputs I searched for mentioned firmware file (libpn544_fw.so) and found the file under Cyanogenmod 13. So I removed this file and bingo NFC works.
On the mobile phone
- Enable Developer settings. Touch multiple times on the Build number (under Settings)
- Under Developer options
- Enable root access for Apps and ADB
- Enable Android debugging
On the computer
Install adb (under Ubuntu the package name android-tools-adb)
sudo apt-get install android-tools-adb
Open an adb shell
adb shell
Execute following commands in the adb shell
# Become root
su
# Make system filesystem writeable
mount -o rw,remount /system
# Remove the firmware file
rm -f /system/vendor/lib/libpn544_fw.so
rm -f /system/vendor/firmware/libpn544_fw.so
After this restart the device. After the restart NFC works as expected.
Update 2016-12-22
After updating to the last nightly I found out that you also must remove /system/vendor/firmware/libpn544_fw.so (Or they moved the file I was to fast with removing)
2016-11-18
Init
During the last weeks I was wondering why the spell checking in the nativ Slack App (under Ubuntu 14.04) isn’t working at all. Finally I found some time to debug this issue.
After a short look into the logfile (/home/USERNAME/.config/Slack/logs/webapp-*.log) I saw following.
2016-11-15T17:07:27.274Z - info: 4 words typed without spell checking invoked, redetecting language
2016-11-15T17:07:27.287Z - info: Attempting detection, string length: 23
2016-11-15T17:07:27.290Z - info: Failed to load dictionary: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/lib/slack/resources/app.asar.unpacked/node_modules/@paulcbetts/cld/build/Release/cld.node)
2016-11-15T17:07:27.296Z - info: 4 words typed without spell checking invoked, redetecting language
Funny to see that because I thought this app is statically compiled and has no external dependencies ¯\_(ツ)_/¯
Solution
After searching around the solution was relatively trivial. You have to add the Toolchain test builds ppa and install / upgrade libstdc++6.
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install libstdc++6
After restarting the Slack app spell checking works as expected.
Sources
2016-05-30
INIT
Ja ich gebe es zu, Ich habe ein Windows7 System am laufen. Dieses ist nur fürs spielen gedacht (wenn ich mal dazu komme). Seit mehreren Monaten, haben ich beobachtet das der freie Speicher auf der C: Partition immer weiter abgenommen hat. OK ich dachte ist halt Windows und erklärte mir das mit Updates und Temp Dateien.
Deshalb habe ich die C: Partition 2 mal vergrößert, am Ende auf 50GB (Was ich selbst für Windows absurd groß fand). Immer nach dem vergrößern hat der freie Speicherplatz binnen Tagen wieder abgenommen, was mir denn doch komisch vorkam.
Lösung
Erstmal wollte ich wissen was auf der C: Partition wie viel Platz beansprucht. WinDirStat eignet sich wunderbar um grafisch anzuzeigen welche Ordner und Dateien wie viel Speicherplatz verbrauchen.
Es stellte sich relative schnell raus das der folgender Ordner mit 22GB dafür verantwortlich war.
c:\windows\logs\cbs\
Eine kurze Recherche ergab das der Inhalt des Ordner vom System File Checker (SFC) Tool stammt und “gefahrlos” gelöscht werden kann, wenn das System ohne Probleme läuft! Was ich denn auch gemacht habe, bis jetzt sind mir keine Probleme dadurch aufgefallen.
Quellen
2016-01-21
INIT
Ich versuche seit geraumer zeit auf meinen Lenovo T440 hibernation zum laufen zu bekommen. Leider ist es mir noch nicht gelungen hibernation stabil zum laufen zu bekommen. Dabei ist mir eingefallen das ich das BIOS updaten könnte, man weiß ja nie ob das was hilft.
Natürlich gibt es den einfachen Weg nur für Windows aber immerhin wird es einen nicht so schwer gemacht das ganze per USB stick zu erledigen.
Vorbereitung
Download der (aktuellen Version, zur zeit 2.36) BIOS Update Bootable CD für den T440/T440s
wget https://download.lenovo.com/pccbbs/mobiles/gjuj23us.iso
# MD5 summe vergleichen
# sollte in diesen fall 5a76509b23a0336cecc3ddb52db6b786 sein
md5sum gjuj23us.iso
5a76509b23a0336cecc3ddb52db6b786 gjuj23us.iso
Falls nicht schon vorhanden genisoimage installieren.
sudo apt-get install genisoimage
Nun das boot image extratypeen und das erstellte Image auf einen passenden USB Stick per dd überspielen.
geteltorito -o bios.img gjuj23us.iso
dd if=bios.img of=/dev/sdb
Wenn alles geklappt hat kann jetzt vom USB Stick gebootet werden und das Update kann eingespielt werden. Es sollte denn so aussehen wie auf dem Bild.
Quellen
2014-11-16
Sehr schön unter How to Install Pandoc on Arch Linux beschrieben, was mir aber gefehlt hat war die Repro URL welche in /etc/pacman.conf eingetragen werden muss.
[haskell-core]
Server = http://xsounds.org/~haskell/core/$arch
2014-11-11
Wer unter Ubuntu 12.04 Keepass2 Plugins nutzen möchte und folgende Fehlermeldung auftritt.
The following plugin is incompatible with the current KeePass version: /usr/lib/keepass2/OtpKeyProv.plgx
Liegt das daran das mono das Plugin nicht kompilieren kann. Abhilfe schafft type das Paket mono-complete zu installieren.
sudo apt-get install -y mono-complete
2014-11-11
INIT
Wir möchten unsere VLANs mittels Racktables dokumentieren. Diesen wollen wir “erstmal” manuell machen, Racktables stellt typefür auch eine Weg bereit.
Hierzu ein Auszug aus dem entsprechenden Wiki Artikel Adding and removing 802.1Q ports offline
To turn the manual editor on, change the “List source: objects with extended 802.1Q sync”; config option to RackCode matching the objects, which should have it on. For example, if you had such switches tagged with “manual 802.1Q”;
WTF??? Wo? Wie? Was?
Lösung
Nach längeren suchen ist mir die Option 8021Q_EXTSYNC_LISTSRC unter die Finger gekommen. Diese ist nicht unter den Interface preferences sichtbar! Warum dieses so ist konnte ich noch nicht klären.
Zumindest wenn die init-full-0.20.8.sql der Demo Installation verwendet wird, ist die Option definitiv nicht sichtbar.
Ich habe mich dazu entschlossen die Option per Hand in der Datenbank sichtbar zu setzten. Dieses kann mit folgenden Befehl erreicht werden.
mysql -u root -p -e "UPDATE Config SET is_userdefined='yes' WHERE varname='8021Q_EXTSYNC_LISTSRC';" racktables
Nun kann unter denn Interface preferences der Wert der Option 8021Q_EXTSYNC_LISTSRC auf {manual 802.1Q} gesetzt werden. Zusätzlich muss ein Tag mit der selben Bezeichnung (manual 802.1Q) angelegt werden.
Nun muss dem entsprechenden Gerät der Tag manual 802.1Q + ein Switch Template zugewiesen werden. Danach ist es nun möglich unter dem Reiter 802.1Q sync Ports manuell hinzuzufügen und zu entfernen.
2014-01-30
Wenn bei einer Sicherung der Fehler
qm set $SYSTEM_ID$ --lock backup failed: exit code 25
auftritt, ist das System höchstwahrscheinlich noch gelockt. Ein unlocken des Systems reicht aus um die Fehlermeldung verschwinden zu lassen.
qm unlock $SYSTEM_ID$
2013-09-05
INIT
Vor ein wenig mehr als einer Woche habe ich mitbekommen das der Dritter Snapshot von Ubuntu 12.04 veröffentlicht wurde. Meine Neugier wurde geweckt. Neuer Kernel und neue Xserver aus dem Raring Release (13.04) das klang spannend.
Also schnell die Pakete installiert.
sudo apt-get install -y linux-generic-lts-raring und xserver-xorg-lts-raring
Einen LTS System so neue Komponenten zu verpassen ist schon ein wenig gewagt, sollte sich aber bei den meisten ohne Probleme installieren lassen. Bei mir leider nicht :( nach der Installation gab es ein paar Fehlermeldungen (leider nicht dokumentiert) aber immerhin gab es eine grafische Oberfläche.
Lösung
Um es vorweg zu nehmen das eigentlich Problem hat sich erst nach der Installation des Radeon Treibers ergeben! Schönes Weißes Rauschen …
Danach ging der Spaß erst mal richtig los :) Da ich meine ATI Mobility Radeon HD 4550 natürlich mit dem Fglrx Treiber benutzt habe, schwante mir da was. Die Unterstützung für den installierten 3.8 Kernel + Xserver war natürlich nicht mehr vorhanden! Gut ich meine nicht das ich den freien Radeon Treibern nicht aufgeschlossen bin, der einzige Grund auf den fglrx Treiber zu setzten war das die Lüftersteuerung. Beim freien Treiber lief der Lüfter leider fast immer, da die Energieverwaltung nicht optimal war.
Also musste der Fglrx Treiber erst mal entfernt werden. Eine ausführliche Anleitung zur Deinstallation gibt es bei ubuntuusers.
sudo apt-get purge fglrx fglrx-modaliases fglrx-amdcccle
Danach die freien Radeon Treiber installiert und neu gestartet.
sudo apt-get install -y xserver-xorg-video-ati-lts-raring xserver-xorg-video-ati-lts-rarin
Nach dem booten ist mir schon aufgefallen wir lange das System bracht um LightDM zu laden, ich war sehr erstaunt als der Bildschirm nur weißes Rauschen gezeigt hat. Meine erste Reaktion war in den alten Kernel zu booten. Das hat auch funktioniert. Nach einigen Neustarts trat bei dieses auch das gleiche Problem auf WTF? Ich habe nichts verändert.
Nach relativ langen debuggen, bin ich durch Zufall darauf gestoßen das wenn ich die Zeile gfxmode $linux_gfx_mode aus dem Grub menuentry entferne (habe das direkt beim booten ausprobiert) alles wieder wie gewohnt funktionierte.
Nach noch mehr debuggen habe ich endlich in Erfahrung gebracht das wenn ich die Variable GRUB_GFXPAYLOAD_LINUX in der /etc/default/grub mit dem entsprechenden Hexwert setzt, alles dauerhaft wieder funktioniert.
Ich bin der Meinung das auch eine ganz normale Auflösung hätte eingetragen werden können aber sicher ist sicher :)
Woher stammt dieser Hexwert nun? Um dieses zu ermitteln gibt es zwei Möglichkeiten
Mittels hwinfo
Damit habe ich aber nicht alle möglichen Auflösungen gelistet bekommen!
sudo hwinfo --framebuffer
02: None 00.0: 11001 VESA Framebuffer
[Created at bios.464]
Unique ID: rdCR.QOJHFkjgnM2
Hardware Class: framebuffer
Model: "(C) 1988-2005, ATI Technologies Inc. M92"
Vendor: "(C) 1988-2005, ATI Technologies Inc. "
Device: "M92"
SubVendor: "ATI ATOMBIOS"
SubDevice:
Revision: "01.00"
Memory Size: 16 MB
Memory Range: 0xd0000000-0xd0ffffff (rw)
Mode 0x0300: 640x400 (+640), 8 bits
Mode 0x0301: 640x480 (+640), 8 bits
Mode 0x0303: 800x600 (+832), 8 bits
Mode 0x0305: 1024x768 (+1024), 8 bits
Mode 0x0307: 1280x1024 (+1280), 8 bits
Mode 0x0310: 640x480 (+1280), 15 bits
Mode 0x0311: 640x480 (+1280), 16 bits
Mode 0x0313: 800x600 (+1600), 15 bits
Mode 0x0314: 800x600 (+1600), 16 bits
Mode 0x0316: 1024x768 (+2048), 15 bits
Mode 0x0317: 1024x768 (+2048), 16 bits
Mode 0x0319: 1280x1024 (+2560), 15 bits
Mode 0x031a: 1280x1024 (+2560), 16 bits
Mode 0x030d: 320x200 (+640), 15 bits
Mode 0x030e: 320x200 (+640), 16 bits
Mode 0x0320: 320x200 (+1280), 24 bits
Mode 0x0393: 320x240 (+320), 8 bits
Mode 0x0395: 320x240 (+640), 16 bits
Mode 0x0396: 320x240 (+1280), 24 bits
Mode 0x03b3: 512x384 (+512), 8 bits
Mode 0x03b5: 512x384 (+1024), 16 bits
Mode 0x03b6: 512x384 (+2048), 24 bits
Mode 0x03c3: 640x350 (+640), 8 bits
Mode 0x03c5: 640x350 (+1280), 16 bits
Mode 0x03c6: 640x350 (+2560), 24 bits
Mode 0x0333: 720x400 (+768), 8 bits
Mode 0x0335: 720x400 (+1472), 16 bits
Mode 0x0336: 720x400 (+2944), 24 bits
Mode 0x0353: 1152x864 (+1152), 8 bits
Mode 0x0355: 1152x864 (+2304), 16 bits
Mode 0x0356: 1152x864 (+4608), 24 bits
Mode 0x0363: 1280x960 (+1280), 8 bits
Mode 0x0365: 1280x960 (+2560), 16 bits
Mode 0x0366: 1280x960 (+5120), 24 bits
Mode 0x0321: 640x480 (+2560), 24 bits
Mode 0x0322: 800x600 (+3200), 24 bits
Mode 0x0323: 1024x768 (+4096), 24 bits
Mode 0x0324: 1280x1024 (+5120), 24 bits
Mode 0x0343: 1400x1050 (+1408), 8 bits
Mode 0x0345: 1400x1050 (+2816), 16 bits
Mode 0x0346: 1400x1050 (+5632), 24 bits
Config Status: cfg=new, avail=yes, need=no, active=unknown
Was mich type ein wenig stutzig gemacht hat, ist das da Auflösungen Fehlen! Als ich die Auflösungen wie weiter unten beschrieben habe mittels Grub Shell bestimmt habe, waren diese auch vollständig.
Direkt in Grub
Eine weitere Möglichkeit ist den Befehl vbeinfo direkt in der Grub Shell auszuführen, das Ergebnis sollte wie bei hwinfo aussehen.
vbeinfo
...
...
Der Hexwert der gewünschten Auflösung muss in die Datei /etc/default/grub der Variablen GRUB_GFXPAYLOAD_LINUX zugewiesen werden. Es kann sein das diese erst noch erstellt werden muss.
GRUB_GFXPAYLOAD_LINUX=0x1e6
Danach muss die Grub Konfiguration aktualisiert werden! Ansonsten werden die gemachten Änderungen nicht aktiv.
sudo update-grub
Ergebnis
Nach ungewohnt langen debuggen und wirklich vielen Neustarts habe ich endlich wieder ein System bekommen. Was normal bootet und mich mit einer grafischen Oberfläche begrüßt.
Vielleicht sollte ich das nächste mal nicht ganz so fix beim Updaten sein, aber irgendwas ist ja immer.
Die einzigen Nachteile die mir beim freien Radeon Treiber bis jetzt aufgefallen sind, ist der höhere Stromverbrauch und der fast ständig laufende Lüfter. Schade das dass immer noch so ist aber im Kernel 3.11 soll sich ja noch mal viel getan haben. Vielleicht schaue ich mir das ganze mal bei Gelegenheit mit diesen Kernel unter Arch Linux an :)