cyberwizzard.nl

sudo dd if=/dev/sda of=disk_mbr.raw bs=512 count=1

sudo dd if=/dev/sda of=disk_mbr_gpt.raw bs=1024 count=17

sudo dd if=/dev/zero of=/dev/sda bs=512 seek=1 count=33

sudo dd if=/dev/zero of=/dev/sda seek=234431048 bs=1024 count=17

Since it took me hours to find this answer, I decided to put it up clear and simple: this is how you 'force' your stock HTC Hero to check for updates.

First off, this is for the original HTC Hero. So not the Sprint or CDMA version, but the GSM version (with the chin). Most sites tell you to use the "Check for updates" option. The original HTC Hero firmware does not have this option.

Instead, you need to install the first (of three) updates to get the updater. The original update mechanism checks every two weeks for an update. If you need it to check right away, you can move the clock 2 weeks forward or use enter this number: *#*#682#*#*. If it worked, the number will disappear from the dialer and almost instantly a popup will tell you that an update is available.

After this update, force the phone to check for future updates by doing:

1. From the Home screen, press MENU, and then tap Settings.
2. Scroll down the screen, and then tap About phone > System software updates.
3. On the System software updates screen, tap Check now.

The Gentoo Wiki article about KVM uses the less flexible networking setup with dedicated TAP devices like 'tap0'. While this setup works fine, other distributions use the bridge device in a different way. By creating a virtual bridge and forcing the host system to connect through this bridge, virtual machines can simply connect to the bridge device and 'plug in'. No need to manually create TAP devices. In this guide we will set up host and guest networking using the virtual bridge device and DHCP for wired ethernet.

For this to work, you will need most of the tools from the wiki article as well as a couple more (I like the management GUI from virt-manager to manage VMs without a text console). Install the following tools:

1. app-emulation/qemu-kvm - QEMU + Kernel-based Virtual Machine userland tools
2. net-misc/bridge-utils - Virtual network bridging
3. app-emulation/virt-manager - libvirt management GUI
4. app-emulation/libvirt - Toolkit to manipulate virtual machines, supporting virtualisation frameworks like KVM and Xen

Install all the tools and modify the kernel to support the bridge devices. Note that tunnel support is omitted (unlike in the original wiki article).

 [ * ] Virtualization --->
       --- Virtualization
           <m> Kernel-based Virtual Machine (KVM) support
           < > KVM for Intel processors support
           < > KVM for AMD processors support
 Networking support --->
       Networking options --->
           <*> 802.1d Ethernet Bridging
           <*> 802.1Q VLAN Support

Build the kernel, the modules and install both. Do not forget to reboot.

Next up, lets configure the network on the host machine. Disable NetworkManager as it will not understand the bridge device and break networking altogether in an attempt to activate things they usually are.

We will connect the network as shown below. The interface 'eth0' is now a passthrough for the virtual network bridge - note that the eth0 device has no IP address. The new 'br0' device is a new bridge. This is the new networking interface for the host PC - it gets an IP address and is the designated end point for communication. Other virtual NICs connect to this bridge.

             HOST
       +---------------+
LAN ---+--- eth0       |
       |      ^        |        KVM GUEST1
       |      |        |   +--------------+
       |    +-----+    |   |              |
       |    |vnet0+----+---+---- nic0     |
       |    |vnet1+----+-+ |192.168.100.2 |      KVM GUEST2
       |    +-----+    | | +--------------+   +--------------+
       |     br0       | |                    |              |
       |192.168.100.1  | +--------------------+---- nic0     |
       +---------------+                      |192.168.100.3 |
                                              +--------------+

In order to automatically configure the network, edit '/etc/conf.d/net' and insert the following:

# Disable all configuration on eth0
config_eth0=("null")
# Use eth0 to connect the virtual bridge
bridge_br0="eth0"
# Statically configure br0
config_br0=("192.168.100.1 netmask 255.255.255.0")
routes_br0=("default via 192.168.100.254")
dns_servers_br0="192.168.100.254"
# Uncomment the next line and comment the lines above to use DHCP
#config_br0=("dhcp")

Now we need to symlink '/etc/init.d/net.lo' to '/etc/init.d/net.br0'. We can now stop 'net.eth0' if you still had it running and start 'br0' instead. Note that the Gentoo networking scripts create the bridge interface 'br0' and bring everything up (including eth0, but without assigning an IP).

The Gentoo scripts do this under water (in case you want to manually configure things):

# Create the br0 device and connect eth0 to it
brctl addbr br0
brctl addif br0 eth0

If you want to make this networking setup permanent, remember to remove 'eth0' from the default runlevel and add 'br0' instead.

Now start the service 'libvirt' and run 'virt-manager' to start managing Virtual Machines. If everything worked as planned, creating new VMs will automatically (read: libvirt creates these) result in new virtual NICs for the virtual network. Good luck!

While the title may sound a tad cryptic, that matched my first impression about the new infrared remote subsystem used in Ubuntu 10.10 and kernel 2.6.36+ based distributions. In Linux 2.6.36, a new sub-system is introduced for remote controls. This subsystem is a partial replacement for lirc as it features complete IR drivers for numerous devices.

