Dienstag, November 22, 2016

Kein Spass mit tar

Da versuche ich also, eine virtuelle Maschine aus Dateien in einem Verzeichnis auf einer anderen Maschine wiederherzustellen. Ich habe eine Live-CD in meiner neuen Maschine, partitioniere und formatiere die Platte, mounte sie, und ... ja, jetzt gehts los...

Auf der sendenden Seite mache ich ein tar cvz . | netcat 1.2.3.4 12345, auf der empfangenden Seite mache ich ein netctat -l -p 12345 | tar xz und kopiere so alle Dateien auf die neue Maschine rüber. Leider beendet sich der Stream nicht richtig, und nachdem alle Dateien kopiert wurden, muss ich noch mit Ctrl-C das netcat abbrechen.
Jetzt noch schnell den Bootloader einrichten, und ich bin fertig! Dazu kann ich ja einfach in einem root-Jail update-grub und install-grub verwenden!

chroot /mnt /bin/bash 
permission denied

Das kann ja wohl nicht wahr sein!

Stellt sich raus, dass zB /bin/systemd eine leere Datei ist auf meinem neuen System. Auf meinem alten ist es ein Symlink nach /lib/systemd/systemd. Wieso ist es eine leere Datei? Da sind noch mehr leere Dateien... Vielleicht auch Libraries? Ich suche nicht alles ab. Nach viel googlen finde ich raus, es ist wie folgt...:

tar entpackt Symlinks aus einem merkwürdigen Sicherheitsgrund nicht direkt, sondern erstellt Platzhalterdateien, die in einem zweiten Lauf erst (wenn sich die Platzhalterdateien nicht verändert haben) durch Symlinks ersetzt werden. Da der mein Netzwerkstream sich nicht richtig beendete, musste ich tar und netcat ja mit Ctrl-C abbrechen, und da ich mir keine Gedanken darüber machte, machte ich das auf der empfangenden Seite. Damit habe ich aber verhindert, dass dieser zweite Lauf durchlaufen konnte, und behielt leere Dateien. Meine Kopie war nicht in Ordnung, chroot funktionierte nicht.
Als ich aber auf der sendenden Seite mit Ctrl-C abbrach, konnte sich tar auf der empfangenden Seite korrekt beenden, seinen zweiten Lauf machen (den man nicht mitbekommt. Es beendet sich einfach), und zack! meine Kopie ist in Ordnung!

Danach funktionierte alles. Mal wieder zwei Stunden im weg mit unvorhersehbarem!

Mittwoch, November 16, 2016

Firefox fix machen

Ich habe endlich eine Möglichkeit gefunden, meinen Firefox zu beschleunigen. Die Lösung ist es, die ganzen Optimierungen abzuschalten.

javascript.options.asmjs = false
javascript.options.baselinejit = false
javascript.options.ion = false
javascript.options.compact_on_user_inactive_delay = 15000

Die JIT-Compilate brauchen entweder viel Speicher oder sind nicht gut mit der Garbage-Collection kompatibel, ich weiss es nicht. Mit diesen Einstellungen fahre ich meinen Firefox von manchmal bis zu 2,5GB, wo die GC ständig zuschlägt aber nix wegräumt auf eher 1,2GB runter, und die GC funktioniert.

ion, baselinejit und asmjs sind dazu da, Javascript schneller auszuführen. Meine Maschine ist mittlerweile eigentlich schnell genug, das auch ohne diese Optimierungen zu schaffen, und diese Optimierungen zerstören offenbar die Speicherverwaltung.

(Bezüglich Firefox 49.0.2)

Donnerstag, Juli 21, 2016

Spass mit tun/tap unter Linux

Heute hab ich ein bisschen Spass mit dem tun/tap-Treiber von Linux gehabt. 

Hier die einfache tun_alloc() abgeschrieben. Mein Code liest nun endlos (die meisten Beispiele benutzen select(), aber ich blockiere einfach) Pakete, vertauscht Source- und Destination-Address, und schreibt es wieder zurück auf das Interface. Das ist insgesamt nicht besonders sinnvoll, 
... aber ...
obwohl es eine Checksumme (crc32) gibt, die den Header sichern soll, kann man trotzdem, ohne die neu zu berechnen, einfach Source- und Dest-Adresse tauschen, weil die crc32 trotzdem korrekt bleibt. Eine merkwürdige Eigenheit dieses Checksummenalgorithmus.

