Some time ago I have written a post about, how to setup Windows 10 to wake it up remotely via network using magic packet. The question that remained unanswered is: how to actually send this packet to the PC to trigger it running.

In the first example I will use Raspberry Pi with Rasbpian Stretch Lite installed:

1) First make sure a tool etherwake is available. If not, this could be fixed with following command, otherwise skip this step:

sudo apt-get install etherwake

2) Then simply invoke it with proper arguments:

sudo etherwake –i <ethernet-interface-name> <PC MAC-address>

Some explanations:

Yes, it will ask you for a password, each time you try to call it. Also MAC address should be specified in format “XX:XX:XX:XX:XX:XX”. That was the easier part.

The harder part is that etherwake by default tries to use eth0 as the network interface, where to send the magic packet. Raspberry has a feature called “Predictable network interface names” enabled by default (since August 2017 I think; was even in Jessie edition, but was disabled by default). With a big probability the name of the interface will be different than eth0 (something like enx?? or wlx?? depending if using LAN or WiFi and ?? should be replaced with Raspberry’s own MAC address).

To list existing network interfaces type this command:

ip link show

Then grab the proper name, which is not a loopback. Or use raspi-config (via command “sudo raspi-config”) and navigate to “2: Network Options” and disable predictable network interface names, so it should go back to using eth0 and wlan0 names.

In the second example I wish to show, how to achieve the same effect on Synology NAS station.

If your DSM is really old, you could use the optional package manager named ipkg. Though this manager make sure wakelan utility is installed. And waking up a PC is just a matter of issuing following command in the console:

export PATH=$PATH:/volume1/@optware/bin/

wakelan –m <PC MAC-address>

MAC this time is in format: “XXYYZZXXYYZZ”.

On the other hand, if you don’t want to play with custom package managers and have a decent DSM 6.x on-board, one could use the build-in synonet utility (as also described here). Then it’s just a matter of calling it this way:

sudo synonet --wake XX:XX:XX:XX:XX:XX eth0

Executable is located at: /usr/syno/sbin/synonet

And that’s all. Have fun!


Recently I described, how to keep in sync with GitLab latest releases on the Raspberry Pi. And of course it lead me to a problem after unsuccessful update to version 8.17-rc3. This release has the PostgreSQL 9.6.2 embedded and apparently everything got broken in the middle of the upgrade process. After all my tries to revert to previous GitLab version, lots of time wasted (yes, each call to apt-get upgrade or install specified GitLab version was taking several hours!), I still stayed with totally unresponsive instance.

Then again I came back to basics.

  1. I rebooted the device
    sudo shutdown –r now
  2. Installed latest GitLab-CE
    sudo apt-get upgrade
  3. Asked it to revert PostgreSQL to previous version
    sudo gitlab-ctl revert-pg-upgrade
  4. At this stage, it was showing some strange errors about inability to connect to psql service via TCP/IP, that was pretty strange.
    So I checked the status.
    sudo gitlab-ctl status

    run: gitlab-workhorse: (pid 3099) 7362s; run: log: (pid 604) 1487541047s
    run: logrotate: (pid 11405) 160s; run: log: (pid 602) 1487541047s
    run: nginx: (pid 1917) 7686s; run: log: (pid 608) 1487541047s
    down: postgresql: 1s
    run: redis: (pid 1930) 7685s; run: log: (pid 603) 1487541047s
    run: sidekiq: (pid 3079) 7364s; run: log: (pid 607) 1487541047s
    run: unicorn: (pid 3257) 7282s; run: log: (pid 606) 1487541047s
  5. And then logs!
    sudo gitlab-ctl tail postgresql
  6. And it was continuously repeating an error, while parsing line 210 of the configuration file, what was all the time stopping the service.
    sudo vi /var/opt/gitlab/postgresql/data/postgresql.con
  7. Since it was about replication, I commented it out and service started normally.
  8. Then manually upgraded PostgreSQL
    sudo gitlab-ctl pg-upgrade
  9. This time all went OK.


I recently noticed that my GitLab installed on Raspberry Pi (running Jessy) stopped updating and stick to version 8.7.9, however the latest one as of today is 8.16.4.

Normally apt-get updateand apt-get upgradeshould do the trick. But it turned out there was a change in the build system and newer packages don’t get uploaded into ‘raspbian’ version of repository. For details - take a look on issue #1303. Although quick patch is following and short:


Edit configuration file located at: /etc/apt/sources.list.d/gitlab_raspberry-pi2.list

And redirect the repository path from ‘raspbian/’ to ‘debian/’.



EDIT: 2017-03-12:

The broken repository for 'raspbian' was fixed and this trick is no more required to install latest version of GitLab.


Yet another day I tried to play a video from an SMB share using OSMC. Must say so – this player is just amazing and works great on Raspberry Pi 2 (although on Pi 1 whole stack was far too slow for HD content). So what could go wrong here?

