Having read about using syslinux as a boot-loader for virtual machines I tried to replace grub2 on one of the Fedora 24 virtual machines I am using with syslinux:

Not completely knowing what to do I did:

  • dnf install syslinux-extlinux.x86_64
  • /sbin/extlinux –install /boot/extlinux/

The I tried to create a configuration file using grubby:

  • grubby --extlinux --add-kernel=/boot/vmlinuz-4.4.6-300.fc23.x86_64 --title="4.4.6" --initrd=/boot/initramfs-4.4.6-300.fc23.x86_64.img --args="ro root=/dev/sda3"

Which resulted in:

# cat /etc/extlinux.conf 
label 4.4.6
 kernel /vmlinuz-4.4.6-300.fc23.x86_64
 initrd /initramfs-4.4.6-300.fc23.x86_64.img
 append ro root=/dev/sda3

I added following lines to the file manually:

default 4.4.6
ui menu.c32
timeout 50

After that I rebooted and the virtual machine was still using grub2 to load the kernel.

To write syslinux to the MBR following additional command was required:
dd if=/usr/share/syslinux/mbr.bin of=/dev/sda bs=440 count=1. I was a bit nervous rebooting the system after overwriting the MBR, but it rebooted successfully. The configuration file was also correctly updated after I installed a new kernel via dnf. I also removed grub2 (dnf remove grub2*) and was able to successfully reboot into the new kernel without grub2.

My son got a tiptoi. I was interested how it works and a little bit of googling lead me to this page. It provides a tool to create your own pages, books, adventures or puzzles. I gave it a try and this is the result.

a hand

result of 1st try with tttol

It does not look pretty and I could not print it in color, but the b/w version works. You can see the dotty area on each finger and on the i/o and play button. They contain the code that is read by the tiptoi pen. The example ha two modes. Mode one will just say the name of the finger when you touch it. Mode two can be activated by touching the play button on the lower right. If you touch the fingers in order starting with the thump it’ll tell the German poem “Das ist der Daumen …” or complain if the oder is not correct.

Find here the code:

product-id: 42
comment: das_ist_der_daumen
init: $spiel:=0
welcome: hallo
language: de
scripts:
 dau:
 - $spiel == 0? P(daumen)
 - $spiel == 1? $pos == 0? P(vdaumen) $pos := 1
 - $spiel == 1? $pos != 0? P(vnochmal,vanderer,vsicher,vhmmm)
 zei:
 - $spiel == 0? P(zeige)
 - $spiel == 1? $pos == 1? P(vzeige) $pos := 2
 - $spiel == 1? $pos != 1? P(vnochmal,vanderer,vsicher,vhmmm)
 mit:
 - $spiel == 0? P(mittel)
 - $spiel == 1? $pos == 2? P(vmittel) $pos := 3
 - $spiel == 1? $pos != 2? P(vnochmal,vanderer,vsicher,vhmmm)
 ring:
 - $spiel == 0? P(ring)
 - $spiel == 1? $pos == 3? P(vring) $pos := 4
 - $spiel == 1? $pos != 4? P(vnochmal,vanderer,vsicher,vhmmm)
 kle:
 - $spiel == 0? P(klein)
 - $spiel == 1? $pos == 4? P(vklein) $pos := 0
 - $spiel == 1? $pos != 4? P(vnochmal,vanderer,vsicher,vhmmm)
 spiel:
 - $spiel == 0? P(spiel_start) $spiel:=1 $pos := 0
 - $spiel == 1? P(spiel_end) $spiel:=0 $pos := 0
speak:
 hallo: "Hallo!"
 daumen: "Daumen" 
 zeige: "Zeigefinger" 
 mittel: "Mittelfinger" 
 ring: "Ringfinger" 
 klein: "kleiner Finger" 
 spiel_start: "Das Spiel wird jetzt gestartet. Beginne mit dem Daumen!"
 spiel_end: "Das Spiel wird jetzt beendet"
 vdaumen: "Das ist der Daumen!" 
 vzeige: "Der schüttelt die Pflaumen!" 
 vmittel: "der liest sie auf!" 
 vring: "der trägt sie nach Haus!" 
 vklein: "und der isst sie alle alle auf!" 
 vnochmal: "Versuchs nochmal!"
 vanderer: "Versuch einen anderen Finger!"
 vsicher: "Sicher?"
 vhmmm: "Hmmmm!"

