Zockertown: Nerten News

Worum geht es?

Ich beschreibe, wie ein modernes Multimeter genutzt werden kann, um Störungsursachen im Heimbereich zu orten, wenn es beim Empfang von DAB+, Funkuhren, DECT Telefonen u.ä. geht.

Wie bei mir üblich, lebt dieser Beitrag und wird noch ergänzt. Wer sich dafür interessiert, kann das beschleunigen und mir einen Kommentar hinterlassen.

Vorgeschichte

Wenn ich früher in meinem Bastelraum das Oszilloskop angeworfen habe, um einen Fehler in einer elektronischen Schaltung zu finden, dann strahlte der in örtlicher Nähe befindliche DLF (ein Mittelwellensender, für die jüngeren Leser) kräftig in ungünstig verlegte Kabel und / oder zu lange Masseleitungen ein.

Dadurch hatte ich bei offenen Tastkopf schonmal eine Grundlinie, die ein rhytmisches Rauschen zeigte. Wenn ich dazu ein Radio auf DLF einstellte, sah ich dass das der Sender war, der da einstrahlte.

Das Testobjekt angeschlossen und etwas Sorgfalt bei den Kabeln konnte das soweit minimieren, dass auch bei Messungen im Millivolt Bereich keine Störungen mehr sichtbar waren.

Mittlerweile ist der DLF abgeschaltet und man sollte meinen, dass ich nun sauberere Messungen machen kann.

Doch so ist es nicht, es ist leider eine Tatsache, es gibt eine Verseuchung durch allerlei Schaltnetzteile und LED Leuchtmittel, die intern oftmals ja auch eine geschaltete Strombegrenzung haben.

Auf Mittelwelle strahlt hier nichts mehr bemerkbar, dennoch sind die Störungen so stark, dass an Messungen im Millivoltberech gar nicht mehr zu denken ist.

In welchem Frequenzbereich genau, kann man am Oszi einigermaßen bestimmen, das hilft bei der Quellensuche aber selten weiter, weil die verschiedenen Schaltnetzteilchen auf unterschiedlichen Schaltfrequenzen Oberwellen produzieren.

Mit einem alten MW (Mittelwelle) Radio habe ich versucht die Quelle zu orten, diverse elektrische Störquellen systematich ausgeschaltet, doch kam ich damit aber nicht recht weiter, so habe ich das erstmal auf sich beruhen lassen und mich nicht mehr weiter darum gekümmert. Man bedenke, dass ein Mittelwellen Radio natürlich auch nur einen beschränkten Empfangsbereich von ca. 500Khz - 1,6 Mhz hat, Störquellen die darüber oder darunter liegen werden naturgemäß nicht zu merkbaren Effekten führen.

NCV - Die Lösung für den Praktiker?

Nun gibt es seit einiger Zeit Digital Multimeter, die u.a. NCV (Non Contact Voltage) Messung bieten. Seit ein paar Wochen bin ich Besitzer eines UNIT UT89XD.

Das habe ich mir u.a. wegen der LED Messung zugelegt, es hat aber auch die ominöse NCV Messfunktion. Ich möchte jetzt gar keine Werbung für das Gerät als solches machen, sondern es geht mir um diesen speziellen Anwendungszweck. Das sollte mit jedem üblichen NCV fähigen Multimeter funktionieren. Bitte berichtet, wenn ihr andere Erfahrungen habt.

Mit dem Multimeter gewappnet bin ich also losgezogen und habe bevor ich richtig auf die Suche ging, bereits den Hauptstörenfried entdeckt. In Verdacht hatte ich die LED-Lupenleuchte wohl schon, nur gestört hat die nicht im MW Band. Die alte Lupenleuchte mit Leuchtstofflampe hat  keine Störungen verursacht.

Ich schaltete also das Multimeter in den NCV Bereich und es war sofort lautes Gepiepse, je näher ich der Lupenleuchte kam, umso schneller wurde das Piepen.

Die LED zeigte entspechend Grünes Geblinke.

Scheinbar ist in der 230V LED Lupenleuchte eine KSQ (KonstantStromQuelle) in Schalttechnologie verbaut.

Klar, eine lineare Konstantstromquelle hat mehr Verluste und auch vielleicht mehr Bauteile, wahrscheinlich eine Sache der betriebswirtschaftlichen Betrachtung.

Bei ausgeschalteter Leuchte  ist immer noch starkes Netzbrummen auf dem Scope zu sehen (Ok, mit offenen Tastkopf über die Lupe gelegt ). Erst Stecker ziehen beendet den Spuk. Ich werde also meine Lupenleuchte über eine 2-Pol schaltbare Steckdose anschließen, einfach ausschalten hilft ja nicht.