Trotzdem nicht besonders sinnvoll, aber es gibt ein Protokoll, das genauso funktioniert: Ping! Und siehe da, ping geht auch.

Wichtig, was mir etwas Kopfzerbrechen gemacht hat: Das tuntap-Interface liefert einem einen File-Deskriptor, dem man mit read() und write() bearbeiten kann. Allerdings liefert read() immer ein Paket von Anfang an. Man kann nicht "testweise" in ein Paket reinlesen und dann im Header nachschauen, wie lang das Paket noch ist, und dann ein passendes zweites read() aufrufen, wie man das vielleicht bei einem tcp-Stream tun würde oder bei einer Datei.

So, jetzt mal Butter bei die Fische:

Mein Code:
tuntaptest.c
--------------------

// Tun/Tap Test

#include <sys/socket.h>    //Mo: or else doesn't compile. (errors in if.h)
#include <linux/if.h>
#include <linux/if_tun.h>

#include <sys/select.h>

#include <netinet/ip.h>
#include <unistd.h>

#include <stdio.h>
#include <string.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <stdlib.h>

#include <arpa/inet.h>

/////////////////////////////////////////////////////////
// copied from https://www.kernel.org/doc/Documentation/networking/tuntap.txt

int tun_alloc(char *dev)
{
  struct ifreq ifr;
  int fd, err;
  
  if( (fd = open("/dev/net/tun", O_RDWR)) < 0 )
    perror("open(/dev/net/tun) < 0");
  
  memset(&ifr, 0, sizeof(ifr));
  
  /* Flags: IFF_TUN   - TUN device (no Ethernet headers) 
   *        IFF_TAP   - TAP device  
   *
   *        IFF_NO_PI - Do not provide packet information  
   */ 
  ifr.ifr_flags = IFF_TUN | IFF_NO_PI;   //Mo: ohne IFF_NO_PI hatte ich ein padding-Problem.
  //ifr.ifr_mtu   = 1500;      // Mo: Hinzugefuegt.
  
  if( *dev )
    strncpy(ifr.ifr_name, dev, IFNAMSIZ);
  
  if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
    close(fd);
    return err;
  }
  strcpy(dev, ifr.ifr_name);
  return fd;
}

//////////////////////////////////////////////////////////////////////

void printip(u_int32_t addr)
{
  printf("%i.%i.%i.%i", addr&0xff, (addr>>8)&0xff, (addr>>16)&0xff, (addr>>24)&0xff);
}

union {
  unsigned char ip_packet[65536];
  struct iphdr iphdr;
} packet;

int main(int argc, char **argv)
{
  char devname[IFNAMSIZ] = "mirror%d";
  int fd, n;
  u_int32_t swaptmp;

  fd = tun_alloc(devname);
  printf("devname: %s\nfd: %i\n", devname, fd);
  printf("sizeof iphdr = %lu\n", sizeof packet.iphdr);
  fflush(stdout);

  while (1) {
    // Genau ein read() pro Paket.
    // Wenn man nicht das ganze liest (bspw. erstmal nur den Header)
    // bekommt man den Rest nicht mehr.
    n = read(fd, &packet, sizeof packet);

    printf("Source IP: ");
    printip(packet.iphdr.saddr);
    printf(" Dest IP: ");
    printip(packet.iphdr.daddr);
    printf(" headerlength=%i", packet.iphdr.ihl);
    printf(" length: %i\n\n", n);
    
    ///// Wir swappen nun daddr und saddr und
    // schreiben das paket zurueck auf die
    // leitung.
    // WENN das ein ping war, muesste es korrekt
    // beantwortet sein. Wenn nicht, passieren halt
    // komische dinge, aber wen interessierts. ;)

    swaptmp = packet.iphdr.saddr;
    packet.iphdr.saddr = packet.iphdr.daddr;
    packet.iphdr.daddr = swaptmp;

    write(fd, &packet, sizeof packet);
  }
}





Dazu gibt es dann ein kleines Configscript:

configtun.sh
------------
#!/bin/bash

ip addr add 192.168.123.1/24 dev mirror0
ip link set up mirror0


Und nun führen wir das ganze aus:

$ gcc tuntaptest.c -o tuntaptest
$ sudo su # ich bin grad auf einem ubuntu...
$ modprobe tun
$ ./tuntaptest

# ... neue shell ...
$ sudo su
$ bash configtun.sh
$ ip addr
...
mirror0   Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet Adresse:192.168.123.1  P-z-P:192.168.123.1  Maske:255.255.255.0
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:6 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:6 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:500
          RX-Bytes:393216 (393.2 KB)  TX-Bytes:264 (264.0 B)