As mentioned by Alex the link was down. Two things happened:

  1. The raspberry pi was not running anymore.
  2. The Internet connection was down.

For the second problem I don’t have a solution yet. For the not running raspberry pi there might be one:

The internal watchdog of the raspberry pi. It can be activated by loading the module, making sure it gets reloaded after a restart and installing the triggering software.

$ sudo modprobe bcm2708_wdog
$ echo "bcm2708_wdog" | sudo tee -a /etc/modules
$ sudo apt-get install watchdog

Configuration happens in the file

/etc/watchdog.conf

by uncommenting the following lines:

watchdog-device        = /dev/watchdog
max-load-1             = 24

This is a very basic configuration and it will restart the raspberry pi in case the load is above 24 for a 1 minute interval.

Activation of the demon can be done like this:

$ sudo service watchdog start

Specific in my case is the additional option to check whether the file, that was not working as mentioned above, is written to on a regular basis. This can be achieved by adding the following lines in the configuration:

file = /data/solar/solar.touch.start
change = 300
file = /data/solar/solar.touch.end
change = 600

Each “file” entry specifies a file that will be checked by the watchdog whether it’s been touched and the “change” entry specifies the time that the file can stay untouched before the watchdog will not be triggered any more and by that lead to a system reset. The first file is touched at the start of the script, the second one at the end. So in case the script for updating the yield data is not called any more the system will be reset after 5 minutes. If the script is started, but does not finish properly it’ll be reset after 10 minutes.

Time will tell how reliable the watchdog is.

After a long break I’ve started logging the PVIs in my father’s house again. The main reason for reactivating the scripts was that the two PVIs have shown different yield numbers at the end of the day. Further investigation has shown that the internal clock of one of the PVIs was wrong, so at around noon the yield counter was reset, which of course led to different results. Anyway the graphs are online now. Currently the graphs are generated using google charts. Hints for an alternative are welcome.

I’ve taken some pictures and short clip

wild animal

click on image for gallery

of the parrots living in the tree in front of my house.

After not even switching my IGEL for a very long time I finally got it running using thinstation and the service tsomatic to build the files instead of doing it on my own.  Unfortunately it takes longer to start and only run ssh than the desktop PC I own. Initially the idea was to have a machine that runs directly after switching on.  But it’s running and not used only as a display support any more.

The latest MirrorManager release (0.6.1) which is active since 2015-12-17 in Fedora’s infrastructure has a few additional features which provide insights into the mirror network usage.

The first is called statistics. It gives a daily overview what clients are requesting. It analysis the metalink and mirrorlist accesses and draws diagrams. Each time the local yum or dnf metadata has expired a new mirrorlist/metalink is requested which contains the ‘best’ mirrors for the client currently requesting the data. The current MirrorManager statistics implementation tries to display how often the different repositories are requested from which country for the available architectures:

In addition to the statistics where the clients are coming from and which files they are interested in the old code to draw a map of the location of all mirror servers has been re-enabled: maps

Another new visualization tries to track the propagation. The time the existing mirrors need to carry the latest bits. A script connects to all enabled mirrors and checks which repomd.xml file is currently available on the mirror. This is done for the development branch and all active branches. The script displays how many mirrors have the current repomd.xml file or if the mirror still has the  repomd.xml file from the previous push (or the push before) or if the file is even older: Propagation.

Another relevant change in Fedora’s MirrorManager is that it is no longer possible to enter FTP URLs. This is the first step to remove FTP based URLs  as FTP based mirrors are often, depending on the network topology, difficult to connect to, other protocols (HTTP, RSYNC) are better suited and more mirror server are not providing FTP anyway.

For some reason the support for init.d and thereby userinit.d has been removed from CyanogenMod starting with CM12. Unfortunately it is not easy to re-activate the functionality, even more so if you want the change to survive future CM updates.

So I decided to create a trivial app that will simply execute run-parts on the /data/local/userinit.d directory when the phone completes booting to get the good old userinit.d back. To clone the git repository run:

git clone https://lisas.de/~alex/runuserinit.git

Find more details on the repository contents here.

After installation you will have to start RunUserinit once and hit the button.  When asked whether RunUserinit should be allowed to use root privileges accept that and make the setting permanent. Finally sshd will run automatically again, whenever my phone requires a reboot…