Überlegenswert wäre auch mal, die LED mit Gleichspannung zu betreiben und die die Stromquelle zu beruhigen, also evtl. einfach einen Linearregler zu verwenden. Wenn die Lupenleuchte mit Gleichspannung arbeiten würde, hätte das auch den Vorteil, dass Bilder und Filme mit dem Smartphone auch besser würden, denn momentan merkt man schon, das hier mit pulsartiger Belichtung gearbeitet wird. Besonders bei Filmaufnahmen stören die horizontalen Hell/Dunkel Streifen

Weil NCV nun gerade neu für mich ist, habe ich mir interessehalber meine rumliegenden USB Wandwarzen angesehen.

Alle zeigen im Groben dasselbe Bild. Auf EFHI, dem unempfindlichen Messbereich ein Balken, manchmal 2.

Auf der EFLo, dem empfindlichen Bereich alle 4 Balken und dauerpiepen.

Anmerkung: EFHI und EFLo sind so im Display des UNI-T zu sehen, ein Tribut an die Möglichkeiten der Siebensegment Darstellung.

Eine Powerbank andererseits zeigt übrigens gar keine Störungen an, hier ist ein Step Up Wandler verbaut und dort werden auch schnelle Schaltimpulse auftreten. Offenbar ist dort die Dämpfung aber besser.

Das zeigt, dass es mit geringem Aufwand möglich ist, eine 5V Ausgangspannung ohne störende Spitzen zu konstruieren ... und das auch richtig günstig, die Powerbank hat ja nicht die Welt gekostet.

Zum Messen habe ich die Konstellation im linken Bild gewählt, also ohne Last und das USB Ladekabel am Messpunkt (Siehe rechtes Bild) vorbei geführt.

Mein Fazit, NCV ist mehr als nur eine nette Spielerei. Natürlich kann man damit auch stromführende Leitungen Unterputz finden, oder mal checken, ob an der Kabelverbindung Netz ist.

Ich finde die Möglichkeit, damit mit Spikes von unsauber aufgebauten Schaltnetzteilen nachzuweisen, viel interessanter. 

Normalerweise sollte man denken, das kommerzielle Geräte mit CE Zeichen auch auf EMI / EMC überprüft worden, das scheint aber wohl nicht mehr so pauschal zu stimmen. (Ja, ich weiß, aus Asien stammende Kleingeräte wie solche Wandwarzen haben zwar häufig ein CE Zeichen, das aber muß nichts bedeuten)

Jedenfalls kann ich nun zu Hause mal leicht z.B. die Ursache finden, warum der DAB+ Empfang oder die Funkuhr nicht richtig funktioniert...

Einen konkreten Fall habe ich bereits, ich habe im Auto so einen USB Ladeadapter fürs Smartphone. Wenn ich den benutze, wird der Empfang des DAB+ Radios entschieden schlechter, FM übrigens auch.

Ps: Wer über die Realisierung der NCV Messung etwas näheres weiß, melde sich bitte.

Ist es ein Hall Sensor mit Hochpass, oder mit Bandpass für 50-60 Hz?

Oder wird es ganz anders gemacht?

Im Netz finde ich dazu nicht wirklich nützliche Informationen.

Wie dem auch sei, ich habe mir eins der USB Wandwarzen genommen und mit dem Oszi auf die unbelastete Ausgangsspannung geschaut. Versuchsweise auch mal mit 2 Spulen und einer minimalen 20K Last.

Beispielhaft mal zwei Fotos. Sieht schon schlimm aus, kein Wunder, dass die Teile so dermaßen Störungen verursachen.

Wenn ich mal Lust habe, werde ich die Filterung nach 1-2 Standard Vorschlägen aus der AFU Szene versuchen und dann mal sehen, wie der NCV Test darauf reagiert.

Klar, STR-C drücken, aber warum nicht ständig?

Heute hat mich das genervt, also in die nanorc

cat nanorc 

set positionlog

set constantshow

Eingetragen und gut iss.

Das positionlog ist das Pendant zu dem autocmd im vi(m) welches ungleich komplizierter ausschaut

positionlog merkt sich die Cursorpostion für die letzten 200 Files, die man mit nano angesehen, oder bearbeitet hat.

Ps: nanorc kann man hier: ~/.nanorc ablegen, oder da wo ich es gemacht habe: ~/.local/nano/nanorc

... und es gibt noch andere Möglichkeiten, man nano ...

PPs: Ja ich schäme mich nicht nano zu nutzen

Eigentlich nimmt man heutzutage GIT.