schonmal ganz cool...

und nun ...
# ping 192.168.123.42
PING 192.168.123.42 (192.168.123.42) 56(84) bytes of data.
64 bytes from 192.168.123.42: icmp_seq=1 ttl=64 time=1.08 ms
64 bytes from 192.168.123.42: icmp_seq=2 ttl=64 time=0.668 ms
64 bytes from 192.168.123.42: icmp_seq=3 ttl=64 time=0.335 ms
^C
--- 192.168.123.42 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.335/0.696/1.085/0.306 ms


# ping 192.168.123.23
PING 192.168.123.23 (192.168.123.23) 56(84) bytes of data.
64 bytes from 192.168.123.23: icmp_seq=1 ttl=64 time=0.340 ms
64 bytes from 192.168.123.23: icmp_seq=2 ttl=64 time=0.433 ms
64 bytes from 192.168.123.23: icmp_seq=3 ttl=64 time=0.575 ms
^C
--- 192.168.123.23 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.340/0.449/0.575/0.098 ms


antwortet einfach jede Adresse in dem Subnetz :)

Mittwoch, Mai 04, 2016

Using a remote pulseaudio to mitigate Virtualbox soundproblems

Applicability

I had this problem with audio in my Virtualbox guest, Xubuntu, on my Mac OS X host.
But this should be applicable -- in part or in whole -- to any host which is able to run pulseaudio and ssh and any unix guest which uses pulseaudio as defaultsoundsystem.


What did go wrong?

So i have this Mac from work, but I like working under Linux, xfce, sometimes I install debian, sometimes Xubuntu. This I did in a Xubuntu guest in Virtualbox on a Mac OS X host.
So I like using my Xubuntu, and I use it for most things that work: Watching movies, listening to music, working, everything. So I like the audio to work.

It does mostly work, but not perfect. Sometimes I connect the Macbook to a bluetooth audio receiver or plug in the hdmi to watch something on my tv screen. Sometimes I plug in headphones. All of these are visible in the audio menu up top, which shows a list of all this devices when I alt-click it. I can choose an audio output device from this list and the Mac promptly plays over that device. 
But not the Virtualbox. The Virtualbox just stays on the device it was playing audio over when it got startet. It doesn't switch to what I choose. (Sometimes it did, but not always, and that got very annoying)


The Solution

This one is kind of complicated.

the host

First, you have to install pulseaudio on your host machine, I did this with brew install pulseaudio, using homebrew.

Now, you have to configure your pulseaudio so you can use it over the net:
pulseaudio --dump-conf dumps you the pulseaudio config which includes the path of the default.pa file which we have to edit. On my machine it lies under
/usr/local/Cellar/pulseaudio/8.0/etc/pulse/default.pa
In this file, there is a commented out line which loads the module
module-native-protocol-tcp
I commented that line in and added some parameters:

load-module module-native-protocol-tcp  auth-ip-acl=127.0.0.1;192.168.0.0/24;10.0.2.15 auth-anonymous=1
(yeah, I googled that, don't really know, what that's doing, although I have an idea, of course. You can adjustt the IP ranges of course, in this example, we will only use the 10.0.2.15)

In the same directory as the default.pa there is another config file named daemon.conf. In this file you set allow-exit=no and comment out the exit-idle-time so pulseaudio doesn't exit if it's idle.

the guest

On the guest, you only have to run pax11publish -e -S 10.0.2.2 where 10.0.2.2 is the IP of the host, and you should be able to use the host's pulseaudio to play sound. done.

Automating it

Make sure you have an ssh-server on the host. Have an ssh-client on the guest. Create a keypair on the guest with ssh-keygen and configure everything so that you can connect from the guest to the host without a password.

Install screen on the host using brew install screen screen. Also, create a script:
cat > startpulseaudio.sh << EOF
#!/bin/bash
exec > ~/.pulselog 2>&1
echo starting pulse
pulseaudio
echo pulse aborted

EOF

On the guest, you create a script:
cat > starthostaudio.sh << EOF
#!/bin/bash

ssh -vT 10.0.2.2 "bash -l -c 'screen -S hostaudiopulse -d -m bash ~/startpulseaudio.sh'"
pax11publish -e -S 10.0.2.2
EOF


where -- as before -- 10.0.2.2 stands for the host IP.

Add starthostaudio.sh to your autostart on the guest, and you should be all set.

Well d'uh!


