11. June 2019

How to start D-Bus in Docker container

Many Linux applications require D-Bus which is not running by default in Docker containers.

When you attempt to start the application you might get the following error:

D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

First of all you need to generate missing machine-id by command:

dbus-uuidgen > /var/lib/dbus/machine-id

The application will be able to start even when the daemon is not running.

To start the D-Bus daemon inside the container you need to run following command on Ubuntu, Centos 7, Centos 8:

mkdir -p /var/run/dbus
dbus-daemon --config-file=/usr/share/dbus-1/system.conf --print-address

Command on Centos 6:

dbus-daemon --config-file=/etc/dbus-1/system.conf --print-address

Now the daemon is running and your application should be able to start. The output should look like this:

unix:path=/var/run/dbus/system_bus_socket,guid=9cfabcc6f66027251e092e955d09e707

28. July 2018

Failed to install Feature update of Windows 10, version 1803 on machine with Linux dual boot

I was chasing a very strange bug for a long time: Windows 10 was not able to install any feature update.

Update history in Windows contained just a message:

Feature update to Windows 10, version 1803
Failed to install on ‎2018-‎05-‎24 - 0xc1900101

To keep the long story short: I was starting Windows by the incorrect bootloader.

Grub from Linux Mint auto-discovered two Windows partitions /dev/sda1 and /dev/sda2. The first partition was just a small partition with bootloader from the previous installation of Windows. When booted by “chainloader +1” the boot automatically kicked in and started Windows stored on the second partition. Unfortunately it had an impact on updates and shutdown of the computer.

The correction was quite simple. Just start Windows from the second partition.

I rebooted the computer from sda2 partition and then I started the new installation of Windows 10, version 1803 update using Windows 10 Upgrade tool.

This correction also fixed another strange bug, that I was not able to shutdown Windows. When I selected “shutdown”, Windows respawned in a few seconds back into login screen. Again the problem was that old bootloader from the first partition kicked in, after the shutdown of Windows and resumed it.

Big thanks to Max Green for pointing out that the problem might be caused by invoking incorrect bootloader.