In reality, the glass is only half full as some IR receivers (and transmitters) deal with raw data. Writing universal drivers for such devices can be bothersome or even impossible, for example when dealing with universal receivers. As such, LIRC is not completely written off as it can be used to do userspace IR processing as it used to. The exact details are unknown to me as I have an SoundGraph iMon receiver (device ID 0038 - LCD), which does not deliver raw sensory input but rather complete scancodes.

When I upgraded from Ubuntu 10.04 running lirc 0.8.6 to Ubuntu 10.10 and lirc 0.8.7, the entire IR subsystem died on me. To my surprise, while the remote was dead, the LCD screen was working fine. Further inspection showed that the 'lirc_imon' driver was not loaded at all.

With the move to the new input layer driver for supported IR devices in the kernel, the new 'imon' driver (version 0.8 at the time of writing) no longer provides a 'lirc0' device. As such, lircd will fail when attempting to claim it and loading 'lirc_imon' (provided you still have it) will not work as the device is already claimed by the 'imon' driver.

The fastest way to get up and running again is as follows. The 'imon' receiver will now be a HID input device. I got the impression it would send keystrokes to a graphical application but I didn't get that working. Instead, we will use 'lircd' again using a special driver called 'devinput'. This driver reads the key strokes from the input layer device and converts them into LIRC events. All your LIRC capable programs will then use lirc like they used to - we only need to use the new button names.

To find the iMon receiver in the list of input devices, lets create a udev rule to symlink to the device. This way we will not have to rely on obscure device names like 'input1'. Make sure the device name matches whatever hardware you have. I inserted this rule in a file called '/etc/udev/rules.d/99-imon.rules':

KERNEL=="event*", SYSFS{name}=="iMON Remote (15c2:0038)", NAME="input/%k", SYMLINK="input/imon_remote", MODE="0666"

Lets begin by stopping lirc if you still have it running. Next, reconfigure LIRC to use the devinput driver - when it asks which device you have DOT NOT SELECT THE SOUNDGRAPH IMON but 'Linux input layer (/dev/input/eventX)'. In the next screen select 'None' as you probably do not use a transmitter.

/etc/init.d/lirc stop
sudo dpkg-reconfigure lirc
> Linux input layer (/dev/input/eventX) 			 		
> None
/etc/init.d/lirc start

In case you are not using Ubuntu linux, I will explain the key parts of the LIRC configuration. The '/etc/lirc/lircd.conf' file now has this part in it:

#Configuration for the Linux input layer (/dev/input/eventX) remote:
include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput"

The 'lirc.conf.devinput' file is a standard (generated) file with key codes as provided with LIRC. There is no need to manually set up a file with button scan codes as the new ir-core kernel subsystem will generate standard codes.

The file called '/etc/lirc/hardware.conf' has something like this in it:

REMOTE="Linux input layer (/dev/input/eventX)"
REMOTE_MODULES=""
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="/dev/input/imon_remote"
REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput"
REMOTE_LIRCD_ARGS=""

All that remains is to use the new buttons in your LIRC capable program. For example, this is a part of my configuration of XBMC (Lircmap.xml) for use with the SoundGraph iMon receiver:

<lircmap>
        <remote device="devinput">
                <hash>KEY_EJECTCD</hash>
                <play>KEY_PLAY</play>
                <pause>KEY_PAUSE</pause>
                <stop>KEY_STOP</stop>
                <forward>KEY_FASTFORWARD</forward>
                <reverse>KEY_REWIND</reverse>
                <skipplus>KEY_NEXT</skipplus>
                <skipminus>KEY_PREVIOUS</skipminus>
                <record>KEY_RECORD</record>...

I've found numerous tutorials to set up KVM with CentOS 5.5. Some refer to the Red Hat guides, which are useless in my opinion if you are not using KVM in a large server park, others come up with scripts to set up networking.

I kept searching and trying configurations until I finally found one that works. Note that among problems you might encounter is the one that plagued me for months: CentOS is attempting to bring up the virtual device for LAN access on the host before bringing up the physical interface, this fails and prevents all networking and dependencies from starting properly.

To set up the bridge devices for KVM and the host (something which is done only once to 'wire' your virtual network instide the bridge) look here. Most of the guide is still relevant even if they refer to the Red Hat documentation (which is about Red Hats cloud virtualisation platform and not a single server running KVM).

Use a configuration like this for proper KVM networking under CentOS, Red Hat and probably even Fedora.

1. Edit /etc/sysconfig/network-scripts/ifcfg-eth0 to contain something like this:

# /etc/sysconfig/network-scripts/ifcfg-eth0 - the physical NIC which will not be used directly
DEVICE=eth0
TYPE=Ethernet
HWADDR=00:23:B3:16:3F:00
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no

The "NM_CONTROLLED" bit seems to originate from Fedora 12/13, CentOS might ignore it altogether so you could leave it out.

2. Edit /etc/sysconfig/network-scripts/ifcfg-br0 to restore network access for your host machine:

# /etc/sysconfig/network-scripts/ifcfg-br0 - Bridged network access for host
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
NM_CONTROLLED=no

The crucial parts in this configuration is that eth0 is started on boot and is assigned a bridge device: 'br0'. The 'br0' device is marked as a bridge device which completes the dependencies between them. So make sure if you deviate from the examples you leave the types and 'bridge=br0' in tact.