Dienstag, Februar 02, 2016

ZMODEM lebt!

Ja, ist super, um Dateien irgendwie durch ssh-Tunnel zu kopieren!
Auf beiden Endpunkten "lrzsz" (Das sind die Kommandos "sz" und "rz") installieren.
Auf dem Endgrät benötigt man "screen", denn Terminals, die selbst noch ZMODEM beherrschen gibt es quasi nicht mehr.

Screen kann man dazu animieren, ZMODEM Kontrollcodes zu erkennen und darauf zu reagieren. Allerdings braucht auch Screen dazu dann sz oder rz.
Diese Funktion muss auch noch aktiviert werden.
Entweder im laufenden Screen "C-a : zmodem catch", bzw "C-a : zmodem auto" (letzteres sollte auch richtig funktionieren).
Stattdessen kann man auch in die ~/.screenrc "zmodem auto" schreiben.

Auf dem Zielgerät müssen auch sz und rz installiert sein. Will man nun eine Datei senden, so gibt man auf dem Zielgerät "rz" ein (Das heisst "Receive ZMODEM"), Screen erkennt den darauf folgenden Kontrollstring und läd dazu ein, lokal das entsprechende sz-Kommando auszuführen, die Switches sind vorausgefüllt, und man muss nur noch den Dateinamen angeben.

Will man vom Zielgerät eine Datei empfangen, so benutzt man stattdessen "sz" (Dann sendet das Zielgerät, deshalb gibt man dort sz = "Send ZMODEM" ein).

scp ist wohl üblicherweise einfacher, ausser, man möchte mehrere Hops überbrücken.

Ausserdem: ZMODEM war früher gut!

Freitag, Juli 25, 2014

in Kauf genommene Obsoleszenz? Oder: Das Wurstbrot war frueher gut!

Schon wieder les ich einen Artikel ueber den "Mythos geplante Obsoleszenz"

http://www.heise.de/tp/artikel/42/42321/1.html

Das Problem scheint mir zu sein, dass das Phaenomen am falschen Ort gesucht wird. Ich naemlich kann es taeglich sehen. Und nein, nicht da, wo es angeblich beobachtet werden kann, und jedesmal wieder die gleichen urbanen Legenden aufgedeckt werden.

Die herkoemmlichen Geschichten sind die von Gluehlampen mit beschraenkter Lebensdauer und Druckern mit Chips, die Ausdrucke mitzaehlen und nach 100000 Seiten aufhoeren. Bla.

Unangemessene Problemloesungen
Die Wirtschaft muss brummen, d.h. es muessen Produkte verkauft werden. Immer mehr Produkte, die heute verkauft werden, loesen aber kein Problem, loesen es schlecht, oder sie loesen ein Problem, werfen aber drei neue auf. Was hier absichtlich dem Kunden vorenthalten wird, ist Interoparibilitaet. Standardinterfaces.

Die Diskussion wird immer anhand von Beispielen gefuehrt, also mach ich das jetzt mal auch.

Plastikfeuerzeuge mit eingebauter Taschenlampe
Ich bin nicht stolz drauf, aber ich bin ja Raucher. Wenn ich nix zum Anzuenden dabei hab, kauf ich im Kiosk normalerweise Streichhoelzer. Ansonsten hab ich noch ein schoenes Zippo. Das ist so die Methode, die am meisten Muell vermeidet.
Nur noch so mitteltoll sind Plastefeuerzeuge. Halten nicht lang, gehen meist kaputt, bevor sie leer sind und sind danach aber recht egaler Muell. Verbrennbares Plastik und ein bisschen Blech. Kein Problem.
Aber wozu sind diese Feuerzeuge mit "Taschenlampe" da? Eine LED und ein paar Knopfzellen, schon hat das Füertüch eine Funktion mehr, und ein Verkaufsargument mehr! Nur, wer hat sowas schonmal ernsthaft gebraucht? Hier wurde kein Problem geloest, aber das Ding, das eh bald kaputt ist, mit Batterien und Elektronik von Hausmuell zu Sondernmuell degradiert.

Das Plastikfeuerzeug ist natuerlich nur ein Beispiel fuer unglaublichen Kleinscheiss mit Elektronik drin, den kein Mensch braucht. Schimpfend muss ich da Zeitungen nennen, die heute einen Artikel ueber Elektroschrott schreiben, morgen ueber die schlimme Plastiktuete, uebermorgen einen ueber die Kohlelobby, und wie schlimm der Klimawandel ist. Kaufen Sie ein Abo! Sie kriegen einen leuchtenden Kugelschreiber als Kundengeschenk! (Achtung, nicht im Hausmuell entsorgen! Enthaelt schwermetallhaltige Batterien!)

