Back in the days when I was setting it up, the latest version of ESXi available was 3.5. I had a fair bit of a headache to get the system set up and boot from RAID10 array. It involved:

• creating custom oem.tgz (edit pci.ids, etc, etc…)
• integrating it into install image
• after install, connecting external DVD drive to the server
• boot into Knoppix LiveCD
• set up RAID10 support in Knoppix (it didn’t work out of the box)
• finally, copy my custom oem.tgz to the relevant partition on RAID10 device
• pray that it works (which it did)

This is a fair bit of hassle, which I didn’t document at all.

Now imagine my disappointment when I figured out that neigher patching nor “normal” upgrades from ESXi 3.5 to ESXi 4/4.1 work for my setup – something to do with custom oem.tgz. Trust me, I tried everything, all possible combinations of upgrades, upgrade tools, network setups, etc. It just doesn’t work, so don’t waste your time on that. At the same time, I needed a solution, as I had to run 64-bit OSes.

To cut the long story short, here is a simple and elegant solution that worked perfectly for me:

1. Install brand new copy of ESXi 4/4.1 (or whatever is the latest at the time) onto USB stick (I used 1Gb SanDisk) following these instructions
2. Boot into any Linux with your newly baked ESXi USB stick connected
3. Download this oem.tar.gz (it must work for anything that is compatible with hptiop driver 1.6 – this includes a range of HighPoint devices with Intel IOP processor)
4. Rename it to oem.tgz
5. Make sure your USB is mounted (“mount” without parameters will tell you what is mounted and where). Let’s assume that your USB partitions are mounted on /media
6. Run something like “find /media -type f -name oem.tgz” to find where exactly the old oem.tgz is located. Let’s assume you find that it is in /media/part1/oem.tgz
7. (this assumes you do not require any other OEM drivers! if you do – for example, for networking – you need to merge two oem.tgz files; this is out of scope of this article) Back it up: “mv /media/part1/oem.tgz /media/part1/oem.tgz.backup”
8. Overwrite the old oem.tgz with a new one: “mv ./oem.tgz /media/part1/”
9. Reboot and enter setup
10. Set your system to boot from USB first
11. Voila – you will have your VMWare ESXi on USB stick, you can import the RAID10 storage and all of your VMs through VMWare vSphere Center.

So this now works and all the updates can be applied remotely without reinstalls/etc. Nice!

I hope this helps someone. If not, it will help me one day.

I have quite a hierarchical tree of my links in SiteBar. However, one piece of functionality that I missed a lot in SiteBar compared to Spurl, was the ability to see and click on URLs that I recently visited, or recently added, or that I visit the most often. I had this on my TODO list for eons.

At the same time, after my move to Kaspersky Lab, I wanted to check how easy it is to work with PHP compared to Perl. At the same time, having the abovementioned functionality became very important as well. So I thought: why not combine the two together, and add missing functionality to SiteBar, while exploring PHP a bit further for work purposes?

So here you go: the result of around 1 hour of poking around SiteBar and PHP. Here is how to use it:

1. Replace your “/var/www/your-site/sitebar/inc/tree.inc.php with the downloaded from here (of course, it’d make sense to backup your old one, just in case)
2. In your SiteBar, go to “Maintain Trees”, then create the following 5 trees (or less, if you don’t need all the functionality; the names and case are important):
   1. “Recently Added” – for recently added URLs
   2. “Recently Visited” – for recently visited URLs
   3. “Most Visited” – for most visited URLs
   4. “Dead” – for dead links
   5. “Unverified” – for those links that haven’t been checked
3. After you do that, every folder of those is going to display top 30 relevant links in your whole collection

So hopefully someone else also finds it useful. Have fun!

P.S. By the way, yes, my opinion is that PHP is as easy as Perl, and implies a more structured approach and, therefore, a tiny bit easier to read.

Like today. I decided that my digital photos were not organized properly. So I just had to move them from drive X: (which is my large, slow, reliable backup and junk drive), to drive D: (which is my super-fast, RAID0 300Gb total WD Raptors 10k). At the same time, I use Adobe Photoshop Elements 6 to manage my photo collection (btw, definitely recommended – provided that you know its character). This means that in addition to just moving the files, one needs to make sure that the Photoshop Elements catalog is up-to-date.

There are several ways to make sure that the catalog is up-to-date.

1. Use “Reconnect Files” menu option in Elements. All good and wonderful, but one needs to be very careful about what links to accept and what not to – especially, in large collections. I’ve had cases where the reconnection completely messed up the catalog by connecting to irrelevant files
2. The way Adobe proposes to move files between locations preserving their directory structure is “Backup/Restore”. Sounds reasonable?
3. Adobe’s *.pesg files (the files that are Photoshop Elements catalogs) are nothing more but SQLite databases with quite clear schema. So using one of the available tools for editing SQLite databases, one can update the catalogs after manually moving files. Sounds like a bit of work though…

Being lazy and having trust in Adobe, I took option (2). There were no issues with backup. Then I wanted the files that were backed-up from X:\Pictures to be restored into D:\Users\Maksym\Pictures preserving my nice, clear and easy-to-navigate directory structure. This meant specifying D:\Users\Maksym as a destination directory for restore. So I restored the files just to see that the catalog files, together with some junk files, were restored directly into D:\Users\Maksym. Not good – they were not supposed to be there! So I thought I missed some option and decided to repeat the restore. But before repeating it, I decided to delete the just-restored catalog. I went into File->Catalogs, selected Maksym as a catalog, and pressed Remove. What would a thinking person expect to happen? I expected the catalog files together with the files it refers, to be deleted.

Do you know what Photoshop Elements has done? No? Wait for it: IT DELETED THE WHOLE OF D:\Users\Maksym, with ALL of my Documents, Downloads, Music, Pictures, Video vanishing from the hard drive!!!

A normal reaction to this situation is PANIC. I only calmed down a little, when I realized that I have Windows built-in backup working like a dream on a nightly basis, and in addition, BackupPC running on my Ubuntu Server box does another backup of the same box to a different location. I managed to restore the majority of the files, other than 1 days worth.

The bottom line is: because of a Backup running in a scheduled mode, I only lost around $10 in my online music downloads, and some work I did in the morning around planning financial strategy for my investment portfolio and around tracking my personal finance. Not a huge price, it could have been much worse.

THANK YOU, BACKUPS!

P.S. An easy solution was to manually move catalog files to the desired location after the Restore process in Adobe Photoshop Elements completes, and delete some rubbish files that shouldn’t have been there in the first place. I did exactly this, and now my computer is running perfectly, with its Pictures folder where I want it.