I had to perform this emergency procedure every now and then and I seem to reinvent the wheel every time so I reckoned it was time to document it.

This time, its a failing master drive in a simple home server - without a RAID. The SMART monitoring has not yet caught on but the self-tests fail and some files are read-only as writes to the drive fail. Also the logs are full with SATA errors like:

Apr 29 10:23:57 rivenscryr smartd[3621]: Device: /dev/sda, 18 Currently unreadable (pending) sectors

To save the installation and all the files, I want to clone or backup the entire root filesystem (which is ext3, but that is not relevant) to a new drive (formatted ext4) in another machine. The reason to do this between machines can be numerous: perhaps you are migrating a live machine or (in this case) perhaps you worry that the current drive may fail when you power-cycle the system when the replacement drive is installed.

Backup/Clone Over Network Recipe

1. Mount the root filesystem of the original machine on another location in order to have a clean copy:

   mkdir /mnt/rootfs && mount / /mnt/rootfs -o bind

   Check if it worked by listing the '/mnt/rootfs/' folder. Note that '/mnt/rootfs/proc' will be empty and 'dev' will be empty or very sparse.
2. Use netcat and tar on the receiving machine (my case: random system with Ubuntu on USB stick and new HDD plugged in) to receive and write the data.

   nc -l 7777 | tar -xz -C /mnt/targetdir

[li]Use tar and netcat on the original machine to stream-copy the root filesystem over the network. [color=red]Big fat warning:[/color] My cloning is done on an internal, trusted network. You **will be cloning using an unsecured stream** over this network.

tar -czp --atime-preserve --numeric-owner --xattrs --recursion /mnt/rootfs | nc remotehost 7777

Heres what all these options do:
[li]-c: Create a new archive [li]-z: Use GZip compression to speed up the transfer [li]-p: Preserve file permissions [li]--atime-preserve: Do not update the accessed timestamp [li]--numeric-owner: Copy using numeric ids only - usefull when cloning into a foreign system [li]--xattrs: Include ACL attributes and SElinux attributes [li]--recursion: Recurse down into sub-folders [li]--ignore-failed-read: Useful when a drive is heavily damaged and you only care to extract as much data as possible. Note: do not enable this by default as you might end up with an unusable clone if some files are missing. (Aka, this is a last resort option for non-functional clones)

If you have a Thomson TG787v modem, like we have from KPN Business in the Netherlands, you might want to add an PXE server to your network to quickly install computers without the hassle of running around with CDs or thumb drives.

I will not explain how to set up the PXE environment itself (which is in fact a TFTP service) but I will stick to the modification of the modem/router. This modification can NOT be done using the webbased configuration panel.

We will log in using telnet, create option templates for the DHCP server, install those option templates and finally add them to the active pool so they will actually be in use.

If you think thats rather a lot of work to install option 66 (TFTP server address) and option 67 (Bootfile name) into your modem, please complain to Thomson and insist they make it a) more intuitive; b) improve their documentation; c) implement these things in their webbased configuration; d) all of the above.

• Log in on the CLI using telnet at your router, port 23 and enter your credentials
  Note: with the unlocked versions, your login will be the username from the webbased configuration and no password. Try "Administrator".
• Install the new template for the PXE server address:
  dhcp server option tmpladd name=tftp_server_name optionid=66
• Install the new template for the PXE bootfile name:
  dhcp server option tmpladd name=bootfile optionid=67
• Instantiate the templates:
  dhcp server option instadd name=tftp_server_name tmplname=tftp_server_name value=(addr)192.168.1.2
dhcp server option instadd name=bootfile tmplname=bootfile value=(ascii)pxelinux.0
  Note: The file name can be configured to whatever you need.
• List all DHCP server pools: "dhcp server pool list"
• Optionally, add the option to the desired pool:
  dhcp server pool optadd name=LAN_private instname=tftp_server_name
dhcp server pool optadd name=LAN_private instname=bootfile

It seems that the template instantiation is added by default to the "LAN_private" pool.

For some reason, my attempts to use GPT with Windows 7 ran aground and I ended up with a working Master Boot Record (MBR) and an empty GPT. While Windows 7 was quite happy with this, the Ubuntu installer detected the GPT and attempts to use it - which effectively prevents me from installing it unless I wipe the entire hard drive for Ubuntu.
In this little article I will clear the GPT from the disk so only the MBR remains. This is an advanced technique which WILL destroy your partition layout and thus your data when it fails. Make very very sure you understand each step and have backups.
Start by making a backup of your MBR, which is 512 bytes long at the start of the disk:

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

I made a backup of the MBR and the GPT as well, just in case (GPT is 512 bytes for the header followed by 16kB of content, total with MBR is 17kB):

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

The GPT is present at the start and end of the disk. Lets start by erasing the GPT from the start:

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

Now find the end of your disk, use 'fdisk /dev/sda' and note the number of bytes on the disk. In my case it is: 240,057,409,536 bytes, since I want to use kilobytes with dd, lets convert it to kB: 234,431,064 kB. We need to erase the last 16.5 kB, but 16kB will suffice (as the header is in the last 512 bytes).
So substract 16 from the drive size to generate the GPT offset for the end of the disk and zero-fill it to the end:

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

All done! Now fdisk will no longer complain the drive has a GPT table and the Ubuntu installer will only find the MBR and happily install using that.

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!