Android-Handies
Die Elektronikwelt ist schnelllebig, und ich bin eigentlich kein Hardwarefreak. Ich brauche nicht unbedingt das neueste, tollste. Ich hab mir ein Galaxy S (das erste) gebraucht gekauft, 50 Euro, zack. Kann alles, was ich will: Emails, Kalender, Facebook, Web, Chat, Maps, Navi, zack!
Allerdings ist es teilweise (vor allem, wenn ich Facebook drauf hab) schmerzhaft lahm. Das war sicher nicht immer so, sonst haette man es, als es neu war, ja nicht gut verkaufen koennen.
Das heisst, mein Handy wird von aussen (also ohne meine Mitwirkung, ausser, dass ich App-Updates mache, die ich ja unbedingt machen soll, wegen der Sicherheit!) immer langsamer und unbenutzbarer gemacht. Obsolet gemacht. Ich weiss nicht, ob  mit Absicht, aus Doofheit, Ignoranz oder ob es einfach in Kauf genommen wird.
Heute ist mein Handy lahm, morgen kann ich kein aktuelles Android mehr drauf installieren, uebermorgen gibts fuer mein veraltetes Android keine funktionierende Facebook-App mehr. Mein Handy verliert, ohne sich selbst wirklich zu aendern, oder richtig kaputt zu gehen, Funktionalitaet. Geplante Obsoleszenz?