I am a bit paranoid about sharing and access rights. That’s why I setup that share with a dedicated user on a server and guarded with a strong password. The user could only list folders and read files, so even if the password gets somehow compromised, it shouldn’t allow to cause any harm on server. But then I couldn’t find the way of mounting such a share though GUI of the OSMC player. After several tries I wanted to give up until I found the way of updating configuration manually.

PC with SSH client is required for that purpose. Let’s connect to the device (default user and password are ‘osmc’, what I recommend changing just after player installation). Then all settings about mapped drives are stored in an XML file at “/home/osmc/.kodi/userdata/sources.xml”. Simply edit this file adding following snippet at respective place. Of course replace the ‘user’, ‘password’ and server IP with the real values from your environment.

        <default pathversion="1"></default>
            <path pathversion="1">smb://user:password@</path>

Save. Reboot. Enjoy!


Few days ago I ordered Raspberry Pi 2 and unboxed it just today. After a lecture of few videos on Channel9 about Microsoft //Build/ 2015 I was very excited and wanted to test the latest Windows 10 for IoT myself. Then I simply hit obstacle after obstacle and wasted more than 10 hours of my life to simply get the image written on microSD card. That was a real nightmare, but maybe because I am not a typical Windows user. Please treat the rest of this post as a warning and also as a guide to make the whole process straight to the point.

Before I start painting everything with my grief, compare, how easy it is to use Raspbian. 4 steps:

1) download an OS image (without signing anything)

2) download a burning tool, that doesn’t need installation and works on any version of Windows

3) burn the image on an microSD card using your favorite card-reader

4) put the card into Raspberry and and power it on!

10 minutes and you are ready to write your programs.

Now let’s install Windows 10 IoT and see, if the Universal Windows Platform is really as awesome as they say. There is a step-by-step guide on the IoT project website. I also found a nice post on Scott Hanselman’s blog, but they both seemed to skip a few quite important details. Let me bring them to light.

1) Yes, here it’s also required to download the image (.ffu), but to get it, you need to sign into Microsoft beta-testers program. The same time, you claim not to reveal any bugs etc., found during the usage of the software. OK, this approach I understand.

2) & 3) But what about the other actions? How to put the image on microSD card?

What you need:

1. Windows 10 Insider Preview- must be a physical Windows machine (not a VM).

Shocking, but true. You need to have a preview version of the desktop OS installed on physical hardware, to actually be able to burn image for Raspberry Pi 2. Confirmed, I tried to create it from a Hyper-V virtual machine and failed to do so. Hyper-V used to access host plugged-in USB card-reader can’t make it at enough low level to perform the image writing. Still I was forced to install 20GB OS to simply use a small command-line utility program that will prepare the microSD card. It really sounds ridiculously and the person, who had this idea at Microsoft should be promoted ;) Couldn’t the utility be ported back to Windows 8.1 and occupy 2MB?

Well, installation of Windows 10 (version 10074) and using it on Hyper-V at least gave me an idea, how the new OS will look and work like. It was fairly OK. However it setup my mind with a sentence – ‘do not install it yet on any of PCs that are used to make money!’. That eliminated my 3 quite new and powerful machines.

UPDATED: version 10130 is much stable and pleasant to work. Although I prefer to use it via Hyper-V (and remote desktop) than on a physical old hardware as described below, which is much slower than i7 with 32GB of RAM and SSD.

The one that left was a Pentium IV 4GHz Prescott from 2005 I suppose.  With Windows XP on-baord it was a nice testing machine. It turned out it can’t be easily upgraded to Windows 10 Preview as this is the last processor, which doesn’t support NX instruction set and causes 0x000000005D failure during installation. Thankfully I found this video explaining, how to overcome this issue. As a result I ended up with a machine with Hyper Threading disabled, enabled legacy USB support in BIOS, modified kernel, which required starting Windows in safe-mode after each reboot and had digital signatures integrity checks disabled. At least it had 2GB of RAM to start! Running on regular HDD was killing any performance the machine had, but I though I was so close the goal. Then I could simply format it as soon as the microSD card is flashed and forget.

So close is sometimes far enough. Execution of flashing:

dism.exe/Apply-Image /ImageFile:flash.ffu

(N is a drive number assigned to card reader)

finished with magic “error 1168”. Turned out external card readers are not supported! If I had a build-in one, like when using Surface Pro or other tablet, I wouldn’t have problem like that. Once again Internet helped me with this forum thread. Komarov (whoever he is) found the root cause and explained, how to edit another system library with hex editor.

You can patch x86 version of FfuProvider.dll with HEX editor.
File offset 0x7312, replace B8 90 04 07 80 with B8 00 00 00 00 (valid for 10074 and 10075)

Job done. Image written.

4) After longer fist boot, Raspberry Pi 2 is now able to run Windows 10 IoT. That’s just great.

I still believe Microsoft won’t leave it that way and will simplify the whole process and this was just hard-core for beta testers.

On the other hand – lesson learned – buy the cheapest Windows 8.1 tablet, which is most probably faster and better supported than 10-years old PC!