Cymen's Blog

I’ve switched from a Virtual Private Server hosted at Gandi.net in France to one hosted by Prgmr.com in California. I switched because the prices increased at Gandi.net after the beta and the latency was beginning to get annoying (from Wisconsin, USA). Prgmr.com is attractive because the prices are very reasonable and the RAM allocation for the price generous. I’m paying about 1/2 – 2/3 of the Gandi price but getting twice the RAM and disk space. The one thing that Gandi did have going for it is that the bandwidth was unmetered (but capped). However, for my purposes, the Prgmr model of X GB per month is not an issue.

The setup process was quick and the VPS is performing great with my minimal usage. I’m happy with the switch and would definitely recommend considering Prgmr as a VPS provider. I have no need for a high end VPS at this time but when I do, the options at Prgmr will definitely be the the first I’ll consider.

On a final note, at first I attributed the slow console feel of the VPS at Gandi to latency but after comparing the feel between Gandi and Prgrmr and the latency figures, I’d put some of the Gandi slow down to low CPU allocation for the single slice VPS offering. I suspect Prgmr is more generous with not only the RAM but the CPU slices which is excellent for those looking for a well performing but small VPS.

The biggest issue is that Windows 7 has very strong requirements on driver signing. In theory I think this is an excellent idea and may indeed keep the operating system installs of many people more stable than if this requirement is not present. However, in some cases it is an impediment: We need a libusb-based driver that will work with ArgyllCMS and the only option that I’m aware of is an unsigned driver. The good news is that Driver Signature Enforcement Overrider program exists for Windows 7 and it can put it into “Test Mode” which will allow you to load an unsigned driver.

Files (google for them):

• dseo13b.exe
• SIXAXIS_libusb-win64.zip
• Argyll_V1.0.4_win32_exe.zip
• dispcalGUI-0.2.6b3-Setup.exe

Steps:

1. Extract SIXAXIS_libusb-win64.zip
2. Run bin\inf-wizard.exe from the above extraction and choose your Spyder2 device to create the libusb-based driver files for it
3. Run dseo13b and follow directions to put the system into test mode
4. Reboot and run dseo13b again to sign all of the spyder* files in the above directory (I had to sign the .inf files and I signed the .sys and .dll too). Do this for each spyder* file in the SIXAXIS bin directory (the files created by inf-wizard.exe).
5. Start Device Manager and update the drive for the Spyder2 device. Choose “Have Disk” or similar and navigate to the SIXAXIS bin directory. Choose the unsigned (no certificate) driver.
6. I had problems with the above. I had to repeat it a couple times before it finally worked.
7. Extract Argyll_V1.0.4_win32_exe.zip to C:\ (the files inside are all in a Argyl_v1.0.4 directory
8. Go to the Windows Advanced System settings and add C:\Argyll_V1.0.4\bin to the end of the PATH environmental variable. You may be able to skip this step if you use the displayCal GUI instead of Argyll directly. I didn’t skip it.
9. Install dispcalGUI-0.2.6b3-Setup.exe.
10. Reboot again.
11. Start a command prompt and go to c:\argyll_v1.0.4\bin and run “spyd2en.exe” to extract some of the drive firmware payload (or similar) from the standard Spyer2 driver. (This maybe the equivalent of the “use Spyder2 device” (don’t have exact wording) option in the displaycalGUI interface).
12. In displaycalGUI, choose the menu option mentioned above.
13. You may need to restart displaycalGUI
14. Now displaycalGUI should see the Spyder2 device.

When I tried to use displayCal with the Spyder2 device, I kept getting “instrument access failed” messages kicked back from one of the ArgylCMS executables. I don’t know what I did to solve it. It might have been rebooting. I googled a while on it and finally it just started working. Not exactly a stellar guide here but there is little else out there.

The rest of it is still uncharted territory. I did notice gamma defaulted to 2.4 so I bumped that down to 2.2. I set my profile to Photo and am running a calibration right now. It looks like quite a lengthy process to do calibrations/profiles. Or the progress is slightly unclear. Either way, I’ll be ecstatic if this lets me use the full potential of the Spyder2 device without having to buy the Spyder2 Pro license/upgrade (at that point, I’d opt towards buying a new device).

The last thing missing is the LUT/profile loader. I am hoping the Spyder2 profile loader will work with the files generated by ArgylCMS.

I wanted to use Debian testing in a Xen DomU but after upgrading (including grub), “xm create ” no longer worked. It failed with the error:

Error: Boot loader didn't return any data!

I followed the suggestion of running “pygrub /path/to/xen/disk” but each of my DomU get a chunk of LVM disk. Within the LVM logical volume, the DomU OS partitions the disk however it wants. I need to get at one of the partitions inside the LVM from the Dom0 or Xen host OS. To do this, get kpartx and run it like so:

kpartx /dev/physical_volume_name/logical_volume_name

After running that, I found my disk partitions from the DomU logical volume at /dev/mapper/logical_volume_name1, 2, 3, etc. So I could then run:

pygrub /dev/mapper/logical_volume_name1

That error out again but it was line 68 of GrubConf.py:

def set_disk(self, val):
val = val.replace("(", "").replace(")", "")
self._disk = int(val[2:])

I added the Python lines to print out the value of val and found that it was getting set to an empty string. Then I simply mounted the now accessible root partition:

mount -t ext3 /dev/pv/lv1 /mnt/tmp

And editing the …/boot/grub/menu.lst revealed the debian upgraded and spewed some cruft into the file. Cleaning that up resulted in a working DomU. The upgrade probably mentioned this but I glazed over it. I suspect I’m not the only one so it’s worth a check.

Finding kpartx made it worthwhile…