Ich nicht, da ich auch nur meine eigenen Spielereien etwas sichern und den Überblick behalten möchte, verwende ich CVS.

Braucht keiner nachmachen, ich schreibs halt hier mal auf, damit ich es wiederfinde, wie ich es aufgesetzt habe.

Schönere Anleitungen gibt es im Netz, hier die Variante, die bei mir werkelt.

Mein Repository liegt auf dem Rootserver.

CVSROOT=/var/CVS

Zugriff kann lokal oder über ssh erfolgen.

Dafür habe ich

export CVSROOT=:extssh:IP-adresse:/var/CVS

in der .bashrc des Client.

Damit das Ganze funktioniert muss der lokale user auch auf dem Server existieren und den sshkey im authorized_key hinterlegt haben.

Jetzt kann auf dem Client z.B. ein Verzeichnis importiert werden.

cvs import Elektronik bed start

Elektronik ist der Ordner Name und bed ist der user.

Selbstredend sollte der Ordner Elektronik frei von unnötigem Zeug sein, sonst wird das auch versioninert. Einige wenige Dateien werden allerdings auch per default ignoriert.

Es öffnet sich nano und fragt nach einem Kommentar. Mit -m "bla fasel" könnte man das umgehen, mache ich gewöhnlich aber nicht.

Jetzt sollte eine Liste von "N Dateinamen" erscheinen, damit ist das importieren erfolgreich.

Danach kann man mit cvs co Elektronik das Verzeichnis ausschecken und so zum bearbeiten vorbereiten

Ps: Nicht vergessen, 

 /var/CVS 

Vor einiger Zeit habe ich den Verursacher von erhöhter Prozessorlast gesucht. Mangels detailierter Monitoring Graphen war ich da leider etwas behindert bei der Suche. Schliesslich hatte ich es dann doch gefunden, es war der 4 Wöchentliche Softraid Check, den ich gar nicht mehr auf dem Schirm hatte.

Das war der Anlaß das Monitoring etwas aufzubohren.

Collectd bietet das Plugin Processes.

Das lässt sich individuell für seine eigene Zwecke anpassen.

Ich habe folgende Konfiguration gemacht:

<Plugin "processes">
ProcessMatch pg_autovacuum "postgres:.*autovacuum"
# Ergänzung um typische Verdächtige, wenn Proccess Count zu hoch ist
ProcessMatch webuser "web???"
ProcessMatch webcgi "php.cgi"
ProcessMatch vmail "dovecot"
</Plugin>

Die Idee dabei ist, dass man diese Prozessgruppen detailiert beobachten kann und nicht nur die normale Gesamtprozess Graphen.

Heute habe ich in meinem Imap Postfach aufgeräumt und diverse Archiv Ordner verschoben und indiziert. (Innerhalb von Thunderbird)

So sah das in der Graphik, aus man erkennt deutlich, in welchem Zeitraum das indizieren stattfand.

Das macht Hoffnung, für spätere Ernstfälle

Update 13.03.2020:

Mit den Notifications bin ich nun ein Stück weitergekommen.

Hier ein Ausschnitt aus der threshold.conf:

<Plugin "processes-vmail">
	<Type "ps_count">
		Instance "processes"
		Percentage false
		Hits 4
		WarningMax 4
	</Type>
	<Type "ps_rss">
		Percentage false
		Hits 4
		WarningMax 550000000
	</Type>

#   ps_cputime. Ohne Angabe einer Instance gilt WarningMax für jeden
	<Type "ps_cputime">
		Percentage false
		Hits 4
		WarningMax 25000
	</Type>
</Plugin>

Ach, bevor ichs vergesse, während des experimentierens mit den Werten fand ich AutoRefresh auf den Detail Seiten ganz praktisch.

# In detail.php nach Header() ein Echo und gut.

header("Content-Type: text/html");
echo '<meta http-equiv="refresh" content="30"/>';

Ab- und zu versende ich auch mal eine eMail von meinem Android Smartphone.

Dazu benutze ich K-9.

Meiner Meinung nach ein komfortabler Mail Client. Nur dummerweise landen die gesendeten Emails nicht im selben Ordner wie im Thunderbird.

Das war mir erst aufgefallen, als ich mal eine versendete Nachricht suchte und nicht im Thunderbird fand.

Ich schaute ganz schön dumm aus der Wäsche, "verflixt, du weißt doch genau, dass du die mail verschickt ist, wo ist sie denn?"

Klar, mit etwas rumprobieren fiel mir dann schon der Name auf.

Im Thunderbird heißt der Ordner Sent und in K-9 Gesendet.

Dummerweise ist der Imap Ordner Inbox.sent.