Und dazu, dass ich kein aktuelles Android mehr installieren kann. Das geht eh nur bei weniger Herstellern auf die vorgesehene Art und Weise ueberhaupt. Auf meinem hab ich CyanogenMod laufen (http://get.cm). So hab ich ein halbwegs aktuelles Android, obwohl mein Hersteller das Geraet schon lange als obsolet ansieht. 

Computer - WindowsXP
Computer haben das gleiche Problem. Sie hatten einen um ein bisschen im Internet zu browsen, E-Mails zu schreiben und von Zeit zu Zeit mal einen Brief? Ihr PC war 8 Jahre gut? Tja. WindowsXP ist ausgelaufen, wenn Sie ins Netz wollen mit Ihrem Kasten, dann kaufen Sie sich am besten einen neuen, denn das Betriebssystem, das noch supportet wird, laeuft auf Ihrer alten Kiste nicht mehr. Die kann zwar alles, was sie wollen, aber... sie ist jetzt obsolet!

Smartboards
Schulen werden jetzt modern und digital. Daher bekommen die jetzt sogenannte Smartboards. Das ist im Prinzip eine festinstallierte, harte Leinwand mit Touch-Funktion. Da dran haengt ein Rechner. Der Rechner zeigt sein Monitorbild per Beamer auf der Leinwand, und man kann direkt drauftatschen und so Mauseingaben machen. Total modern und ja, irgendwie auch ziemlich cool.

Das Bloede ist nur: Alle Schulen bekommen die jetzt. Und sie ersetzen damit die alten Tafeln.
In Grundschulen haben wir jetzt also anstatt einer Tafel mit Kreide ein empfindliches, sauteures Geraet, welches ordentlich Strom verbraucht (Beamer). Der Rechner und der Beamer surren die ganze Zeit im Unterricht, der Rechner braucht Zeit zum Hochfahren zum Unterrichtsbeginn, und muss regelmaessig geupdatet werden. Und wenn WindowsXP auslaeuft, muss der Rechner auch noch ausgetauscht werden. Die Lampen fuer den Beamer sind auch sauteuer.
Anekdote: Ein Lehrer erzaehlte mir, die Schule haette an einem Smartboard einen neuen Rechner angebracht, jetzt mit Windows7. Es gab Treiberprobleme. Die Firma Smart meinte, das Smartboardmodell sei alt, die Garantie sei abgelaufen, und Windows7-Treiber gaebe es fuer dieses alte Modell nicht mehr. Da muesse halt ein neues Smartboard angeschafft werden.
Ich antwortete sueffisant, tjaha, die alte Kreidetafel wuerde noch gehen. Sagte der Lehrer: Die Kreidetafeln seien auch nicht billiger (die grossen, an der Wand aufgehaengten).
Mit der Frage, wie oft die Kreidetafeln denn ausgetauscht werden muessen, hatte ich meinen Punkt dann gemacht: Nie.
Geplante Obsoleszenz?

Apple und Beats
Apple hat jetzt Beats uebernommen, und stellt jetzt eigene Kopfhoerer vor. Diese neuen Kopfhoerer dekodieren selber ein digitales 48kHz-Signal  (CDs haben nur 44,1kHz, d.h. die Kopfhoerer koennen mehr, als das normale Eingangssignal hergibt) und dafuer brauchen sie einen neuen, eigenen, nur bei Apple verfuegbaren Stecker.
Wenn Sie also in Zukunft an ihrem Applegeraet Musik hoeren wollen. Allein, mit Kopfhoerern, sind ihre alten Kopfhoerer, mit dem Stecker, den man seit 50 Jahren verwendet... obsolet. Nicht, weil Sie ein Problem gehabt haetten, das geloest werden musste, nein. Weil Apple Kopfhoerer verkaufen wollte, auf einem gesaettigten Markt. Dass normale, Analoge Kopfhoerer so schlecht seien, dass die Welt unbedingt digitale braucht... Das hab ich bisher noch nicht gehoert.

http://www.heise.de/mac-and-i/meldung/Apple-veroeffentlicht-Spezifikationen-fuer-Lightning-Kopfhoerer-2216060.html

Fernsehen und Radio
Ja, ich gebe es zu: DVBT sieht besser aus als das alte Analogfernsehen. Trotzdem: Es gab einen Standard, in Deutschland PAL, ueber den Fernsehen uebertragen wurde, und im Kabelnetz immer noch uebertragen wird. Das hat ueber die Jahre auch ein paar Erweiterungen erfahren, um zB 16:9 Bilder uebertragen zu koennen.
Dann. Zack! Kam DVB-T. Alte Roehren mit Antenne dran funktionierten nicht mehr, nun brauchte man eine Kiste Elektroschrott, um seine alte Roehre einfach fuer das weiternutzen zu koennen, fuer das man sie vorher auch schon benutzt hat. Oder einen neuen Fernseher mit eingebautem DVB-T-Tuner. Schlitzohrig auch, dass das zugehoerige DVB-C so anders funktioniert, dass man zwar vom Kabelnetzbetreiber das angeboten bekommen kann, aber mit einem DVB-T-Tuner nicht empfangen kann. Da braucht man wieder eine... richtig: Box.
Und achja! Sie haben den ganzen Klimbim bereits? Schoen fuer Sie. Die eine private Sendergruppe will oder ist bereits bei DVB-T ausgestiegen, also gibts jetzt weniger Programme, und zweitens... Wussten Sie, dass DVB-T2 bald kommen soll? Dann haben sie zu Hause wieder einiges an... obsoletem Elektroschrott.

http://www.heise.de/newsticker/meldung/ARD-und-ZDF-wollen-ab-2017-auf-DVB-T2-umsteigen-1960584.html

Und nun zum Radio. WTF?! Das Wurstbrot war frueher gut! (https://www.youtube.com/watch?v=rfAYPP8RtVw )

Also... Seit dem Krieg, also eigentlich schon seit vor dem Krieg gibts Radio. Das gibts auf der ganzen Welt. Radio. Egal was ist, egal wo man wohnt, und man sieht es in jedem einzelnen Hollywood-Katastrophenfilm... man hoert Radio, und wenn draussen die Welt untergeht und der Strom weg ist, dann hoert man die Unwetterwarnung oder den Fliegeralarm im Radio. Man hoert die Verkehrsmeldungen im Radio, dass man auf die "spielenden Kinder auf der A1" achtgeben kann. Ich persoenlich besitze vielleicht 5 Radios. Eins im Handy, einen Radiowecker, ein Kuechenradio, dann so ein mobiles Werbegeschenkding und eins im Auto. Ueberall stehen Radios. Die sind mittlerweile billig, klein, und koennen ueberall eingebaut werden.
Und nun? Nun kommt das neue Digitalradio DAB+. Irgendwann. Und dann soll das analoge auch abgeschaltet werden. ( http://www.heise.de/newsticker/meldung/Digitalradio-Konsortium-fordert-UKW-2018-abschalten-1888859.html ) Dann kriegen Sie den Verkehrsfunk im Auto nicht mehr rauschend und schlecht verstaendlich, weil Sie durch ein Tal fahren, sondern gar nicht mehr. Weil: Digital ist da empfindlicher. Wenn sie was empfangen, dann die besten Hits der 70er, 80er, 90er und Nullerjahre! Dafuer in HighDefinition!
Super werden auch die 300Mio obsoleten Radios in Deutschland, die dann alle nach Afrika wandern ( http://dradiowissen.de/beitrag/elektroschrott-landet-in-afrika ), und dass sie mit ihrem DAB+-Autoradio natuerlich im Ausland kein Radio mehr kriegen, ausser natuerlich, sie haben fuer einen Analogtuner mitbezahlt beim Kauf. Einem Analogtuner, den Sie aber vermutlich nie oder nur sehr sehr selten benutzen. Way to go!

Geplante Obsoleszenz ein Mythos? Hrhrhr. Wish it were so!

Donnerstag, Juli 24, 2014

Debian Jessie systemd. Why? Oh! Why?!

Alter was?!


Also...

Ich mache da also gestern apt-get dist-upgrade auf meinem Debian/testing Jessie, und bekomme jetzt diesen hochmodernen systemd. Tschuess SysVInit. Tschuess Verstehen, was passiert. Aber das hab ich gestern ja noch gar nicht gemerkt. Der Rechner lief ja noch. Bis ich ihn dann runterfuhr, um ins Bett zu gehen.

Heute dann fahr ich meinen Rechner also wieder hoch. Was begruesst mich?

Welcome to the emergency console. After logging in, use journalctl -xb to see what went wrong (Sinnerhaltend zitiert.) Natuerlich stand das nicht in der letzten Zeile, sondern irgendwo in der Mitte der Schirms inmitten von Matrix-Style-Konsolentext. Natuerlich gabs auch keinen Login, also auch kein 'after logging in'. Danke. Und nun? Jedenfalls irgendwelches Bla von wegen 'systemd', also wusste ich, ok, gestern war wohl der Tag, an dem Debian entschied, Systemd kommt jetzt. Was stand da sonst noch so? Hm. /run/systemd/private nicht gefunden. DBus funktioniert nicht. Ratterratter. Am Schluss haengts irgendwie beim Swap starten. Sehr merkwuerdig alles.

WTF!


Also Reboot. init=/bin/bash. / schreibbar mounten.

emacs /etc/fstab. Kein richtiges TTY. Emacs geht nicht. Fuck You! Nano geht. Swap entfernt.

Reboot. Ich krieg n Login! Auf der Textkonsole. Grr. Hm... Das Update gestern koennte natuerlich auch den Graphiktreiber uebermalt haben. sgfxi soll mir mal n neuen Treiber installieren. Mist. Kein Netz, der Treiber kann nicht gezogen werden. dhclient eth0. Netz! Fast... Namensaufloesung geht natuerlich nicht. Hm. nano /etc/resolv.conf. Komisch. Die Datei ist leer. Hm. nameserver 8.8.8.8 CTRL-O. Speichern? Geht nicht. Die Datei existiere nicht. WTF!

Ja, meine Damen und Herren! Die Datei ist bloss ein Symlink nach /etc/resolvconf/run/resolv.conf Wobei natuerlich, nicht zu vergessen, /etc/resolvconf/run ein Symlink nach /run/resolvconf ist. Soweit, so einfach. Achja. Die Fehlermeldung? Nun: Das Verzeichnis /run/resolvconf existierte nicht. Kein Wunder /run liegt in einem tmpfs und wird bei jedem Boot neu angelegt, bei einem init=/bin/bash ist das nicht gefuellt. Also war der Symlink /etc/resolvconf/run/ -> /run/resolvconf tot, und damit konnte die Datei unter dem Verzeichnis natuerlich nicht gespeichert werden. Klar oder? "File not found"... Das mit den Fehlermeldungen ueber wir nochmal.

m(


Nun hab ich also Netz und kann mir also den Graphiktreiber wieder installieren.

Reboot. Bunt! Kompletter Lockup! Hier half nun leider nur noch der Powerbutton. Hmm... Bloed das. Na, dann wollen wir doch mal einstellen, dass das Bunt halt nicht gestartet wird.
init=/bin/bash .
systemctl disable display-manager
...Could not connect to dbus

Ah. Jetzt kommen wir zu den wirklichen Qualitaeten von Systemd. Man kann das Problem mit dem Booten im Systemd nur dann beheben, wenn der Systemd laeuft! Jaja! Weil Configdateien? Neeeein! Das waere ja zu einfach! Naja. Doch Configdateien. cd /etc/systemd/system ; mv display-manager.service display-manager.service.disabled Super. Das funktioniert. Nun kriege ich nach einem Reboot wieder einen richtigen Textlogin. Das ist doch schonmal ein Zustand, mit dem man arbeiten kann.

Oah ey! Neee!


So. Nun koennen wir uns dem zuwenden, was eigentlich kaputt ist!. Also. Systemd findet immer diese /run/systemd/private nicht, das ist ein Socket, und darueber geht irgendwie die systemd-interne Kommunikation und die Kommunikation mit den Interface-Tools. Hm. Gut. Schaun wir mal. Vielleicht kriegen wir ja Hinweise. journalctl -xb Das soll ja, wie mir Systemd schon selbst erzaehlt hat, da mal Logs zeigen.

/run/systemd/private not found.

Ah. Cool. journalctl funktioniert nur, wenn Systemd laeuft. D.h. wenn Systemd abschmiert hab ich keinerlei Moeglichkeit zu sehen, was eigentlich los ist. In /var/log findet sich jedenfalls nix. Auch nicht, nachdem ich in /etc/systemd/system.conf: Logging=persistent reinschreibe. Fuck You!

Na gehen wir mal forschen. Also in /run gibts nicht mal ein /run/systemd. komisch. Hmhm. Google. Hm. Sollte es aber. Hm. Auf einen Hunch hin, geb ich mount ein. Was sehen meine mueden und genervten Augen? /run ist 2x gemountet.

umount /run. Geht nicht. In Use.
umount -l /run. ok... Whoa. journalctl -xb liefert ein Log. Ich werd nicht mehr! Den Kommunikationssocket gabs doch. Er war nur verdeckt von einem ueberfluessigen Mount. Hah! Dann werden wir das ja mal ganz leicht los! Wo kommt der 2. Mount denn her? Hm... in /etc/fstab wird /run nicht gemountet. Aehm. Ja. Fragen wir journalctl. Ich komm zwar mit den bloeden Optionen noch nicht so klar, aber was ich finde ist nix mit /run, sondern mit /var/run. Genauer var-run.mount. Irgendwie ist das nicht das gleiche, aber ich hab das Bauchgefuehl, dass ich dem nachgehen sollte. var-run.mount also. Das ist so n Systemd-Ding. So ein Mount-Target-Unit-Dings. Systemd hat so Dateien, die auf .service und .mount enden, und da definiert man dann seine Services und Mountpoints. Weil /etc/fstab ist ja aus der Mode.
Die var-run.mount existiert nur nicht. find, locate, updatedb, locate. Nein. Sie existiert nicht. Vielleicht ist dieses Target-Mount-Dings nur ein Eintrag in einer Datei die anders heisst? Hm... Greppen wir mal.

Die Ironie!


/lib/systemd/system# rgrep var-run.mount *
grep: Ungültige Option -- .


Ok. Was?! Nachdem ich nun also langsam anfange, meine Model-M kaputt zu schlagen, merke ich, dass Systemd so schlau ist, in dem Verzeichnis eine Datei namens -.slice aufzubewahren. Und alle Tools, ls, grep, rgrep, etc nehmen hier an, ein Switch kaeme nach dem Minus, und aber einen Switch -. gibts nicht. Abbruch.

Also:
/lib/systemd/system# rgrep var-run.mount -- *
debian-fixup.service:Before=var-run.mount var-lock.mount sysinit.target


Dies hier ist tatsaechlich das einzige Vorkommen im Systemd, welches ich gefunden habe. Dies ist allerdings nicht die Definition, sondern eine Referenz. Nicht das, was ich suche. Die Ironie? Die Datei in dem das vorkommt, sollte ein Problem mit Debian und Systemd fixen!

Endgame

Nun suche ich also noch ne Weile wild und willkuerlich herum, und weiss langsam nicht mehr wirklich, was denn nun. Aber Logs sind doch das, was am Ende hilft. journalctl und ein suchen nach var-run.mount liefert mir den Hinweis, dass es sich bei var-run.mount nicht um eine Datei handelt (dabei gibts einige .mount-Dateien!), sondern um eine quasi virtuelle Datei, die die Zeile /var/run in der /etc/fstab beschreibt. Und da /var/run ja in der Transition nach /run zu einem Symlink wurde, wurde ein Mount nach /var/run zu einem Mount nach /run, welcher dann den Systemd-Kommunikationssocket ueberdeckt hat.

Rausmachen.

Geht.

Ich hasse euch alle fuer eure Windosen und Apples, die einfach so gehen! </sarkasmus>