Formosa21 eHome Infrared Transceiver (MCE) and OpenELEC 6: buttons not working

Since the upgrade to OpenELEC 6.0, I think there were some changes in the kernel regarding usbhid that causes this Windows Media Remoteclone  to behave strangely sometimes on boot (guessing due to race condition) where some keys (especially OK) do not work on the remote. The transceiver portion of the device identifies itself as:

lsusb
Bus 001 Device 004: ID 147a:e03a Formosa Industrial Computing, Inc. eHome Infrared Receiver
Kernel buffer (dmesg)
New USB device found, idVendor=147a, idProduct=e03a
New USB device strings: Mfr=1, Product=2, SerialNumber=3
Product: eHome Infrared Transceiver
Manufacturer: Formosa21

You may see the following error messages in your kernel buffer when buttons aren't working:

hid-generic 0003:147A:E03A.0001: timeout initializing reports
mceusb  Error: urb status = -71

To resolve this error, mount /flash partition as read/write and added the following string to /flash/cmdline.txt:

usbhid.quirks=0x147A:0xE03A:0x20000000

This activates the HID_QUIRK_NO_INIT_REPORTS (0x20000000) quirk which resolves the timeout error and allows lirc to bind properly to the USB device.

radicale behind Apache reverse proxy with Dovecot authentication

  • Requires mod_authn_dovecot for Apache 2.2 and 2.4, which can authenticate against Dovecot using email address or just username (depending on Dovecot configuration)
  • Requires auth_basic, authn_alias, authn_default, authz_default, authz_host and authz_user to be enabled for authentication.
  • For the reverse proxy: proxy, and proxy_http must be enabled in Apache.
  • Optional AppArmor changehat support provided (and accompanied AppArmor profiles for the web component in Apache and radicale itself.)

Apache configuration (/etc/apache2/conf.d/radicale.conf or equivalent)

ProxyPassMatch ((\.(ics|vcf))|((\.well-known\/)?(cal|card)dav)/)$ http://localhost:5232
<LocationMatch ((\.(ics|vcf))|((\.well-known\/)?(cal|card)dav)/)$>
   AuthType basic
   AuthName "Dovecot Authentication"
   AuthBasicProvider dovecot
   AuthDovecotAuthSocket /var/run/dovecot/auth-client
   AuthDovecotTimeout 5
   AuthDovecotAuthoritative On
   Require valid-user

   RewriteEngine On
   RewriteCond %{REMOTE_USER}%{REQUEST_URI} !^([^/]+/)\1
   RewriteCond %{REQUEST_URI} !^/.well-known/.+
   RewriteRule .* - [Forbidden]
   <IfModule security2_module>
      SecRuleEngine On
   </IfModule>
   <IfModule apparmor_module>
     AAHatName radicale
   </IfModule>
</LocationMatch>

Radicale configuration, relevant sections only (/etc/radicale/config)

[server]
hosts = 127.0.0.1:5232

[auth]
type = remote_user

[rights]
type = None

[storage]
filesystem_folder = /var/lib/radicale/collections

/etc/apparmor.d/usr.bin.radicale

