0 Comments

At first glance, it seemed to me to be a really easy task. Install QEMU for Windows, download latest Raspbian and run! Unfortunately after whole evening of tries I still fail to have it usable anyhow. Maybe it’s not totally not running, but still it’s pretty useless in terms of any further development of application without a device. Simply, at current state (as of 2018-02-18) of QEMU, it doesn’t support emulation of the USB controller, and since the whole network relays on it, there are huge connectivity issues (no network interface at all, so no SSH, no tools installation, no file transfers neither).

Just for reference, here is the tutorial I followed, not to be very bold, that I have discovered everything myself. I appreciate the work already done by QEMU team and others involved. I only hope they can emulate BCM2836’s USB anytime soon…

Probably since the spec of the USB controller is not publicly available, it makes the whole thing harder and that’s why the emulation not yet available. Although I found some article describing try of porting the USB driver itself into the Xinu OS running on Raspberry Pi. Maybe this could be used somehow to create the opposite.


OK. That’s a NO GO for the moment. Is there any other solution?


Well, yes, there is. After a while, it turned out that there are plenty of people (here, here or here) doing some heresy, but at the end of the day, it works. Instead of running Raspbian on emulator of the Raspberry Pi hardware, they use the ARM Versatile/PB board, which works somehow as expected. Among the best, it has network working!

This is pretty amazing, but also has some own quirks. First – a set of kernel patches must be applied to make it boot. Secondly it can handle only up to 256 MB of RAM (qemu exits with an error, when more is specified). Should be enough to start the device, but it’s quite low for some serious scenarios of audio/video processing. Thankfully Dhruv Vyas prepared required QEMU binaries in this open-sourced project (well, took over the work after xecdesign.com went down few years ago and is updating it along with all recent Raspbian releases). Great job!

So after downloading updated kernel, it’s just a matter of issuing single long command (Windows 10 shell):

"C:\Program Files\qemu\qemu-system-arm.exe" -m 256 -M versatilepb -cpu arm1176 -serial stdio -no-reboot -kernel kernel-qemu-4.14.79-stretch -dtb versatile-pb.dtb -net nic -net user -append "root=/dev/sda2 panic=1" -drive format=raw,media=disk,index=0,file=D:\Raspi\2018-11-13-raspbian-stretch-lite.img

Update paths accordingly to your installation. Then QEMU will start fine.


PS.

One final note. It would be recommended at the very beginning to enlarge the SD card image to get some extra space for new programs to be installed.

This could be done with following command:

"C:\Program Files\qemu\qemu-img.exe" resize D:\Raspi\2018-11-13-raspbian-stretch-lite.img +2G


That's all. Have fun!

0 Comments

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!

0 Comments

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.

0 Comments

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/’.

 

Done!


EDIT: 2017-03-12:

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

0 Comments

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.

<sources>
    ...
    <video>
        <default pathversion="1"></default>
        <source>
            <name>Prime</name>
            <path pathversion="1">smb://user:password@10.0.0.111/video/</path>
        </source>
    </video>
    ...
</sources>

Save. Reboot. Enjoy!