Dies ist Client unabhängig. Der Client ist dafür verantwortlich, die eMails richtig zu speichern. 

Also bin ich im K-9 auf die Suche gegangen um das zu ändern.

 Der Weg ist Einstellungen->Kontoeinstellungen->Ordner

Dort habe ich den Ordner für gesendete Nachrichten auf INBOX.Sent und auch gleich den Entwurfsordner auf INBOX.Draft gestellt. 

Als Nacharbeit bleibt dann nur die Emails aus dem Ordner Gesendet in den Sent Ordner zu verschieben und Gesendet zu löschen.

Jetzt habe ich nur noch jeweils einen Ordner und wundere mich nicht mehr, dass ich eine eMail nicht finde, obwohl ich weiß, das ich sie versendet habe

Mit Überwachungstools ist die Linuxfamilie reichlich gesegnet. 

Seit mehreren Jahren setze ich collectd ein. Dieser Daemon schreibt fortwährend Perfomancedaten im rrd Format auf die Platte und ist netzfähig.

Das umwerfende an collectd ist seine einfache Konfiguration.

Das meiner Meinung nach am einfachsten zu verwendende grafische Interface ist CGP (Collectd Grafik Panel)

Auf Buster musste ich ein wenig fummeln, bis es wieder lief.

Es war zu lange her, dass ich damit was zu tun hatte, weil es einfach lief

Lange Rede kurzer Sinn:

Damit die Grafiken dargestellt werden können, muss Open_basedir angepasst werden:

Mit dem Plugin Processes habe ich ein wenig rumgespielt, dabei ist mir eine fehlende Grafik im CGP aufgefallen.

Im Apache error.log fand ich:

ERROR: No DS called 'value' in '/var/lib/collectd/rrd/domain.de/processes-pg_autovacuum/io_ops.rrd'

Ich habe es so gelöst.
in CGP/inc/types.db
Added
io_ops read:DERIVE:0:U, write:DERIVE:0:U