/usr/bin/radicale {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/python>



  /bin/dash rix,
  /etc/radicale/* r,
  /proc/*/mounts r,
  /run/radicale/* w,
  /sbin/ldconfig rix,
  /sbin/ldconfig.real rix,
  /usr/bin/python2.7 ix,
  /usr/bin/radicale r,
  /var/lib/radicale/** rw,
  /var/log/radicale/* w,

}

/etc/apparmor.d/apache2/radicale

^radicale {
  #include <abstractions/apache2-common>
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # for log writing (could be abstracted)
  /var/log/apache2/*.log w,


}

Boot LVM on mdraid (5, and others) on Ubuntu 14.04 on newer kernels

If you build a LVM mdraid5 on Ubuntu 14.04, and update the kernel you may be dropped into initramfs on reboot and be forced to manually activate the logical volumes on the volume group. This is due to a missing/incomplete udev rule for LVM which should be incorporated into initramfs.

/etc/udev/rules.d/85-lvm2.rules

# This file causes block devices with LVM signatures to be automatically
# added to their volume group.
# See udev(8) for syntax

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_TYPE}=="disk", \
        RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"

Once you have added this udev rule, you should update initramfs on your system:

update-initramfs -u -k all

If you need to activate the logical volume groups from initramfs, execute the following commands to boot the system:

lvm vgscan
lvm vgchange -a y
exit

QEMU agent for graceful shutdown of Windows guests under libvirt/qemu-kvm

libvirt sending an ACPI shutdown doesn't always prompt Windows guests to shutdown. That's why there is a QEMU guest agent (which is also handy for freezing/thawing guest file systems.) Installing QEMU guest agent will also cause libvirt to block on shutdown commands until the guest has terminated.

libvirt XML definition required

<channel type='unix'>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>

You may also have to create /var/lib/libvirt/qemu/channel/target on the KVM host.

mkdir -p /var/lib/libvirt/qemu/channel/target
chown -R libvirt-qemu:kvm /var/lib/libvirt/qemu/channel/target

virtio-win drivers distributed by the Fedora Project contain the guest-agent and required virtioserial drivers for communication between guest and host and can be downloaded as an RPM package called virtio-win.

Once you have the RPM, you can either install it or convert it to a Debian package using alien. The ISO will be installed to /usr/share/virtio-win/virtio-win.iso and can be mounted in the guest.

virsh attach-disk GuestName /usr/share/virtio-win/virtio-win.iso hdc –type cdrom –mode readonly

Once you have restarted the guest with the XML definition changes, you can complete the following steps

  • Install virtioserial driver for PCI Simple Communication Controller under Device Manager, in the vioserial folder
  • Install the guest-agent located under the guest-agent folder for your architecture in the virtio-win ISO

libvirt 1.2.9 KVM qemu AppArmor support

If you want to use AppArmor support in libvirt 1.2.9, you will need to copy the following files over from the source:

cp libvirt-1.2.9/examples/apparmor/libvirt-lxc /etc/apparmor.d/abstractions
cp libvirt-1.2.9/examples/apparmor/TEMPLATE.lxc /etc/apparmor.d/libvirt
cp libvirt-1.2.9/examples/apparmor/TEMPLATE.qemu /etc/apparmor.d/libvirt
ln -s /etc/apparmor.d/libvirt/TEMPLATE.qemu /etc/apparmor.d/libvirt/TEMPLATE.kvm

This is due to the fact that libvirt looks for both TEMPLATE.lxc and TEMPLATE.qemu instead of just TEMPLATE to enable AppArmor support.

You may encounter the following error when trying to a KVM guest with AppArmor support enabled:

error: Failed to start domain test-domain
error: internal error: cannot load AppArmor profile 'libvirt-598505b5-1549-4164-97bd-d1d37fdd8995'

If you look at /var/log/libvirtd.log you may see the following error message:

2014-10-24 18:00:52.280+0000: 4468: error : virCommandWait:2533 : internal error: Child process (/usr/lib/libvirt/virt-aa-helper -p 0 -c -u libvirt-598505b5-1549-4164-97bd-d1d37fdd8995) unexpected exit status 1: virt-aa-helper: error: template does not exist
virt-aa-helper: error: could not create profile

2014-10-24 18:00:52.280+0000: 4468: error : AppArmorGenSecurityLabel:468 : internal error: cannot load AppArmor profile 'libvirt-598505b5-1549-4164-97bd-d1d37fdd8995'

This is due to the fact there is a bug in libvirt 1.2.9 which looks for /etc/apparmor.d/libvirt/TEMPLATE.kvm instead of /etc/apparmor.d/libvirt/TEMPLATE.qemu. This has been fixed via a patch which has not been integrated in a release upstream as of this post. You may symlink TEMPLATE.kvm to TEMPLATE.qemu to resolve this issue until it is resolved upstream.