Anquet and VirtualBox Shared Folders

For a while now, I have had Anquet installed in a virtual machine instance of Windows XP but it has been throwing errors continuously on start up. Perhaps surprisingly, it only dawned upon me recently what might have been the cause. A bit of fiddling revealed that my storing the mapping data Linux side and sharing it into the VM wasn’t helping and copying it to a VM hard drive set things to rights. This type of thing can also cause problems when it comes getting Photoshop to save files using VirtualBox’s Shared Folders feature too. Untangling the situation is a multi-layered exercise. On the Linux side, permissions need to be in order and that involves some work with chmod (775 is my usual remedy) and chgrp to open things up to the vboxusers group. Adding in Windows’ foibles when it comes to networked drives and their mapping to drive letters brings extra complexity; shared folders are made visible to Windows as \\vboxsvr\shared_folder_name\. The solution is either a lot of rebooting, extensive use of the net use command or both. It induces the sort of toing and froing that makes copying things over and back as needed look less involved and more sensible if a little more manual than might be liked.

Getting Fedora working in VirtualBox

After a hiatus induced by disk errors seen on start up, I have gone having a go with Fedora again. In the world of real PC’s, its place has been taken by Debian so virtualisation was brought into play for my most recent explorations. I could have gone with 10, the current stable version, but curiosity got the better of me and I downloaded a pre-release version of 11 instead.

On my way to getting that instated, I encountered two issues. The first of these was boot failure with the message like this:


As it turned out, that was easily sorted. I was performing the installation from a DVD image mounted as if it were a real DVD and laziness or some other similar reason had me rebooting with still mounted. There is an option to load the hard disk variant but it wasn’t happening, resulting in the message that’s above. A complete shut down and replacement of the virtual DVD with a real one set matters to rights.

The next trick was to get Guest Additions added but Fedora’s 2.6.29 was not what VirtualBox was expecting and it demanded the same ransom as Debian: gcc, make and kernel header files. Unfamiliarity had me firing up Fedora’s software installation software only to find that Synaptic seems to  beat it hands down in the search department. Turning to Google dredged up the following command to be executed and that got me further:

yum install binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel

However, the installed kernel headers didn’t match the kernel but a reboot fixed that once the kernel was updated. Then, the Guest Additions installed themselves as intended with necessary compilations to match the installed kernel.

The procedures that I have described here would, it seems, work for Fedora 10 and they certainly have bequeathed me  a working system. I have had a little poke and a beta of Firefox 3.5 is included and I saw sign of OpenOffice 3.1 too. So, it looks very cutting edge, easily so in comparison with Ubuntu and Debian. Apart from one or niggles, it seems to run smoothly too. Firstly, don’t use the command shutdown -h now to close the thing down or you’ll cause VirtualBox to choke. Using the usual means ensures that all goes well, though. The other irritation is that it doesn’t connect to the network without a poke from me. Whether SELinux is to blame for this or not, I cannot tell but it might be something for consideration by the powers than be. That these are the sorts of things that I have noticed should itself be telling you that I have no major cause for complaint. I have mulled over a move to Fedora in the past and that option remains as strong as ever but Ubuntu is not forcing me to look at an alternative and the fact that I know how to achieve what I need is resulting in inertia anyway.

Killing those runaway processes that refuse to die

I must admit that there have been times when I logged off from my main Ubuntu box at home to dispatch a runaway process that I couldn’t kill and then log back in again. The standard signal being sent to the process by the very useful kill command just wasn’t sending the nefarious CPU-eating nuisance the right kind of signal. Thankfully, there is a way to control the signal being sent and there is one that does what’s needed:

kill -9 [ID of nuisance process]

For Linux users, there seems to be another option for terminating process that doesn’t need the ps and grep command combination: it’s killall. Generally, killall terminates all processes and its own has no immunity to its quest. Hence, it’s an administrator only tool with a very definite and perhaps rarely required use. The Linux variant is more useful because it also will terminate all instances of a named process at a stroke and has the same signal control as the kill command. It is used as follows:

killall -9 nuisanceprocess

I’ll certainly be continuing to use both of the above; it seems that Wine needs termination like this at times and VMware Workstation lapsed into the same sort of antisocial behaviour while running a VM running a development version of Ubuntu’s Intrepid Ibex (or 8.10, if you prefer). Anything that keeps you from constantly needing to restart Linux sessions on your PC has to be good.

A quick way to create a blank text file

The primary job done by the touch command in UNIX or Linux is to update the time stamps on files. However, it also has another function: creating an empty text file where you are "touching" a file that doesn’t exist. This has its uses, particularly when you want to reduce the amount of pointing and clicking that you need to do or you want to generate a series of empty files in a shell script. Whatever you do with it is up to you.

Quickly surveying free disk space on UNIX and Linux

Keeping an eye on disk space on a Solaris server is important for me at work while keeping the same top level overview is good for my use of Linux at home too. Luckily, there’s a simple command that delivers the goods:

df -h 2>/dev/null

The "df -h" piece is what delivers the statistics while the "2>/dev/null" rids the terminal of any error messages; ones stating that access has been denied are common and can cloud the picture.