und in
CGP/plugin/processes.json
Added

        "ps_io_ops": {
                "title": "IO Operations ({{PI}}) on {{HOST}}",
                "vertical": "Ops per second",
                "type": "io",
                "legend": {
                        "read": {
                                "name": "Read",
                                "color": "0000ff"
                        },
                        "write": {
                                "name": "Write",
                                "color": "00b000"
                        }
                },

Warum blogge darüber nach ca. 6 Jahren Einsatz erst jetzt? Damit ich beim nächsten Mal wenigstens schon mal einen Eintrag habe

Im Ernst, gerade heute hatte ich mich gewundert, warum der Server so einen stark erhöhten Load hat, wo er doch meist nur vor sich rum dümpelt. Ich gebe zu, ich hatte erst wieder einen ungebetenen Gast in Verdacht und fahndete nach einen nicht vorhandenen Geist. Doch dann fiel mir ein, dass Softraid alle 4 Wochen Sonntags immer einen Check durchführte....

Bingo! # dmesg -T |grep md:
[Mon Jan 20 03:42:11 2020] md: data-check of RAID array md0
[Mon Jan 20 03:42:11 2020] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
[Mon Jan 20 03:42:15 2020] md: md0: data-check done.
[Mon Jan 20 03:42:16 2020] md: data-check of RAID array md1

Schön, das war also geklärt

(Wenn der Check fertig ist, momentan ist er bei:

cat /proc/mdstat |grep check
      [===================>.]  check = 99.6% (2919523968/2929609152) finish=7.4min speed=22487K/sec

Achso, also gleich fertig, dann warte ich noch die paar Minuten und schreibe gleich weiter

# dmesg -T |grep md:
[Mon Jan 20 03:42:11 2020] md: data-check of RAID array md0
[Mon Jan 20 03:42:11 2020] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
[Mon Jan 20 03:42:15 2020] md: md0: data-check done.
[Mon Jan 20 03:42:16 2020] md: data-check of RAID array md1
[Mon Jan 20 19:25:31 2020] md: md1: data-check done.

Der Check hat also knapp 16 Stunden gedauert und mich dadurch mit vielen (ca. 50 email vom Monitoring System) genervt.

Zu den Benachrichtitungen schreibe nochmal einen Extra Artikel, momentan ist das nämlich nicht mit Collectd realisiert. Dabei sollte ich gleich diesen vorhersehbaren Load Anstieg berücksichtigen und die Schwellwerte  in der Zeit anpassen.

Zum Abschluß heute noch einen Screenshot der Load Grafik, die sich sehr gut mit dem dmesg Eintrag deckt.

Ich habe die Kombi png / Canvas eingestellt, dadurch kann ich in der Detailansicht sehr fein zoomen. 

Ps: Bei Buster ist der Cronjob anders eingestellt, nämlich immer am 20. des Monats

42 3 20 * * root if [ -x /usr/share/mdadm/checkarray ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

Beim Durchsehen der Statistiken ist mir besonders beim Disk Traffic aufgefallen, dass ich mir die Bösewicht Sucherei wirklich hätte schenken können, dieses Bild ist eher unüblich für malware.

Update 02.03.2020

Anstatt die inctypesdb zu editieren einfach das Original von collectd verwenden.

Das behebt auch die anderen leeren Grafiken bei disk und smart

cd CGP
cp /usr/share/collectd/types.db inc/types.db

Update: 04.03.2020

Die DF Anzeige war mir viel zu unübersichtlich und 10fach gemoppelt.

Ich habe nun die folgenden Plugin Parameter und bin damit zufrieden.

        # ignore rootfs; else, the root file-system would appear twice, causing
        # one of the updates to fail and spam the log
#       FSType rootfs
        FSType "ext3"
        FSType "ext4"
        MountPoint "/boot"
        MountPoint "/home"
        MountPoint "/var"
        MountPoint "/tmp"
        MountPoint "/home/cloud"
        IgnoreSelected false
        ReportInodes True
#       ValuesAbsolute true
#       ValuesPercentage false
</Plugin>

Update: 07.03.2020

Im erweiterten Eintrag wird das konfigurieren der Notifications besprochen.

Ab- und zu mal einen Blick auf die lang dauernden SQL Queries gucken, macht Sinn

In /etc/mysql/mariadb.conf.d/50-server.cnf

Müssen entsprechende Einträge existieren:

# Enable the slow query log to see queries with especially long duration
slow_query_log
slow_query_log_file     = /var/log/mysql/mariadb-slow.log

Bei mir fehlte slow_query_log. Die Angabe des Logfiles allein reicht nicht.

slow_query_log also einfach hinzugefügt, die Datenbank gestartet und schon kanns losgehen.

Momentan ist es allerdings leer 

In MariaDB 10.2 und später ist das DYNAMIC-Zellenformat das Standardzellenformat. Wenn die Tabellen ursprünglich auf z.B. Compact stehen, kommt es zu Fehlermeldungen im mysql error.log.

[Warning] InnoDB: Cannot add field `basic_auth_password` in table `xxowncloud`.`oc_news_feeds` because after adding it, the row size is 8269 which is greater than maximum allowed size (8126) for a record on index leaf page.

Mit dem folgenden SQL Statement : (irgendwo im Netz gefunden)

SELECT NAME, ROW_FORMAT

FROM information_schema.INNODB_SYS_TABLES

WHERE ROW_FORMAT IN('Redundant', 'Compact')

AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS');

Gibt man eine Liste der Tabellen, die nicht auf DYNAMIC stehen, aus.

Ein Beispielauszug.

| xxowncloud/oc_properties                                        | Compact    |
| xxowncloud/oc_schedulingobjects                                 | Compact    |
| xxowncloud/oc_share                                             | Compact    |
| xxowncloud/oc_share_external                                    | Compact    |

Da es bei mir mehr als 1000 Zeilen waren, habe ich mit etwas einzeiler Script Magie (Dirty, hat aber geklappt) ein SQL Script generiert, um die Tabellen zu ändern.

Das Ergebnis des oberen SQL Kommandos in eine Datei als repair-inno.sql gespeichert.

Dann mit dem Einzeiler:

​cat repair-inno.sql |awk '{ printf "ALTER TABLE `%s`  ROW_FORMAT=DYNAMIC;\n",$2 }'|sed s'/\//\`.`/g'>innodb2dynamic.sql

die Datei in das hier gewandelt:

ALTER TABLE `xxowncloud`.`oc_properties`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_schedulingobjects`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_share`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_share_external`  ROW_FORMAT=DYNAMIC;

und mit mysql -u root -p ausgeführt.

Hat etwas gedauert, aber nun sind alle Tabellen geändert, wie ein erneuter Select Befehl zeigt.

Nun ist Ruhe im Error Log

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     58160         1050014
# 2  Extended offline    Completed without error       00%     55855         -

​wie gewünscht haben wir die defekte Festplatte mit der S/N: xxxxx für Sie ausgetauscht.
Leider haben wir momentan keine 3 TB Enterprise HDDs mehr im Lager,
daher haben Sie von uns eine 4 TB Enterprise HDD bekommen.

Als ich nach wenigen Minuten nach dem Einbau der Platte die Partitionierung durchführte und gerade dem Raid wieder die neuen Partionen hinzufügen wollte, stand der Server.

Es half nur ein manueller Hardware Reset, der bei Hetzner nach wenigen Minuten durchgeführt wurde.

Ursache war

wie gewünscht haben wir Ihren Server überprüft, es schien wohl ein Problem mit der neuen HDD 
im Zusammenspiel mit der alten BIOS-Version auf dem Server zu bestehen.

Wir haben die BIOS-Version auf die aktuellste von uns geprüfte und freigegebene Version 
aktualisiert und den Server ins installierte System starten lassen.

Tja so ist das eben. Naja, Downtime unter 30 Minuten, das Raid synct natürlich noch...

Heute wurde der Server von Stretch auf Buster angehoben.

Caveats:

Bei Dovecot hat sich eine Sache in der dovecot.conf Syntax geändert.

Gut beschrieben ist es hier: https://b4d.sablun.org/blog/2019-02-25-dovecot_2.3_upgrade_on_debian/

Weil ich ispconfig benutze, wurde das auch gleich upgegradet auf 3.1.15p2.

Dabei festgestellt, dass ich noch die diversen php7.3 pakete nachinstallieren musste.

Ich habe auch confluence laufen, also Java und tomcat gedöns. Deshalb ist postgres installiert, welches ein 

postgres reindexdb --all

benötigt. (Man wird aber darauf hingewiesen)

Mal sehen, was es noch für Probleme gibt ...

Nur mal so für mich zum merken.

Immer wenn ich mal auf einem neuen (jungfräulichen) Linuxrechner zu tun habe, fehlt mir meine Lieblingseinstellung für den vi

cat ~/.vimrc
:map <F2> :w\|!python3 %<CR>
:color industry
if has("autocmd")
  au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
endif

Der :map auf F2 sorgt für das unmittelbare Ausführen des Python Codes.

Aber das ist nur ein Gimmick.

:color ist selbsterklärend.

Wichtiger für mich ist der autocmd Teil. Das sorgt dafür, dass sich vi(m) merkt, in welcher Zeile ich in jeweiliger Datei war.

Ps: habt ihr evtl. noch andere Dinge, die das Leben erleichtern?

Ein Medion Akoya E1210 fiel mir nach vielen Jahren wieder in die Hände.

Es war Debian 8 Jessi installiert.

Irgendwann war das Gerät zu klein, vor allem die Auflösung und der etwas lahme Prozessor waren wohl das Manko, was zum einmotten führte.

Bevor ich das Teil wieder in die Versenkung schicke, dachte ich mir, guckst du doch mal was das schlaue Internet dazu sagt.

Das Ergebnis:

Das Gerät ist weitgehend baugleich zum MSI Wind U100

Unterschied zum MSI U100: im Medion ist kein eingelötetes RAM, sondern nur ein Steckplatz, der ab Werk mit 1GB bestückt ist.

Der Hammer ist allerdings, dass es die Möglichkeit gibt das E1210 mit dem MSI BIOS zu flashen, um dann auch die Übertaktungsmöglichkeiten zur Verfügung zu haben.. Immerhin sind bis zu 124% CPU Takt drin!

Also ans Werk:

Freedos von http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ geholt,

BIOS von https://www.msi.com/Laptop/support/U100#down-bios.

Damit einen bootfähigen USB Stick konstruiert und das E1210 damit geflasht.

Eine fast 100% richtige Anleitung wie man das macht ist hier:

https://feeding.cloud.geek.nz/posts/creating-freedos-bootable-usb-stick-to/

(Richtig: cp /usr/lib/syslinux/mbr/mbr.bin . Falsch: cp /usr/lib/syslinux/mbr.bin .)

Das Gerät muß dazu am Netz sein, wenn es auf Akku läuft, verweigert das Flash Utility die Arbeit mit der irreführenden Fehlermeldung, es hätte die vorhergehende BIOS Version nicht auslesen können, obwohl der Schalter, um die Überprüfung zu übergehen gesetzt ist.

Nach stromlos machen, 30 Sekunden warten muß beim nun folgenden ersten Boot die ESC Taste gedrückt werden, denn wie oben bereits erwähnt hat das MSI Board 1GB eingelötetes RAM, das natürlich initialisiert, bzw. gecheckt wird. Da das beim Medion nicht vorhanden ist, führt der Versuch zum schwarzen, eingefrorenen Bildschirm.

Mein Medion Akoya E1210 läuft nun mit Debian 10 Buster, Mate Desktop und 24% Übertaktung recht flott.

Was mache ich nun damit?

Ich denke im Elektronik Bastelzimmer ist es gut aufgehoben, um mal schnell einen Datenblatt nachzuschlagen oder ähnliches.

Ok, Chromium ist etwas träge, der Epiphany ist ein klein wenig flotter, eine reine Fraude ist das aber auch nicht, vielleicht sollte ich die 12,50€ für einen 2GB Riegel ausgeben, schadet bestimmt nicht. Denn nur der laufende Webbrowser mit ein paar einfachen Seiten und evince mit einem PDF Dokument reichen bereits aus um das RAM auszulasten und ersten 200MB Swap zu nutzen.

Die 80GB Hitachi Platte könnte man noch gegen eine SSD tauschen. Sollte ich mal mein Tuxedo XC1506 aufrüsten, fällt eine gebrauchte SSD 256 ab.

Um PIC Controller zu programmieren nutze ich immer den Pickit3 von Microchip. Funktioniert(e) prima, bis ich auf den Bolzen kam, den Programmer mal falsch, also um 180° verdreht anzuschliessen.

Interessanterweise funktioniert identifizieren und auslesen eines PIC immer noch, nur flashen geht nicht mehr.

Was also tun? Ich hatte bereits vor längerer Zeit einen Pickit2 geordert, der in der Bastelhölle der Erstverwendung harrte. Dies ist die Geschichte, wie ich den Pickit2 zur Mitarbeit überredet habe.

Einschub:

 Ein Hobby (Maker wie ich hat dennoch Auswahl genug, mein momentaner Standard Typ ist der PIC18F25K22, der wie viele andere unterstützt wird.

Im Netz findet man allerlei gute Anleitungen wie vorzugehen ist, wenn man den Pickit2 unter Linux zum Flashen benutzen möchte, hier meine Anleitung in gewohnt knapper Form.

Im Grunde habe ich mich hier orientiert: https://blog.toonormal.com/2016/01/26/using-a-pickit2-on-linux/

Die Sourcen sind nicht mehr direkt verlinkt, aber noch downloadbar. (Das Paket ist nur 3.6 MB klein.)

Schaut euch die Anleitung dazu im link oben an.

Wenn die Sourcen übersetzt sind und ein Test erfolgreich war, muß das Programm in einem sinvollen Pfad gepackt werden.

Ich habe mich für /opt/microchip/pk2cmd/release/ entschieden.

Dort findet man dann auch eine ausführliche Beschreibung:

/opt/microchip/pk2cmd/release/ReadmeForPK2CMDLinux2-6.txt

Es fehlt noch die Ergänzung der udev Rules, damit es auch als normaler User und nicht nur als root funktiert.

Dazu root werden und das File /lib/udev/rules.d/60-pickit2.rules

anlegen mit folgendem Inhalt:

cat /lib/udev/rules.d/60-pickit2.rules 
ATTR{idVendor}=="04d8", ATTR{idProduct}=="0033", MODE="0666"

Nun noch udev restarten, um sich einen reboot zu sparen.

# /etc/init.d/udev restart

Das wars auch schon.

(Wird noch weiter verfeinert)

Typische Aufrufe: Achtung: keine Leerzeichen zwischen den Optionen und deren Parametern!

pk2cmd -?V     # Auch ohne angeschlossenen Programmer möglich

Executable Version:    1.21.00
Device File Version:   1.63.148
OS Firmware Version:   PICkit 2 not found

mit dem Parameter -B kann eine alternative PK2DeviceFile.dat verwendet werden, um zum Beispiel zweifelfrei die neuere zu identifizieren

pk2cmd -B. -?V 

​Executable Version:    1.21.00
Device File Version:   1.62.00
OS Firmware Version:   PICkit 2 not found

pk2cmd -T -PF5 -GF./drin.hex

pk2cmd -T -PF5 -R

pk2cmd -D/opt/microchip/pk2cmd/release/PK2V023200.hex # Eine Firmware in den Pickit 2 laden.

pk2cmd -P -M -YP -F"/home/bed/Projekte/Rollladensteuerung/rollladen.hex" # MCU flashen und den PIC automatisch erkennen

ist natürlich langsamer als die gezielte Angabe des Typs

Ich hatte mich ja in meinem ersten Artikel über den neuen Laptop über die fehlenden Einstellungen für die Akku Ladestrategie mukiert. Jetzt (Aprif 2016) habe ich einen FAQ Eintrag gefunden, der genau dieses Problem angeht.

Beim Tuxedo XC1506 übernimmt das die BIOS Funktion "Flexicharge" FAQ Artikel im Supportforum von Tuxedo

Damit bin ich die gefährlichen Mikro Ladezyklen und das "immer Volle Pulle" auf 100% laden los.

Update 04.10.2019: Mein Laptop ist ca. 3,75 Jahre alt. Der Akku hat noch 94% seiner Design Kapazität. Ich habe die Schwellen auf 70% und 90% eingestellt. Der Laptop ist zu 95% am Netz.

Diese Frage hat mich heute Morgen beschäftigt, als mich Gnome mit einer Notiz "wichtige Aktualisierungen sind verfügbar" (leider keinen Screenshot gemacht) darauf aufmerksam machte und mir die Wahl zwischen "nicht jetzt" und "Ja, aktualisieren" ließ.

Na klar, wollte ich das mal ausprobieren, also auf "Ja" geklickt.

Dann kam der Hinweis, das dazu der Rechner rebootet werden muss.

WTF? Das hat mich dermaßen geschockt, dass ich erneut den Screenhot vergaß.

Also habe ich gesagt, "OK".

Was dann kam hat mich doch sehr überrascht. Es wurde sofort der Shutdown eingeleitet auf halben Wege  wurden dann die Pakete installiert und danach fuhr der Rechner  weiter mit dem Reboot fort.

Jetzt gab es auf dem Desktop diese Nachricht.

Hiervon habe ich einen Screenshot gemacht.

Es war ja schon lange in der internen Diskussion bei Debian, über das Für und Wider von automatischen Installationen.

Aus Sicht eines einfachen, evtl. von Windows migrierten Anwenders vielleicht gar nicht die schlechteste Idee.

Abschalten oder einfach ignorieren, bis man es dann selber macht kann man es ja trotzdem.

Doch ich bin besonders verblüfft über die Art und Weise. Ist der Reboot nun obligatorisch? Hoffentlich nicht, das wäre dann wirklich eine Verschlechterung. Bisher war das meiner Meinung nach eins der wichtigsten Argumente Linux anstelle Windows für die tägliche Arbeit zu benutzen. Wenn ich sehe wie häufig Windows Systeme wegen einer Software Aktualisierung reboot werden müssen....

Ps: ich suche nochmal die Pakete raus, die aktualisiert wurden,  es war vermutlich etwas dabei, das einen Reboot erfordert.

Nachtrag: Ja, diese Pakete waren betroffen. U.a. der Kernel.

Start-Date: 2019-08-14  08:38:35
Commandline: packagekit role='update-packages'
Upgrade: libpangoft2-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangoft2-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), linux-libc-dev:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chrome-remote-desktop:amd64 (76.0.3809.21, 76.0.3809.117), libgs9:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-image-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), gir1.2-pango-1.0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium-sandbox:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), chromium-common:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), pango1.0-tools:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangoxft-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango1.0-dev:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangocairo-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangocairo-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), ghostscript:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-headers-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 
4.19.37-5+deb10u2), libgs9-common:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-kbuild-4.19:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
linux-headers-4.19.0-5-common:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), libpango-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1)
End-Date: 2019-08-14  08:39:21

Die alte Variante gefiel mir besser, es wurde einfach eine Marker Datei " /var/run/reboot-required" angelegt.

Bei einem Server ist es vermutlich immer noch so, aber auch so mancher Entwickler wird sich ärgern, wenn er durch ein leichtfertiges "Ja" seine gesamte Palette an gestarteten Programmen schwinden sieht und er alles wieder einzeln öffnen muss.

Nun Gut, das passiert nur ihm sicher nicht nochmal... 

Zum nachlesen 

https://anarc.at/blog/2016-12-22-debian-considering-automated-upgrades/

https://www.pro-linux.de/news/1/24312/debian-diskutiert-%C3%83%C2%BCber-automatische-aktualisierung-als-standard.html

Nachtrag 18.8.2019:

So, wieder wird mir von gnome eine notwendige Betriebssystem Aktualisierung angezeigt.

Auch hier blau hervorgehoben, im Hintergrund noch gerade erkennbar wird von Neustart geredet.

Diesmal ist kein Kernel Update und auch die Libs sehen für mich nicht so auss, als wäre ein Neustart notwendig.

Also kurzerhand in der Console apt update und full-upgrade gemacht.

Es wird kein /var/run/reboot-required  angelegt, also ist kein Reboot aus Sicht des Packagemanagers notwendig, dennoch wurde der Anwender von der Notwendigkeit, (siehe links) infomiert.

Erschwehrend kommt ja noch hinzu, dass man, wenn man ok gesagt hat ja den Neustart nicht mehr aufhälten kann. Das macht Windows besser (Oh Gott, dass ich das mal sage ..), denn dort wird installiert und man bekommt die Option den Neustart später zu machen.

Fazit für mich, ich inoriere die GUI Benachrichtigung und mache es weiterhin in der Console, wenn es mir passt.