Windows is unable to install to the selected location. Error: 0x80300001

The above is a very annoying error I just encountered while installing a new VM (Windows 7 in this case) under ProxMox with a VirtIO hard drive. After scratching my head for a bit (after all, I had just manually loaded the Virtio drivers to get it to see the hard drive, which it was now and showing the correct size), I searched around and found a page with someone having the same issue.

It seems that the Windows 7 installer isn't smart enough to tell you to switch back from your driver cdrom/dvd (a virtual one in this case but still) to the Win7 install media so it gives you this very unhelpful & cryptic error message. Once you have switched it back to the install media and hit refresh, it lets you continue on without a hitch.

Yay for vague error messages.

A somewhat scary bit of research has been done by Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson. They found that the current methods for clearing hard drives of their data (ie: removing of sensitive material or just clearing it for selling or handing down to someone else for example) doesn't work for SSD (solid state drives), which are very commonly found as USB Thumb drives and more commonly shipping or being put into new systems in place of standard hard drives.

While sanitizing entire disks and individual files is well-understood for hard drives, flash-based solid state disks have a very different internal architecture, so it is unclear whether hard drive techniques will work for SSDs as well.

We empirically evaluate the effectiveness of hard drive-oriented techniques and of the SSDs' built-in sanitization commands by extracting raw data from the SSD's flash chips after applying these techniques and commands. Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.

This third conclusion leads us to develop flash translation layer extensions that exploit the details of flash memory's behavior to efficiently support file sanitization. Overall, we find that reliable SSD sanitization requires built-in, verifiable sanitize operations.

More information can be found as a Video, PDF or also a summary article at TheRegister

There is a nice guide to how SSD drives work (http://juku.it/en/2010/12/14/ssd-demystified/) over on Juku.it that I found useful as a fairly quick explanation on NAND, SLC vs MLC, FAL, etc.

Over on the Citrix Blog there is a short guide on downloading XenDesktop 5 Express with 1 year license, XenServer 5.6, some documentation and other useful software & guides. It's a nice way to make a test lab or just to brush up or add to your skills. I may go through the setup simply to add to mine :)

As a bonus, I found a link to Craig Ellrod's setup on the site as well which looks interesting.

Ever needed to find out what process has a port open? Or easily check all listening ports and see what process has them open?

If so, it's very easy to do. There are in fact, multiple ways to solve these problems.

The main way that I use is netstat. It can show many useful things but for this example, the syntax is:

netstat -tulpn

Which will show something like:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address        Foreign Address   State       PID/Program name
tcp        0      0 127.0.0.1:3306       0.0.0.0:*         LISTEN      1374/mysqld
tcp        0      0 0.0.0.0:139          0.0.0.0:*         LISTEN      1132/smbd
tcp        0      0 0.0.0.0:80           0.0.0.0:*         LISTEN      12171/apache2
tcp        0      0 0.0.0.0:50000        0.0.0.0:*         LISTEN      2247/mediatomb
tcp        0      0 0.0.0.0:4949         0.0.0.0:*         LISTEN      1413/munin-node
tcp        0      0 0.0.0.0:53           0.0.0.0:*         LISTEN      1371/dnsmasq
tcp        0      0 0.0.0.0:22           0.0.0.0:*         LISTEN      1093/sshd

You can also use grep to limit your results if you have a lot of open ports:

netstat -tulpn | grep :80

for example will show you port 80 (http)

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      12171/apache2

Another method that works but I find isn't as handy at times is fuser:

fuser 80/tcp

which will show something like:

80/tcp:              12171 12174 12175 12176 12177 12178

but doesn't tell you easily the name of the process like netstat will, which for example means another step like:

ls -l /proc/12171/exe

to give you

lrwxrwxrwx 1 root root 0 2011-02-14 12:55 /proc/12171/exe -> /usr/lib/apache2/mpm-prefork/apache2

which then tells you that port 80 is opened by process 12171 which is apache2.

I prefer the netstat option as that shows everything you need to know with just one command generally.