Quick styling

Quick styling no embedding!

<style type="text/css">
pre.source-code {
  font-family: Andale Mono, Lucida Console, Monaco, fixed, monospace;
  color: #000000;
  background-color: #eee;
  font-size: 12px;
  border: 1px dashed #999999;
  line-height: 16px;
  padding: 10px;
  overflow: auto;
  width: 100%
}
</style>

<pre class="source-code"><code>Quick styling no embedding!
</code></pre>

Quick styling embedded! 

Getting a VM to work...the hard way

What am I talking about? I still don't really understand the concept of a computer running inside a computer. And I don't mean a laptop running inside a desktop case! I'm talking about Virtual-Machines. Loading an OS from a recently acquired image and then making it run in the background of an already running OS. Sounds like I might need a faster computer. Or get some liquid N2 and just frost up the bottom of my laptop. At least my palms wouldn't get hot. It does sound like a bit much.

Kernel-based Virtual Manager looks like a decent package. A bare bones kind of software that hopefully won't weigh down the running system. Problem is that I don't know how to use it, and I think that it runs from a command-line, which is what I want. There is an ever-so-useful HowTo at there site, and I'm testing that the procedures do work as I type this. I should go to bed.

Install the packages below as a start.

sudo apt-get -y install kvm qemu bridge-utils uml-utilities
sudo modprobe kvm
sudo apt-get -y install libvirt-bin
sudo apt-get -y install virt-manager

The last one is meant to be some sort of GUI but I have no idea how to use it, yet. The modprobe line reloads KVM without having to restart your computer, even though I've restarted mine several times before even getting this far.

Next, is you'll want to create a disk image for the guest-image, or in other words, a place where the virtual machine will live/sleep. From what I gather, Qcow2 is some sort of tool which creates a standalone image from a cluster of memory which is then scanned by the header when it needs to be read. I don't know. It's a thing. Create one like this:

/path/on/computer/where/it/will/live create -f qcow2 imagename.img 10G

Qcow2 will do it's thing, the last paramater is the size of the image, 10G -- I haven't played around with this much. When you have finally downloaded your Free and Open Source Linux distro that you so desire, just go ahead and install it.

sudo qemu-system-x86_64 -hda imagename.img -cdrom /path/where/.iso/is -m 512

There is meant to be some sort of read error and the host os will be unable to determine if the system you are installing is 32 or 64 bit, so by assigning qemu-system-x86_64 as the pathway, no one gets confused. Although, it might actually be part of the command, not sure. The final -m tells qemu how much RAM you want to allocate to the VM. I'm finding out now that maybe I should have used -m 1024, 36mins57s remaining...uhg!

1:29:40AM - Still waiting...

1:34:46AM - Meanwhile, test that the printer works

1:49:05AM - Printer works, going to bed, check the install in the morning.

5:35:19AM - Still going, stupid WINS param...

8:54:24AM - Yay! It's working! I'm now running Debian 2.22.3

Lastly, when you need to start up the VM from scratch, it is a simple call of the OS file created and the image memory, or whatever you want to call it. As you will probably find out, it's much simpler to create a directory and store both of these files there, that's what I did.

qemu-system-x86_64 -hda /path/to/imagename.img

So that's it. The system seems to be working fine. I have somehow lost track of where the KVM functionality is taking place, as Qemu seems to be doing all the work. My understanding of KVM has been rewritten, again - I must have missed something.

Creating an autorun script for when a specific USB device is plugged into your Computer

Much of my information came from this thread, very helpful: http://ubuntuforums.org/showthread.php?t=502864

Several steps are involved and several locations will be accessed heavily. These are:
/etc/udev/rules.d - where the .rules file will be kept for the computer to access when the USB device of choice is plugged in, this ultimately points to the script file below
/usr/local - or wherever your script file is located.
/home/... - any other places where script files that will be used are stored, python, C etc

/etc/udev/rules.d
A README file is available in this folder and it is helpful to read. You will need to create a file here which will be picked up by your computer and read when an action occurs.

The file must begin with two digits followed by a - and end with .rules, 70-filename.rules. It will contain the following script:

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0d49", ATTRS{idProduct}=="7350", RUN+="/usr/local/script_file.sh", SYMLINK+="my_device"

If you are lost, just take a look at the files in /etc/udev/rules.d and make a similar filename.

To make it work for a specific device, with the device plugged in, run lsusb in a terminal and find the device Vendor and Product numbers. For the Kodak Co. device below, Vendor is 040a and the Product is 0576:
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 040a:0576 Kodak Co.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

The RUN+= is the location of your script file. It is very important that this file has user executable permission as well as for all other .py files etc that will be used by the script. To do this, go to the directory with the file and run:

$ sudo chmod u+x filename

and check the permissions with

$ ls -all

It should be: -rwxr--r--
These are the permissions that work for me, I'm not sure if this is across all platforms.
The location of the script file is not important, but make it an easy place to remember. SYMLINK+= is a feature I'm not familiar as yet, however it does allocate the device to the variable given to a spot in the /dev folder, /dev/Maxtor.
The ATTRS before {idVendor} and {idProduct} can be changed to SYSFS if the device is not being recognised once plugged in. This can only be tested by you and your product, although there may be better explainations about this.

The SUBSYSTEM variable can be left out completely, however it does give useful information to the computer. Other variables such as usb_device and pci... exist but usb is the one that works for me.

At first, it is advised to make the script file a simple copy code like a cp command of a file you know to a place you know. If after you plug in the device, you find that the file has been copied to the new destination, you can be sure that the .rules file has been successfully read. This is definately the hardest part of the setup of this 'autorun' script.

Before I wrap things up, I did want to add a work-around for the .sh file, the file pointed to by the .rules file. I had problems when plugging in my device because the .sh file would read first, and then any other code already on the computer would read last. This was a problem because I wanted to point to a folder on the device but the device hadn't been mounted yet. I could have mounted it myself but I ran into a dead end. An alternative was using the sleep command followed by my code, inside some curly braces {}, looking like this:
{

sleep 5
cp -ar /a/folder/on/my/computer /folder/on/device

} &

The {} tells the interpreter to read to code, but run it in the background. With the sleep command, there is a 5 second pause while the computer runs it's usual code of mounting the device. After the 5 seconds it now copies the folder to the location on the device.

If you have a know fix for mounting a device manually using the /dev location, I'd be happy to hear. I'm now using this method to auto update my Uni files on my external HD whenever I plug it in. This is my first How-To so enjoy, rate, comment.