Google Earth error in Fedora 17 x86_64

After installing google-earth-stable_current_x86_64.rpm, downloaded in 08.29.2012 from Google's official site, it didn't open and when trying to open it in the terminal, I received the following error:


[rafael@rafael ~]$ /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF interpreter: No such file or directory

[1]+  Exit 126                google-earth

To solve this, as root or with sudo, install redhat-lsb for x86_64 and x86 architectures with the following commands: yum install redhat-lsb.x86_64; yum install redhat-lsb.i686

How to export virtual machine configurations from QEMU-KVM

When exporting a virtual machine to use in another system or in a new operating system install, it's very helpful export its configurations. Yesterday I put to work two virtual machines from an old install of my box and I had one problem that caused me a headache: in their new profiles, both virtual machines received a new MAC address. This is obvious... but to discover that this was the problem I spent some time looking the configurations of both virtual machines. To solve this problem in the virtual machine that runs a Linux server, I commented the lines in /etc/udev/rules.d/70-persistent-net.rules because udev wasn't recognizing the MAC address of eth0 as configured in /etc/sysconfig/network-scripts/ifcfg-eth0 and it created a new ethernet device - eth1 - with the new MAC address (the one from the new profile). Then I updated /etc/sysconfig/network-scripts/ifcfg-eth0 with the new MAC address and rebooted the virtual machine. These three steps were sufficient.

But... how to export the configurations to a file to import them in another system or install? All the commands below need to be executed as root or with sudo.

[root@rafael vms]# virsh --connect qemu:///system dumpxml VM_NAME > VM_NAME.xml

If you don't know the name of the virtual machine you want, you can retrieve it with the virsh --connect qemu:///system list --all command.

Now you have the configurations file in XML format. To import and apply the configurations file to a virtual machine, use the virsh --connect qemu:///system define FILENAME.xml command.

YUM purge?

I was wondering if the yum remove command removes the configuration file(s) of a package or if YUM has a command like apt-get purge to remove it(them). After a little Googling I found that there is no such command like purge of the apt-get in YUM. Only using yum remove it's enough to remove a package and its configuration file(s).

You can retrieve the configuration file(s) of a package using the rpm -q --configfiles PACKAGE command:

/[root@rafael ~]# rpm -q --configfiles gparted
/etc/pam.d/gparted
/etc/security/console.apps/gparted

How to disable the DHCP server in a KVM environment - part 2

It seems that the trick to disable the DHCP server by editing the XML file isn't working anymore. I tried it yesterday in my Fedora 17 x86_64 box and it didn't worked. The solution I found was disable the default virtual network, create a new one and disable the DHCP server in the wizard (when you create a virtual network the wizard shows you an option to disable it).

How to disable the DHCP server in a KVM environment - part 1

When you setup a KVM environment, you soon will realize that there is no graphical option to disable the DHCP server that's started by default. However, it's very easy to disable it: you only need to comment three lines in /etc/libvirt/qemu/networks/default.xml. Remember that to edit this file you need to be logged as root or use the sudo command. You can edit it with a simple program, like vi, vim or nano. So, to disable the DHCP server, you need to comment (putting # in the beggining of the line) the two lines that begins with the keyword <dhcp>, the line that begin with the keyword <range and restart the libvirtd service (you can do this with the command systemctl restart libvirtd.service, /etc/init.d/libvirtd restart or /sbin/service libvirtd restart - depending of your distribution - as root or with sudo).

By editing /etc/libvirt/qemu/networks/default.xml, you are changing the configuration of the default virtual network, that can be visualized in the virt-manager GUI.

Guide for KVM in openSUSE 12.1

Surfing on the openSUSE's documentation I found this great guide for KVM in openSUSE 12.1: http://doc.opensuse.org/documentation/pdf/openSUSE/book.kvm_en.pdf.

It covers since the installation of KVM and related libraries to the management of virtual machines. It's great and very well done.

Good reading!

How to check media integrity in Linux

It's a good idea check the integrity of media made from ISO images. It's possible to do this using only two simple tools: dd and sha1sum. If you want, you can use another hash algorithm, like md5sum, sha256sum or sha512sum.

The examples in this article were made in a Linux environment.

First, you need to know the hash of the ISO image. In the following example, I used the sha1sum tool to get the sha1sum hash of the ISO image openSUSE-12.1-GNOME-LiveCD-x86_64.iso:

rafael@rafael:~/rafael/tmp> sha1sum openSUSE-12.1-GNOME-LiveCD-x86_64.iso
4922fc8d380fd688825954026f72655fc42bd233  openSUSE-12.1-GNOME-LiveCD-x86_64.iso

Now you know the hash of the ISO image: 4922fc8d380fd688825954026f72655fc42bd233. When I downloaded the image from the openSUSE's official torrent, I checked in the openSUSE's official site if its hash is equal to the downloaded ISO image hash in my computer. And I confirmmed that it is (the hash is in the file http://download.opensuse.org/distribution/12.1/iso/openSUSE-12.1-GNOME-LiveCD-x86_64.iso.sha1).

And now, you need to know the size in bytes of the ISO image. You can see this through the ls -l command:

rafael@rafael:~/rafael/tmp> ls -l
total 691204
-rw-r--r-- 1 rafael users 707788800 Aug 21 18:23 openSUSE-12.1-GNOME-LiveCD-x86_64.iso

Now you know that the ISO image size is 707788800 bytes. To get the hash of the media part that contains the ISO image, you need to run the following command putting the ISO image size value after the count argument:

rafael@rafael:~/rafael/tmp> dd if=/dev/cdrom bs=1 count=707788800 | sha1sum
707788800+0 records in
707788800+0 records out
707788800 bytes (708 MB) copied, 724.078 s, 978 kB/s
4922fc8d380fd688825954026f72655fc42bd233  -

You could speed this up by using a larger block size (bs) and dividing count by the new block size. Since all iso images are multiples of 2048, that is an appropriate block size.

And there is the gold, in the last line: the hash of the ISO image on the media. If this hash is equal to the hash generated by the hash tool on the ISO image, the media should be OK to be used. If it's not, it's recommended record again the media, until both hashes be equal.

It's necessary hash only the size of the ISO image in the media because a hash of the entire media will return a different value because it will contain the empty space at the end of the disk.